Líderes de opinión

Comience a prepararse ahora para el próximo apagón en la nube

mm
Añade Unite.AI a tus fuentes preferidas en Google

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.

Harshit Omar es el Co-Fundador y CTO de FluidCloud, donde está construyendo el futuro de la infraestructura en la nube, permitiendo a las empresas migrar, replicar y optimizar las cargas de trabajo de manera fluida en entornos de nube múltiple. Anteriormente, fue el primer ingeniero en Accurics, donde lideró los esfuerzos de desarrollo principal en su motor de políticas y plataforma de seguridad en la nube.

Con una profunda experiencia en Go, Kubernetes, Terraform y cumplimiento en la nube, Harshit ha pasado más de una década diseñando sistemas resilientes en AWS, Azure y GCP.

Su misión ahora es eliminar el bloqueo en la nube y hacer que la infraestructura sea tan portable y resiliente como el código.