Despliegue blue-green canary releases aplicación web

Desplegar sin que se caiga nada: el reto de siempre

Todos hemos vivido esa escena: llega el momento de actualizar la aplicación en producción y alguien dice "va, son cinco minutos de caída, lo hacemos a las dos de la mañana y nadie se entera". Pero resulta que siempre hay alguien que se entera. Un cliente que justo estaba haciendo un pedido, un usuario que pierde su sesión, o peor, un error que aparece después del despliegue y no te das cuenta hasta la mañana siguiente.

En aplicaciones web a medida, sobre todo las que mueven negocio real (ecommerce, plataformas SaaS, sistemas de gestión internos), esos minutos de inactividad pueden significar ventas perdidas, usuarios cabreados y explicaciones incómodas. Las estrategias de despliegue zero-downtime existen precisamente para evitar esto, y las dos más consolidadas son los despliegues blue-green y los canary releases.

Blue-green: dos entornos, un interruptor

La idea detrás del despliegue blue-green es sencilla y elegante. Mantienes dos entornos de producción idénticos, que por convención llamamos "blue" y "green". En todo momento, solo uno de ellos recibe el tráfico real de los usuarios.

Cómo funciona paso a paso

1. Punto de partida: el entorno blue está sirviendo tráfico. El green está parado o con la versión anterior.
2. Despliegue: subes la nueva versión al entorno green, que no tiene tráfico de producción. Si algo sale mal durante el despliegue, los usuarios ni se enteran.
3. Pruebas: ejecutas smoke tests, pruebas de integración y verificas los endpoints críticos contra el entorno green. Todo esto sin afectar a nadie.
4. El cambio: cuando estás satisfecho, cambias el balanceador de carga para que apunte al green en lugar del blue. Para el usuario, la transición es instantánea.
5. Vigilancia: durante un rato (media hora, unas horas, lo que te dé tranquilidad), monitorizas el entorno green buscando problemas que las pruebas automatizadas no hayan pillado.
6. Cierre: si todo va bien, el blue se prepara para el siguiente ciclo. Si algo falla, basta con devolver el balanceador al blue y vuelves a la versión anterior en segundos.

Lo bueno

• Rollback inmediato: volver atrás es cambiar un interruptor. Sin redesplegar, sin restaurar nada.
• Puedes probar a fondo antes de que ningún usuario vea la nueva versión.
• Fácil de entender: el modelo es tan claro que hasta las personas no técnicas del equipo lo pillan rápido.

Lo no tan bueno

• Pagas doble en infraestructura: necesitas recursos para mantener dos entornos completos de producción.
• La base de datos es un lío: si ambos entornos comparten la misma base de datos (que es lo habitual), las migraciones necesitan un cuidado especial.
• Todo o nada: cuando haces el cambio, el 100% del tráfico va a la nueva versión. Si hay un problema que solo aparece bajo carga real, todos tus usuarios lo sufren a la vez.

Canary releases: ir soltando cable poco a poco

Los canary releases son la alternativa para los que prefieren no jugársela con todo el tráfico de golpe. La idea es exponer la nueva versión primero a un porcentaje pequeño de usuarios e ir subiendo ese porcentaje conforme confirmas que todo va bien.

El proceso en detalle

1. Despliegue parcial: subes la nueva versión a un subconjunto de tu infraestructura. Puede ser una de cada diez instancias, o simplemente dirigir un 5% del tráfico a las instancias nuevas.
2. Comparación constante: mientras la versión canary recibe tráfico, comparas sus métricas con las de la versión estable: tasa de errores, latencia, uso de recursos, métricas de negocio como conversiones o flujos completados.
3. Subir gradualmente: si las métricas se mantienen sanas, incrementas el porcentaje. Del 5% al 25%, del 25% al 50%, del 50% al 100%.
4. Promover o retirar: si en cualquier momento las métricas se degradan, retiras la versión canary y todo el mundo vuelve a la versión estable. Si llega al 100% sin problemas, ya tienes tu nueva versión en producción.

Lo bueno

• Riesgo acotado: si la nueva versión tiene un bug gordo, solo lo ve un 5% de los usuarios, no el 100%.
• Pruebas con tráfico real: hay problemas que solo aparecen con patrones de uso reales que las pruebas automatizadas no reproducen.
• Decisiones con datos: promueves o retiras basándote en métricas objetivas, no en corazonadas.

Lo no tan bueno

• Más complejidad: necesitas un balanceador que sepa repartir tráfico por porcentajes y una monitorización comparativa.
• Experiencia inconsistente: durante el despliegue, distintos usuarios pueden ver versiones distintas de la aplicación.
• Más lento: el proceso completo puede tardar horas o incluso días, dependiendo de lo conservador que seas con los incrementos.

Tabla comparativa: para los que quieren verlo de un vistazo

