Interrupción de AWS: su respuesta a la caída de AWS no debería ser multinube

Comentario: Es conveniente asumir que la multinube resolverá los problemas de resiliencia de su aplicación. Conveniente, pero incorrecto. Este es el por qué.

Imagen: iStockphoto / Ralwel

Trabaja en TI empresarial, por lo que no es muy propenso a unirse De Twitter «#hugops» multitud cuando un servicio en la nube deja de funcionar. La semana pasada, la región de EE. UU.-Este para AWS se hundió, y mucho, dejó a cientos de millones de clientes de Netflix, Disney + y otras propiedades en línea sin servicio. Esas empresas no querían abrazos. Querían una solución.

Lamentablemente, la multinube no es esa solución.

VER: Kit de contratación: ingeniero en la nube (TechRepublic Premium)

Como ha subrayado el cofundador de Honeycomb, Charity Majors, la multinube no ofrecerá la capacidad de recuperación de aplicaciones que desea. Y, quizás aún más pertinente para aquellos que se dirigen a una solución multinube para la implosión entre EE. UU. Y el este, hay varios pasos imperativos que deben tomar para brindar resiliencia a las aplicaciones antes de «fantasear con la disponibilidad de múltiples nubes», dijo Lydia Leong, analista de Gartner.

¿Igual que?

Carros antes que caballos

Antes de empezar a pensar en varias nubes, es mejor elegir bien la primera. Ese es el tl; dr del argumento de Leong: «Antes incluso de fantasear con la disponibilidad de múltiples nubes, debe ser multi-AZ en múltiples regiones y haber maximizado su capacidad de recuperación a través del diseño / implementación de aplicaciones adecuadas, probadas a fondo a través de la ingeniería del caos».

Incluso si está haciendo todo esto, es posible que todavía no haya respuestas fáciles. Una persona que respondió al tweet de Leong señaló: «El problema suele ser el estado. Replicar su base de datos principal en otra región es costoso. [AWS-East] el impacto parece estar relacionado con la creación de redes. En raras ocasiones, las fallas en la red pueden causar agujeros negros que son difíciles de aislar en una sola zona de disponibilidad «. Algunas de ellas pueden complicar la vida del proveedor de la nube y otras de usted.

Y todo recae en los departamentos de TI que están al límite. Como Leong sugirió en un tweet de seguimiento., «Es muy fácil hablar sobre lo que la gente debería hacer. La mayoría de la gente de TI se enfrenta a situaciones no ideales[s] donde no cuentan con las personas, las habilidades, el tiempo y el dinero adecuados para implementar buenas prácticas. Por lo general, saben que están tomando riesgos. El costo del riesgo se considera menor que el costo de mitigar el riesgo «.

En una publicación de blog separada, Leong agregó:

La conmutación por error multicloud requiere que mantenga la portabilidad total entre dos proveedores, lo que es una carga enorme para los desarrolladores de aplicaciones. El tiempo de ejecución de cómputo básico (ya sean máquinas virtuales o contenedores) no es el problema, por lo que OpenShift, Anthos u otras soluciones de «Puedo mover mis contenedores» realmente no lo ayudarán. El problema son todos los diferenciadores: las diferentes arquitecturas y características de red, las diferentes capacidades de almacenamiento, las capacidades patentadas de PaaS, las capacidades de seguridad tremendamente diferentes, etc. ¿Te molestas en absoluto con la nube?

En otras palabras, antes de pasar a la nube múltiple, ponga en orden su casa en la nube única. Excepto que puede que tenga que conformarse con una «casa» algo destartalada debido al presupuesto y otras limitaciones de recursos. Ah, y si mágicamente tiene todo eso en orden, administrar con éxito un entorno multicloud no es para los débiles de corazón (o billetera).

VER: Multicloud: una hoja de trucos (PDF gratuito) (TechRepublic)

Esto no quiere decir que correr en múltiples nubes sea una mala idea. La mayoría de los proveedores de SaaS, por ejemplo, ofrecen opciones multinube porque tienen que hacerlo: Los clientes prefieren ejecutar todo tipo de nubes de infraestructura. Los proveedores de SaaS no van a rechazar a esos clientes, al menos mientras se ejecuten en uno de los 3 grandes proveedores de nube (AWS, Microsoft Azure, Google Cloud). Incluso dentro de una sola empresa, para bien o para mal, la mayoría de las empresas crean aplicaciones en múltiples nubes, según una encuesta reciente de O’Reilly. Eso no es sorprendente, ya que la conveniencia de deslizar la tarjeta de crédito y obtener la nube ha permitido a los desarrolladores poner en marcha cualquier servicio en la nube que necesiten.

Volviendo al punto original de Leong, hay mucho trabajo por hacer para habilitar la resiliencia, y comienza con una sola nube, no con varias. Y sí, ejecutará varias nubes, así es como funciona la TI. ¿Pero usar multicloud para la resiliencia…? Probablemente no quieras ir allí.

Divulgación: Trabajo para MongoDB y solía trabajar para AWS, pero las opiniones expresadas en este documento son solo mías.

Ver también