Despliegue blue-green: cambia de sistema sin downtime

El despliegue blue-green es una técnica de release en la que ejecutas dos entornos de producción completos lado a lado: blue, que atiende a los usuarios hoy, y green, que contiene la nueva versión. Una vez que green está probado, mueves el tráfico de blue a green en un único cambio controlado.

Bien hecho, los usuarios no deberían notar downtime, porque blue sigue funcionando todo el tiempo. Si green se comporta mal, apuntas el tráfico de vuelta. Es una de las formas más simples de reemplazar un sistema en producción, con una parte difícil: la base de datos. A continuación explico cómo funciona el cambio, dónde encaja en una migración y dónde no.

¿Qué es el despliegue blue-green?

Mantienes dos entornos tan idénticos como puedas. Blue está en vivo. Green está inactivo o recibe solo tráfico interno de prueba. Despliegas la nueva versión en green, ejecutas smoke tests y luego cambias el router para que green pase a estar en vivo. Blue se convierte en tu standby. En el siguiente release, los roles se invierten.

Qué necesitas antes de intentarlo

• Una capa de switch: un load balancer, reverse proxy, API gateway, registro DNS o una función de la plataforma que decida a dónde va el tráfico.
• Entornos equivalentes: la misma infraestructura, la misma forma de configuración, el mismo manejo de secretos. Las diferencias entre blue y green son la fuente de las sorpresas.
• Health checks: tests automatizados que demuestren que green funciona antes de recibir usuarios reales.
• Monitoreo: tasa de errores, latencia y al menos una métrica de negocio, para saber si el cambio causó daño. Como trabajé en el equipo de carrito y checkout de Total Wine & More, siempre observo un flujo de dinero durante un cambio, no solo métricas técnicas.

Si no puedes construir el segundo entorno de forma repetible, arregla eso primero. La configuración manual hace que blue-green sea lento y riesgoso.

¿Cómo pasa el tráfico del entorno viejo al nuevo?

El tráfico se mueve dondequiera que esté tu capa de enrutamiento. Las opciones comunes se diferencian sobre todo en qué tan rápido y qué tan limpio hacen el cambio.

Elijas lo que elijas, piensa en las solicitudes que ya están en curso. Deja que blue las termine (connection draining) antes de dejar de enviarle tráfico. Revisa también las sticky sessions, las cachés en memoria y las conexiones de larga duración, como los websockets. Un usuario con sesión iniciada en blue no debería perder la sesión por el cambio.

¿Cómo ayuda el despliegue blue-green a reemplazar un sistema en producción?

Te da un momento en el que el sistema viejo y el nuevo existen a la vez y tú eliges cuál ven los usuarios. Esa es la forma más segura para una migración, porque la decisión es reversible.

Lideré la migración completa de una plataforma en avanzzada que se postula automáticamente a ofertas de empleo por sus usuarios, moviendo toda su arquitectura de un stack legado a uno nuevo mientras la gente seguía usándola todos los días. La lección que saqué de ese tipo de trabajo: pon el switch delante de todo antes de escribir código nuevo. Una vez que puedes enrutar el tráfico, cada paso posterior se convierte en una decisión pequeña y reversible, en lugar de una noche de lanzamiento.

Dónde encaja y dónde no

• Buen encaje: reemplazar un servicio o una aplicación completa cuando el viejo y el nuevo pueden funcionar en paralelo.
• Encaje más débil: un sistema grande en el que el nuevo stack todavía no puede hacerlo todo. Ahí, muévete pieza por pieza y usa blue-green por ruta o por servicio.
• Costo: pagas por ejecutar dos entornos durante la superposición. En mi experiencia, eso suele ser más barato que una reescritura big-bang, que de todos modos tiene que mantener el sistema viejo funcionando en paralelo.

