Failover multirregión: por qué es más difícil de lo que muestran los diagramas
Ayer por la mañana, ingenieros de todo el mundo tecleaban una frase en Google como si su puesto de trabajo dependiera de ello, porque por un momento así fue. La frase era "¿Cómo configurar el failover multirregión en AWS?".
Una gran caída golpeó de nuevo la región US-East-1 de AWS, y como una hilera de fichas de dominó en pleno caos digital, servicios como OpenAI, Snapchat, Canva, Duolingo, Perplexity e incluso Coinbase se quedaron fuera de línea. Así, sin previo aviso, equipos de DevOps habitualmente tranquilos pasaron a tomar triples espressos, revisar alertas de Slack sin parar e intentar recordar si sus diagramas de infraestructura eran meras aspiraciones o realmente funcionaban.
Como resumió un ingeniero: "Pasamos de estar seguros a entrar en pánico y luego a ponernos extrañamente filosóficos en 37 minutos". Define bastante bien el ambiente.
La ilusión de estar preparados
El failover multirregión suena heroico en una presentación y queda impecable en un diagrama de arquitectura. Te imaginas servidores zumbando en centros de datos lejanos y climatizados, listos para intervenir como un doble de acción digital si las cosas se tuercen.
Como demostró lo ocurrido ayer, esa imagen suele ser solo una ilusión. Entre bastidores, muchas empresas no son tan "resilientes" como creen, y las que de verdad lo son pagan sumas enormes por ese privilegio.
Por qué resulta tan endiabladamente difícil
1. Es caro, pero caro de verdad
¿Quieres cambiar de región en un instante? Necesitas duplicar o triplicar tu infraestructura y luego pagar para mantenerla. Varios ingenieros en plena batalla bromeaban ayer diciendo que "triplicar es mejor", pero al equipo de finanzas no le hace ninguna gracia.
Como publicó un ingeniero sénior: "Los clientes siempre exigen el mejor flujo de recuperación ante desastres, pero cuando mencionamos el coste, de repente la caída pasa a ser 'poco probable'". Dicho de otro modo: la resiliencia escala con el presupuesto, diga lo que diga el diagrama de arquitectura.
2. No todos los servicios admiten failover
¿Crees que estás a salvo con tu ingeniosa configuración multirregión? Genial. Ahora explica qué haces cuando Docker Hub se cae, cuando tu proveedor de identidad vive exclusivamente en US-East-1 o cuando tu canalización de compilación falla estrepitosamente porque no puede alcanzar un repositorio de dependencias. Alguien señaló: "La ingeniería del caos ya no suena tan descabellada", y probablemente llegue tarde.
Varios ingenieros se toparon con callejones sin salida donde servicios como ECR, IAM Identity Center o incluso el PrivateLink de Datadog no podían cambiar de región porque, sencillamente, no lo admiten. Un usuario compartió con resignación: "Nuestra nueva plataforma interna de documentación se cayó, justo a la que habíamos movido los planes de recuperación de emergencia". Eso sí que es un fallo poético.
3. Los proveedores externos no colaboran
Aunque tu pila sea sólida como una roca en múltiples regiones, un proveedor externo inestable puede tirarlo todo por tierra. "Nuestra infraestructura estaba perfecta", comentó un equipo, "pero Twilio estaba caído y nuestros usuarios no podían iniciar sesión. Da igual lo resilientes que seamos si nuestras integraciones no lo son".
Puedes tener una arquitectura de failover impecable, pero si tu proveedor de feature flags, tu servicio de inicio de sesión o tu herramienta de analítica se rompen, tú también te rompes.
4. Hay que ensayar el plan
El failover no es algo que configuras una vez y te olvidas. Uno de los equipos mejor preparados admitió que cambia regularmente entre regiones a propósito, solo para desarrollar memoria muscular. "Si no estás alternando de un lado a otro con frecuencia", decía un comentario, "no va a funcionar cuando de verdad lo necesites".
La mayoría de las empresas no ensayan. Tienen failover entre regiones sobre el papel, pero nunca se ha probado, y cuando AWS tiene un tropiezo se dan cuenta de que siguen atadas a esa región como a una mala relación que juraron abandonar.
Cuando caerse significa que todo el mundo se cae
Lo curioso es que, cuando AWS se hunde, la sensación no es tan mala si no estás solo. Algunos usuarios fueron implacablemente sinceros: "Nuestro plan de recuperación ante desastres básicamente consiste en esperar a que AWS se arregle solo".
Un comentarista llegó a decir: "Internet se cae cuando AWS se cae, así que los clientes entienden que tú también te caigas". Mal de muchos, consuelo de tontos: si todo está roto, tu propia caída parece menos catastrófica.
Ese sentimiento se repitió en docenas de comentarios. Por mucho que las empresas fantaseen con una disponibilidad del 99.999%, a menudo descartan una inversión real si solo sirve para evitar un mal día cada dos años. En lugar de eso, confían en que AWS, o quien sea, termine solucionando el problema.
La gran lección es que la fiabilidad va más allá de la tecnología
El simulacro de fuego de ayer tuvo tanto que ver con las prioridades de la organización como con servidores o arquitectura en la nube. Los ingenieros estaban listos, los sistemas no tanto y el presupuesto no aparecía por ninguna parte.
Alguien lo resumió a la perfección: "Mi director de tecnología me preguntó por qué estábamos afectados. Le respondí: 'Porque no quisiste pagar por la solución de recuperación que llevo tres años pidiendo'". Doloroso pero real.
La caída dejó al descubierto la brecha entre la viabilidad técnica y la disposición del negocio. Dibujar flechas de failover entre regiones es sencillo; financiarlas resulta mucho más complicado.
¿Y ahora qué?
No hay recetas mágicas aquí, pero algunas lecciones surgieron con claridad en medio del caos:
- Ensaya los failovers. Pero de verdad, ejecútalos.
- Invierte en primitivas básicas. Los servicios en la nube de valor añadido son cómodos, pero pueden resultar frágiles entre regiones.
- Audita las dependencias de terceros y asume que al menos una te va a fallar.
- Pelea por presupuestos realistas o sé sincero sobre lo que pasará cuando la nube tiemble.
- Documenta fuera de línea. Créenos en esto.
Uno de los mejores resúmenes provino de un equipo que llevaba una década preparándose para días como este. Comentaron: "Hoy no ha sido divertido, pero tampoco hubo pánico. Hizo falta años de trabajo para llegar aquí, pero ahora podemos mover servicios individuales fuera de una región si hace falta".
Ese es el objetivo deseado: un equipo tranquilo y preparado que trata la fiabilidad como un hábito y no como una jugada a la desesperada, lo cual vale mucho más que cualquier promesa de cinco nueves en una presentación.