Líderes de opinión
Comience a prepararse ahora para el próximo apagón en la nube

Los incidentes importantes en la nube, como el de esta semana en AWS, son inevitables. Estos cuatro métodos pueden ayudar a su empresa a seguir adelante.
Con innumerables horas de productividad perdida, sistemas financieros interrumpidos para millones de usuarios, y posiblemente cientos de miles de millones de dólares perdidos, el apagón de AWS de esta semana fue un día terrible para los equipos de TI globales. Por supuesto, también fue la peor catástrofe de la nube a nivel global desde el último… y hasta el próximo.
Ya sea que esté en AWS, GCP, Azure o cualquier otra plataforma, los apagones importantes son una realidad de la computación en la nube. Entonces, ¿qué puede hacer su empresa para suavizar el golpe? A continuación, ofreceré cuatro pasos que su equipo puede tomar de inmediato.
Traiga su escepticismo – y haga su tarea.
A menudo, los equipos se lanzan al desastre asumiendo que las grandes corporaciones de la nube son inherentemente confiables. Para ser seguro, las empresas más confiables han ganado su reputación por una razón. Al mismo tiempo, cada nube y hyperscaler ofrece una amplia gama de opciones de infraestructura – AWS América del Norte solo tiene 31 zonas de disponibilidad y 31 ubicaciones de red de borde – y algunas opciones son mucho más confiables que otras.
De hecho, la región US-EAST-1 de AWS, la causa del apagón de esta semana, había estado detrás de interrupciones importantes en 2020, 2021 y 2023, y era bien conocido en ciertos círculos de TI como la región menos confiable. Muchas empresas probablemente entendieron la situación pero tomaron un riesgo calculado dado el bajo costo y las numerosas ofertas de la región. Pero dado el alcance del apagón, es imposible no considerar cuántas empresas fueron tomadas por sorpresa – y habrían optado por regiones más confiables si hubieran sido conscientes de los compromisos. He conocido personalmente a líderes de TI que eligieron mudarse a otras regiones de AWS solo después de tener malas experiencias con US-EAST-1 en el pasado.
La lección aquí es hacer su tarea cuando se trata de opciones de infraestructura en la nube, sin importar qué nube esté utilizando. Los lugares para comenzar incluyen herramientas gratuitas como cloudprice, Cloudping, y las vistas de incidentes históricos de las herramientas de salud de los servicios en la nube proporcionadas por los hyperscalers.
Elige portátil sobre nativo de la nube.
Cuando esté diseñando configuraciones de la nube, la ruta más sencilla es ir con la nube nativa. Sin embargo, aunque es conveniente seleccionar aplicaciones listas para usar construidas por y para su proveedor de la nube, estas opciones nativas de la nube lo dejan más expuesto si su nube se va hacia abajo.
Para evitar esa capa adicional de dependencia de la nube, opte por productos independientes y/o de código abierto cuando sea posible. Algunos ejemplos de reemplazos incluyen los siguientes:
|
Categoría |
Ejemplo de oferta nativa |
Alternativas de código abierto incluyen… |
|
Autenticación e identidad |
AWS Cognito |
Keycloak |
|
Búsqueda |
Azure Monitor |
Elasticsearch |
|
Bases de datos relacionales |
Google Cloud SQL |
PostgreSQL |
|
Bases de datos NoSQL |
AWS DynamoDB |
MongoDB |
|
Orquestación de contenedores |
Azure Kubernetes Service (AKS) |
Kubernetes |
|
Monitoreo y observabilidad |
Google Cloud Monitoring |
Prometheus + Grafana |
|
Colas de mensajes |
AWS SQS/SNS |
Apache Kafka |
|
Almacenamiento de objetos |
Azure Blob Storage |
MinIO |
|
Puerta de enlace de API |
Google Cloud API Gateway |
Kong |
Para ser seguro, construir más de su pila de la nube desde cero significa más trabajo para sus equipos. Sin embargo, en mi experiencia, una vez que tiene la infraestructura en funcionamiento, hay poco o ningún diferencia entre agregar carga de trabajo a una infraestructura establecida o operar en una nube nativa. Y los beneficios en términos de resistencia – sin mencionar la reducción de la dependencia de la nube – hacen que las opciones independientes sean muy valiosas.
Ingeniería para el fracaso.
Dado que los fallos de la nube ocurrirán, asegúrese de diseñar sus productos con el fracaso de la nube en mente. Un ejemplo para mirar es Datadog: en un incidente de 2023, la empresa perdió repentinamente el acceso a más de la mitad de sus nodos de Kubernetes en producción y rediseñó completamente su enfoque de desastres en respuesta. Los cambios incluyeron eliminar cuellos de botella arquitectónicos y abordar la deuda técnica para que los fallos parciales no se propagaran por el sistema, mejorar la ingesta y almacenamiento de datos para una mayor disponibilidad de datos durante los apagones, y construir sistemas para recuperarse automáticamente a gran escala. Un gran lugar para comenzar en su viaje es seguir la recomendación de Datadog de “comenzar con lo que es importante para el usuario final” y construir salvaguardas para proteger lo que más importa.
Ejecutar en al menos dos nubes.
Por supuesto, la mejor manera de no estar sujeto a los fallos de la nube es la redundancia de la nube múltiple. Lograr una verdadera fluidez en la nube múltiple es un esfuerzo enorme para muchas empresas, ya que es extremadamente difícil traducir la infraestructura de una nube a otra. Pero construir infraestructura en solo dos nubes es un buen – y a menudo factible – lugar para comenzar. Crítico para hacer que esto funcione es tener un equipo en su lugar con un experto en cada una de las nubes que está ejecutando.
Para ser seguro, nada puede proteger completamente a las empresas del impacto de un apagón masivo como el que vimos esta semana. Pero con la debida diligencia adecuada, un enfoque portátil en la nube, la ingeniería para el fracaso y el uso de “dual-nube” como una piedra de toque para la verdadera nube múltiple, las empresas pueden ser mucho más ágiles cuando el próximo (y desafortunadamente inevitable) incidente importante de la nube ocurra.