Una trampa es el trabajo en segundo plano. Si ambos entornos ejecutan los mismos jobs programados o consumidores de colas, los usuarios pueden recibir emails, cobros o acciones automáticas duplicados. Decide qué entorno es dueño de los workers y apágalos en el otro. Cuando asumo una base de código, mi orden es: primero los accesos, luego el build, luego los flujos de dinero, luego los riesgos, y un inventario de jobs y consumidores es uno de los primeros riesgos que anoto.

¿Qué pasa con la base de datos durante un cambio blue-green?

Esta es la verdadera dificultad. Dos versiones de la aplicación normalmente comparten una base de datos, así que el esquema tiene que funcionar para ambas al mismo tiempo.

Opción 1: base de datos compartida, cambios retrocompatibles

El enfoque más común, y el que uso por defecto, es expand and contract:

1. Expand: agrega columnas o tablas nuevas sin quitar nada. Blue sigue funcionando.
2. Despliega green y cambia el tráfico. Green usa la nueva estructura y tolera la vieja.
3. Contract: cuando estés seguro de que no harás rollback, elimina las columnas viejas en un release posterior.

Nunca combines un cambio destructivo de esquema con el cambio de tráfico. Eso elimina tu rollback.

Opción 2: bases de datos separadas

Cuando el nuevo sistema tiene un modelo de datos o un motor de base de datos diferente, green tiene su propia base de datos. Entonces necesitas mantener ambas sincronizadas hasta el cambio, usando replicación o change data capture, y a menudo un breve congelamiento de escrituras en el cutover. Es más trabajo y conlleva más riesgo, así que lo trato como un proyecto aparte y lo ensayo primero con una copia de los datos de producción.

¿Cómo haces rollback si la nueva versión falla?

Hacer rollback significa enviar el tráfico a blue otra vez. Si te preparaste para ello, normalmente toma segundos, y es la razón principal para usar esta técnica.

• Define los disparadores de antemano. Por ejemplo: una tasa de errores por encima de un umbral acordado, fallos de inicio de sesión o una caída en una acción de negocio clave, como checkouts o envíos de formularios. No lo debatas durante un incidente.
• Mantén blue funcionando y actualizado durante una ventana de observación definida. Apagarlo justo después del cambio elimina tu red de seguridad.
• Protege los datos. Todo lo que escribió green debe seguir siendo legible por blue. Por eso importan los cambios de esquema retrocompatibles. Con bases de datos separadas, quizá necesites sincronizar los datos de vuelta.
• Ensaya. Practica el rollback en staging. Un rollback no probado es una suposición.

Ten en cuenta también los límites. Un rollback no puede deshacer efectos secundarios ya enviados al mundo exterior, como emails o pagos. Las operaciones idempotentes y unos buenos logs te ayudan a limpiarlos.

Blue-green o canario: ¿cuál deberías usar?

Ambos reducen el riesgo de un release, pero sacrifican cosas distintas.

• Blue-green: todos los usuarios pasan a la vez, el rollback es un solo cambio y la lógica es fácil de entender. Cuesta un segundo entorno completo, y un bug oculto afecta a todos antes de que lo notes.
• Canario: una pequeña parte de los usuarios recibe primero la nueva versión, así que un bug afecta a menos personas. Requiere enrutamiento ponderado y métricas sólidas para evaluar el resultado, y significa que dos versiones atienden a usuarios durante más tiempo.

Mi regla práctica, como estimación y no como estándar: usa blue-green cuando quieras un cutover limpio y reversible y puedas ejecutar ambos entornos a bajo costo. Usa canario cuando el cambio sea riesgoso para el comportamiento real de los usuarios y tengas el monitoreo para leer los resultados. Combinarlos funciona bien: verifica green con tráfico de prueba y luego mueve a los usuarios por etapas con enrutamiento ponderado, manteniendo blue listo hasta el final.

¿Quieres una segunda opinión sobre tu cambio?

Si estás planificando un cutover y tienes dudas sobre la base de datos o el plan de rollback, escríbeme a me@filipeeduardo.dev con los detalles. Con gusto comparo notas contigo y te digo qué revisaría primero.