Criterio	Blue-Green	Canary
Velocidad de despliegue	Rápido (cambio instantáneo)	Gradual (minutos a horas)
Riesgo si falla	Alto (afecta a todos)	Bajo (porcentaje controlado)
Complejidad de montaje	Media	Alta
Coste de infraestructura	Alto (todo duplicado)	Medio (capacidad extra parcial)
Rollback	Instantáneo	Rápido (retirar instancias canary)
Validación con usuarios reales	No	Sí
Gestión de base de datos	Compleja	Compleja
Mejor para	Cambios grandes, bien testeados	Cambios frecuentes, validación progresiva

Lo que hacen muchos equipos en la práctica es combinar ambas: blue-green para cambios de infraestructura o migraciones gordas, y canary para el despliegue habitual de funcionalidades nuevas.

Qué necesitas a nivel de infraestructura

Un balanceador de carga que sepa hacer su trabajo

El balanceador de carga es la pieza clave. Para blue-green, necesitas poder cambiar el pool de servidores de destino. Para canary, necesitas enrutamiento por peso (weighted routing) que reparta un porcentaje del tráfico a un pool distinto.

Las opciones más habituales:

• NGINX con upstreams configurados con pesos.
• HAProxy con control dinámico de backends.
• AWS Application Load Balancer con grupos de destino ponderados.
• Envoy Proxy con configuración dinámica (ideal si vas por el camino del service mesh).
• Traefik con soporte nativo de canary mediante anotaciones en Kubernetes.

Orquestación de contenedores

Si tu aplicación va en contenedores Docker (y a estas alturas, probablemente sí), un orquestador te simplifica mucho la vida:

• Kubernetes te da mecanismos nativos para rolling updates y, con herramientas extra, soporte completo para blue-green y canary.
• Docker Swarm tiene rolling updates básicos pero para blue-green o canary necesitas montártelo más a mano.
• Amazon ECS integra despliegues blue-green con AWS CodeDeploy de serie.

Cómo montarlo en Kubernetes

Kubernetes es donde más equipos implementan estas estrategias hoy en día, así que merece la pena entrar en detalle.

Blue-green con Services

La forma más directa es mantener dos Deployments (blue y green) y un Service que apunte a uno de ellos con selectores de etiquetas:

1. Creas el Deployment blue con la etiqueta version: blue.
2. Creas el Service apuntando a version: blue.
3. Despliegas el Deployment green con la etiqueta version: green.
4. Validas el green con un Service temporal o un port-forward.
5. Cambias el selector del Service principal de version: blue a version: green.

Así de simple. El rollback es cambiar el selector de vuelta.

Canary con Argo Rollouts

Argo Rollouts es una extensión de Kubernetes que añade soporte nativo para canary y blue-green con análisis automatizado. Te permite definir la estrategia de forma declarativa:

• Qué porcentaje de tráfico en cada paso.
• Cuánto tiempo dura cada paso.
• Qué métricas evaluar para la promoción automática (integrando con Prometheus, Datadog o New Relic).
• Qué hacer si las métricas se degradan (rollback automático).

Alternativas similares son Flagger (del proyecto Flux) e Istio con sus capacidades de traffic management.

En los proveedores cloud: cada uno lo hace a su manera

AWS

• Elastic Beanstalk tiene despliegues blue-green nativos con swap de entornos.
• CodeDeploy permite configurar canary con porcentajes y tiempos.
• ECS con ALB combina grupos de destino ponderados para distribuir tráfico.

Google Cloud

• Cloud Run soporta traffic splitting de serie: puedes mandar un porcentaje del tráfico a una nueva revisión.
• GKE usa las mismas herramientas de Kubernetes que hemos visto.

Azure

• App Service tiene deployment slots con routing porcentual integrado.
• AKS con Argo Rollouts o Flagger para estrategias avanzadas.

La base de datos: donde todo se complica

El punto más delicado de cualquier despliegue zero-downtime es la gestión de cambios en la base de datos. Tu código puede correr en dos versiones al mismo tiempo sin problema, pero la base de datos es una sola y es compartida.

Reglas de oro para migraciones compatibles

• Compatibilidad en ambas direcciones: cada migración debe funcionar tanto con la versión nueva como con la anterior de la aplicación. No puedes borrar una columna que la versión anterior todavía usa.
• Primero añade, luego quita: añadir columnas, tablas o índices es seguro. Eliminar o renombrar requiere hacerlo en dos fases: primero dejas de usar el elemento en la aplicación, y en una migración posterior lo eliminas.
• Expand-and-contract: este patrón consiste en expandir el esquema (añadir la nueva estructura), migrar los datos, actualizar la aplicación para que use lo nuevo, y finalmente contraer el esquema (quitar lo antiguo).

Herramientas que te ayudan

• Flyway y Liquibase para Java.
• Alembic para Python con SQLAlchemy.
• Knex.js o Prisma Migrate para Node.js.
• Django Migrations para Django.

Todas versionan las migraciones y las aplican en orden, pero la responsabilidad de diseñar migraciones compatibles con zero-downtime es tuya y de tu equipo.

Rollback: el plan B que siempre tiene que funcionar

