Blog

Multicloud puede ser una estrategia inteligente, pero no para brindar resiliencia a la infraestructura.

Si desea irritar a la analista simplemente dígale que adoptar la multinube para ganar resiliencia en la infraestructura es una buena idea. “La conmutación por error en múltiples nubes es casi siempre una idea terrible”, responderá, ofreciendo razones sólidas para evitar el camino de múltiples nubes hacia la resiliencia de las aplicaciones.

Según el analista, “la mayoría de las personas, y notablemente, casi todos los reguladores, están completamente equivocados al abordar la resiliencia de la nube a través de la creencia de que deberían hacer una conmutación por error de múltiples nubes…”.

Esta analista hace hincapié en que “la conmutación por error en múltiples nubes es compleja y costosa hasta el punto de que casi siempre resulta poco práctica, y no es una forma especialmente eficaz de abordar los riesgos de resiliencia de la nube”. Entonces, ¿por qué seguimos planteándolo como una panacea para mitigar la dependencia de los proveedores de la nube? Porque es fácil encontrar fantasmas en esos proveedores de la nube: “Hablamos de riesgo de concentración porque las cosas grandes e improbables y aterradoras captan la atención de la gente”, dijo.

Los reguladores, los gerentes de riesgo y una gran cantidad de administración de TI piensan en gran medida en AWS, Azure, etc., como entidades monolíticas, donde “la nube” puede romperse para ellos, y luego todo está muerto en todas partes del mundo. Se imaginan un centro de datos gigantesco y amorfo, sujeto a todos los problemas que pueden afectar a los centros de datos o sistemas individuales. Pero no es así como funciona, esa no es la forma más efectiva de abordar el riesgo, y probar la “capacidad de recuperación del proveedor” (como un todo genérico) es imposible y sin sentido.

En cambio, las nubes están formadas por componentes que se comunican entre sí. Cuando una nube falla, generalmente se debe a que esos componentes ya no pueden conversar (debido, por ejemplo, a un fallo de la red). Pero incluso aquí, las interrupciones globales “generalmente han sido lo suficientemente breves como para que, dados los objetivos de tiempo de recuperación empresarial típicos para la recuperación de desastres, que a menudo son prolongados, los clientes normalmente no activan un plan tradicional de recuperación ante desastres”, señaló.  Por supuesto, sería mejor no bajar nunca, pero el riesgo de que estos reguladores estén sobreingeniería / legislando en exceso para evitar es comparativamente pequeño.

En última instancia, enfatizó, “el enorme coste y complejidad de una implementación multinube es efectivamente una distracción negativa de lo que debería estar haciendo que mejoraría su tiempo de actividad y reduciría sus riesgos, lo que hace que sus aplicaciones sean resistentes a los tipos de fallas que son realmente probables “. Adopte la diferenciación de las nubes, en otras palabras, mientras diseña y prueba la resiliencia de las aplicaciones (por ejemplo, a través de la ingeniería del caos).

Fuente: IT User