Una estrategia de despliegue sin un plan de rollback claro no es una estrategia, es una apuesta. Y las apuestas en producción salen caras.

• Blue-green: rollback instantáneo. Cambias el balanceador al entorno anterior y listo. Es la reversión más rápida y segura que existe.
• Canary: rollback rápido. Retiras las instancias canary y todo su tráfico vuelve a las instancias estables.
• Rolling update en Kubernetes: puedes deshacer un rollout con kubectl rollout undo y vuelves a la revisión anterior del Deployment.

En todos los casos, recuerda que si aplicaste migraciones de base de datos, el rollback de la aplicación solo funciona si esas migraciones son compatibles hacia atrás (como debería ser si sigues las reglas de oro que hemos visto).

Feature toggles: desplegar no es lo mismo que lanzar

Los feature toggles (o feature flags) te permiten separar dos cosas que normalmente van juntas: desplegar código nuevo y activar una funcionalidad nueva. Puedes subir el código a producción con la funcionalidad desactivada y encenderla cuando quieras, para quien quieras.

Esto complementa muy bien las estrategias blue-green y canary:

• Despliegas la nueva versión con la funcionalidad apagada.
• La activas gradualmente para segmentos específicos de usuarios.
• Si detectas problemas, la apagas al instante sin necesidad de hacer rollback.

Herramientas como LaunchDarkly, Unleash (open source) o Flagsmith gestionan feature toggles a escala. Para una aplicación web a medida en sus primeras fases, una tabla en la base de datos con una interfaz de administración puede ser más que suficiente.

Monitorización durante el despliegue: no despliegues a ciegas

Desplegar sin monitorizar es como cruzar una carretera con los ojos cerrados. Puede que llegues al otro lado, pero no es el método recomendado.

Las métricas que debes vigilar durante y después de un despliegue:

• Tasa de errores HTTP (4xx y 5xx): cualquier subida respecto a la línea base merece una investigación.
• Latencia de respuesta (p50, p95, p99): presta especial atención a los percentiles altos. Puede que la media esté bien pero el p99 se haya disparado.
• Uso de recursos (CPU, memoria, conexiones a base de datos): la nueva versión podría tener fugas de memoria o consultas que no escalan bien.
• Métricas de negocio: tasa de conversión, flujos completados, errores de pago. Estas métricas capturan problemas funcionales que las métricas técnicas podrían no reflejar.
• Logs de error: nuevos tipos de error o incrementos inusuales en errores que ya existían.

Para canary releases, la comparación automática de métricas entre la versión canary y la estable (lo que se llama canary analysis) te permite decidir si promover o retirar basándote en datos, no en sensaciones.

Un ejemplo de la vida real: pipeline completo

Pongamos un caso concreto. Tienes una aplicación web a medida de gestión de pedidos y quieres desplegar una nueva funcionalidad de cálculo de descuentos. Tu pipeline podría ser así:

1. El desarrollador fusiona el código en la rama principal. La funcionalidad de descuentos va detrás de un feature toggle, apagada por defecto.
2. El pipeline de CI ejecuta tests unitarios, de integración y de contrato.
3. Se construye la imagen Docker y se sube al registro de contenedores.
4. Argo Rollouts arranca un canary en Kubernetes: el 5% del tráfico va a la nueva versión.
5. Durante 15 minutos, Prometheus compara las métricas de la versión canary con las de la versión estable.
6. Si todo está en orden, el tráfico sube al 25%, luego al 50%, luego al 100%.
7. Con el 100% del tráfico en la nueva versión, el equipo enciende el feature toggle de descuentos para el 10% de los usuarios.
8. Se monitorizan las métricas de negocio durante 24 horas.
9. Si todo va bien, se enciende el toggle para el 100% de los usuarios.

Este enfoque combina canary releases para gestionar el riesgo del despliegue con feature toggles para gestionar el riesgo del lanzamiento funcional. Dos capas de seguridad que se complementan.

Conclusión

Los despliegues blue-green y los canary releases no son cosas de empresas gigantes con equipos de plataforma de veinte personas. Son prácticas perfectamente accesibles para cualquier aplicación web a medida que corra en contenedores o en un proveedor cloud moderno. Lo que inviertes en infraestructura y automatización se recupera rápido en forma de despliegues más frecuentes, menos sustos en producción y un equipo que no le tiene miedo a poner código nuevo en producción un viernes.

Empieza por lo simple. Un blue-green básico con dos entornos y un cambio manual de balanceador ya te quita el problema del downtime. A partir de ahí, ve evolucionando hacia canary releases automatizados con análisis de métricas y rollback automático. No hace falta tenerlo todo desde el día uno.

Si quieres montar una estrategia de despliegue zero-downtime para tu aplicación web a medida y necesitas que alguien te ayude con la arquitectura, las herramientas o el proceso, Contacta con Tangram Consulting y diseñamos juntos un pipeline de despliegue que se ajuste a tu contexto técnico y operativo.