Blue-Green Deployment: la estrategia DevOps para cero tiempo de inactividad

Cuando empecé a trabajar como ingeniero de MLOps, tuve que desplegar una pequeña aplicación que incluía un modelo de ML para clasificación de imágenes. El primer despliegue fue bien. Pero cuando actualicé el modelo, empezó el caos. Para empezar, el Pod que alojaba mi nuevo modelo no arrancaba por diferencias entre mi entorno de pruebas y el de producción. Además, la gente no podía trabajar porque el Pod con el modelo antiguo ya se había sustituido por mi Pod nuevo, que ni siquiera arrancaba. Fue una pesadilla. Tuve que hacer un rollback manual y disculparme con quienes usaban ese modelo. 

Aprendí la lección y me pasé a la estrategia de despliegue blue-green. Este enfoque DevOps permite publicar actualizaciones sin interrupciones ni rollbacks de madrugada. 

En esta guía te cuento cómo funciona el blue-green deployment en la práctica: cómo montarlo, los compromisos, lo que no sale en la documentación. Tanto si creas servicios de ML, APIs o aplicaciones full‑stack, este enfoque le da a tu equipo la red de seguridad que necesita para lanzar nuevas funciones con confianza.

Entendiendo el blue-green deployment

El blue-green deployment suena más complicado de lo que es (al menos a mí me lo pareció cuando lo oí por primera vez). 

Es un truco inteligente para publicar nuevas versiones sin molestar a los usuarios. Lo consigue manteniendo dos entornos de producción idénticos y conmutando el tráfico entre ellos. 

Si alguna vez te ha pasado que tu aplicación funcionaba en staging pero se caía en producción, esta estrategia es para ti.

Arquitectura clave y mecánica operativa

La idea básica: mantienes dos entornos de producción idénticos. Uno se llama blue y el otro green.

El blue es el entorno con el que interactúan los usuarios en ese momento. Cuando tienes una nueva versión que quieres publicar, la despliegas en el entorno green, la pruebas y, cuando estás seguro de que funciona, rediriges el tráfico de producción del blue al green.

Con esta estrategia no hay tiempo de inactividad ni mensajes de «estamos actualizando». Es una transición invisible que pasa entre bambalinas y que la gente ni nota.

En la práctica, la magia sucede en el balanceador de carga. Lo configuras para enrutar el tráfico a uno u otro entorno según el estado del despliegue. Te da control fino del tráfico y hace que revertir sea tan fácil como volver a enviar el tráfico al entorno blue. 

Esta estrategia resuelve el famoso «en staging iba» que me pasó con mi nuevo modelo de ML. Como el entorno green también es de producción, estás probando en el mundo real antes de que lo usen los usuarios.

Resumen rápido del flujo típico: 

1. Despliega la nueva versión en green.
2. Ejecuta tests de integración y smoke tests.
3. Cambia el tráfico con el balanceador de carga. 
4. Monitoriza el green por si hay anomalías.
5. Si todo va bien, apaga blue o consérvalo por si necesitas revertir.

Blue-green deployment, fase 1: aplicación nueva en green para pruebas; el tráfico sigue en blue (Imagen del autor).

Blue-green deployment, fase 2: tráfico redirigido al entorno green (Imagen del autor). 

Evolución histórica y adopción en la industria

El enfoque blue‑green fue nombrado y utilizado en ThoughtWorks hacia 2005 por Daniel Terhorst‑North y Jez Humble. Se documentó y popularizó más tarde en el libro Continuous Delivery (2010) de Jez Humble y Dave Farley.

Desde entonces se usa en todas partes, desde startups hasta gigantes cloud‑native como Netflix y cualquier organización que despliega varias veces al día sin dramas.

Las plataformas en la nube aceleraron este cambio. Con infraestructura como código, grupos de autoescalado y orquestadores de contenedores como Kubernetes, levantar y mantener entornos duplicados se volvió sencillo.

El blue-green deployment incluso inspiró otros modelos de despliegue, como los canary releases y los feature flags. Si entiendes blue‑green, tienes la base para entender los demás.

¿Nuevo en DevOps? Empieza con el curso DevOps Concepts. Una base clara y práctica para entender las estrategias clave antes de pasar a flujos avanzados.

Principales beneficios del blue-green deployment

Sinceramente, la primera vez que oí hablar de blue‑green me pareció un sinsentido mantener dos entornos de producción. Pero vi lo fácil que era desplegar nuevos modelos de ML y cómo disminuían las quejas y las escaladas, y entendí que merecía la pena.

En los siguientes apartados destaco sus beneficios.

Casi cero tiempo de inactividad

Este es el más evidente: nadie quiere caídas.

Con blue‑green puedes cambiar el tráfico al instante del entorno antiguo al nuevo sin pasar por servicios degradados. Tus usuarios no notan el cambio, que es justo lo que buscas.

Es un antes y un después cuando ejecutas APIs de cara al usuario, paneles o canalizaciones de ML que no se pueden permitir ni unos minutos de interrupción.

Rollbacks sencillos

Imagina que publicas una nueva versión y, a los pocos minutos, descubres que lanza muchos errores 500. Con blue‑green puedes volver a apuntar el balanceador al entorno blue y arreglarlo sin prisa.

Ese nivel de seguridad anima a los equipos a publicar a menudo. Se acabó el «si funciona, no lo toques».

Pruebas seguras en producción

Puedes probar en producción sin exponer a los usuarios a riesgos. Esa es la gracia del entorno green. Puedes ejecutar pruebas de carga, cheques de integración e incluso simular comportamientos de usuario antes de que llegue tráfico real.

A diferencia de un staging tradicional, pruebas sobre la misma infraestructura, configuración y demás.

Esto hace que las pruebas reflejen mucho mejor la realidad.

Soporte para A/B testing y despliegues graduales

Una vez tienes dos entornos de producción idénticos, puedes ir más allá. Por ejemplo, enrutar el 90% del tráfico a la versión blue y el 10% a la green. 

También puedes integrar feature flags para controlar qué funciones se activan, cuándo y para quién, con blue‑green como base de despliegue subyacente. 

Si quieres profundizar en entregas progresivas, echa un vistazo a CI/CD in Data Engineering. Explica cómo configurar canalizaciones que soporten A/B testing y lanzamientos graduales.

Mejor experiencia de usuario y continuidad del negocio

El blue‑green deployment ayuda a:

• Exponer menos errores a los usuarios.
• Aumentar la rapidez de respuesta de ingeniería ante incidencias.
• Simplificar la restauración de copias de seguridad

Si despliegas servicios de machine learning críticos o herramientas internas de datos de las que depende la gente cada día, esto importa, y mucho.

Planificación del blue-green deployment

Antes de implantarlo, conviene entenderlo bien a fondo.

Veamos qué necesitas en arquitectura, costes y preparación interna.

Requisitos de infraestructura

Necesitas dos entornos de producción idénticos. Es decir, doble de configuración y doble de mantenimiento.

Pero que no cunda el pánico por los costes: no significa pagar el doble todo el tiempo. En nubes o con Kubernetes, puedes levantar recursos para el green solo cuando los necesites y apagarlos después.

Herramientas que ayudan a montar los dos entornos:

• Infraestructura como código (p. ej., Terraform) para replicar entornos rápidamente.
• Gestión de configuración para evitar problemas por deriva de configuración.
• En Kubernetes, utiliza namespaces u objetos de Deployment distintos para blue y green.

Además, ten en cuenta que en on‑prem todo se complica, porque tendrás que asegurar que:

• Los balanceadores de carga permiten conmutar el tráfico al instante.
• Puedes aprovisionar entornos rápido (quizá con virtualización o contenedores).
• Las dependencias externas (BBDD, APIs, etc.) están sincronizadas y aisladas.

Puedes consultar la comparativa de servicios de AWS, Azure y GCP para decidir qué te resulta más sencillo en tu plataforma.

Análisis coste-beneficio

Los escépticos siempre señalan el aumento de costes al mantener dos entornos de producción. Y sí, no es gratis. Pero hay que equilibrar el coste del segundo entorno con el coste que tiene una caída para tu negocio. 

Pregúntate:

• ¿Cuál es el impacto medio (en tiempo o dinero) de un despliegue fallido?
• ¿Cuántas horas lleva depurar, revertir y explicar la caída?
• ¿Con qué frecuencia publicas con presión, esperando que no se rompa?

Ahí está la gran baza de blue‑green: menos caídas, iteraciones más rápidas y menos presión y burnout en ingeniería. 

Consejos para optimizar costes:

• Usa autoescalado para dimensionar el entorno green según la carga de pruebas.
• Elige instancias spot o VMs efímeras para el entorno green.
• Ejecuta la versión green en un namespace de Kubernetes separado y escálala a cero tras el cambio.

Una canalización CI/CD bien configurada puede encargarse de este escalado automáticamente.

Requisitos previos y preparación organizativa

Esta parte suele pasarse por alto, pero es clave.

Aunque tengas presupuesto para infraestructura y herramientas, el blue‑green no funcionará si tu cultura y sistemas no están listos.

Vas a necesitar: 

• Flujos CI/CD: canalizaciones que puedan desplegar y probar en green de forma independiente.
• Monitorización y observabilidad: debes revisar métricas antes de conmutar de blue a green.
• Estrategia de rollback clara: idealmente automatizada y practicada.
• Alineación transversal: Desarrollo, Operaciones, QA y Producto deben comprender el proceso.

Si no tienes claro en qué punto está tu equipo, plantéate CI/CD for Machine Learning. Ofrece una visión completa de cómo es un despliegue maduro y cómo llegar ahí.

Implementación técnica

Hasta ahora hemos visto por qué usar blue‑green. En esta sección te enseño a implementarlo. 

Desgloso un ciclo de vida típico de despliegue blue‑green, con foco en el reto de gestionar bases de datos.

Verás qué automatizar, qué monitorizar y qué no debes saltarte.

Ciclo de despliegue estándar

Un blue‑green bien implantado sigue un orden preciso. Suele verse así en la práctica:

1. Aprovisiona un entorno green: levanta un entorno de nivel producción que refleje tu entorno actual (blue), ya sea en la nube, on‑prem o con Kubernetes.
2. Despliega la nueva versión en green: tu pipeline de CI/CD debe construir y desplegar el código aquí, idealmente etiquetándolo como release candidate.
3. Ejecuta tests automatizados: smoke tests, integraciones y sondas de salud que simulen el uso. Compruebas si green está listo para tus usuarios.
4. Monitoriza logs y métricas: si tus paneles están limpios y no hay alertas, adelante. Si no, corrige e intenta de nuevo en green.
5. Cambia el tráfico a green: reconfigura el balanceador para enrutar todo el tráfico al servidor green.
6. Desactiva blue: cuando estés seguro de green, apaga blue o consérvalo como backup hasta el próximo release.

Haz que el rollback sea tan rápido como el rollout, de modo que cualquiera del equipo pueda revertir en menos de un minuto.

La guía CI/CD in Data Engineering es un excelente recurso para automatizar estas fases.

Estrategias de sincronización de bases de datos

Esta parte es delicada. Tu app puede ser stateless, pero tu base de datos no. 

Si no la gestionas bien, no podrás revertir con facilidad y pierdes el sentido del blue‑green deployment.

Así puedes manejarlo:

1. Diseña con compatibilidad hacia atrás: durante el cambio, puede que los usuarios sigan tocando el entorno blue durante unos milisegundos. Tu esquema debe funcionar para ambas versiones en ese periodo. 
1. No elimines ni renombres campos de inmediato.
2. Añade nuevas columnas/tablas y usa valores por defecto.
3. Evita restricciones duras hasta que ambas versiones soporten el cambio.
2. Versiona tus migraciones: usa herramientas como Flyway o Liquibase en sistemas Java o Alembic con Python + SQLAlchemy. 
3. Gestiona el estado de sesión: si tu app guarda la sesión en memoria, cambiar de entorno puede desconectar a la gente o romper funciones. Usa Redis, Memcached o una BBDD compartida para evitarlo.
4. Valida la consistencia de datos tras el cambio: automatiza comprobaciones sobre datos críticos.
1. ¿La gente puede iniciar sesión? 
2. ¿Se guardan los cambios recientes? 
3. ¿La canalización de analítica sigue ingiriendo correctamente?
5. Vigila derivas sutiles: a veces los cambios no lanzan errores y parecen funcionar, pero causan problemas sutiles como retrasos en el procesado de eventos o registros mal formados. Usa logging y observabilidad para detectarlos cuanto antes.

Si te interesa aplicar MLOps en producción, te recomiendo el curso MLOps Deployment and Life Cycling.

Análisis comparativo con otras estrategias de despliegue

Blue‑green se usa a menudo como base de otras estrategias, con variaciones para abordar distintos aspectos del proceso de despliegue. 

Según tu arquitectura, frecuencia de releases y tolerancia a la complejidad, valora alternativas o incluso combinarlas.

Comparemos el caso más común: blue‑green vs. canary.

Blue-green vs. despliegues canary

A menudo se mezclan, pero persiguen metas distintas.

Blue‑green es un cambio completo: despliegas en green, lo pruebas y, cuando estás listo, pasas el 100% del tráfico.

Canary es un cambio gradual: despliegas la nueva versión junto a la antigua y vas moviendo un porcentaje pequeño de tráfico (1%, luego 10%, luego 50%) mientras monitorizas posibles problemas.

Diferencias clave entre ambas:

Yo he usado blue‑green para llevar nuevos modelos de ML a producción, pero con una base de usuarios limitada. Si hubieran sido masivos, seguramente habría preferido canary.

Compromisos de infraestructura y operación

Ambas estrategias requieren buenas herramientas, pero su complejidad está en áreas distintas.

Blue‑green necesita entornos idénticos, lo que aumenta los costes de infraestructura. Sin embargo, el enrutado es simple: cambiar tráfico de un entorno a otro. 

Canary es más ligero en infraestructura, pero exige más lógica para el cambio gradual de tráfico. También requiere observabilidad más detallada para detectar problemas cuanto antes.

Otros factores a considerar: 

• Monitorización: canary requiere métricas granulares (p. ej., latencia por usuario o por petición); blue‑green solo necesita saber si la app está sana. 
• Herramientas de automatización: Argo Rollouts soporta ambos modelos en Kubernetes, pero canary requiere más configuración.
• Tiempo de despliegue: blue‑green es rápido. Canary es más cauto y lleva más tiempo.

Entonces, ¿qué te conviene?

Si tu equipo aún está madurando en CI/CD, blue‑green puede ser la mejor forma de ganar confianza. También es un buen punto de partida para acumular experiencia. 

Si tienes una gran base de usuarios o despliegas cambios de alto riesgo (como lógica de precios), canary puede encajar mejor.

Para equipos centrados en Azure, el Azure DevOps Tutorial muestra cómo implantar un buen CI/CD en Azure.

Implementaciones específicas por plataforma

Basta ya de teoría. Vamos a lo técnico. Veamos cómo se implementa blue‑green deployment en las plataformas que los equipos de datos usan a diario: Kubernetes, servicios gestionados en la nube y herramientas de automatización.

Cada una ofrece funciones distintas, pero la idea central es la misma: dos entornos idénticos y un conmutador de tráfico.

Patrones de orquestación en Kubernetes

Implementar blue‑green con Kubernetes es directo: ya trae todo lo necesario. 

Hay varias formas de montarlo:

• Deployments separados: despliega my-app-blue y my-app-green como deployments distintos, compartiendo labels y services.
• Un solo objeto de Deployment con revisiones: menos común, posible con anotaciones para rastrear versiones.
• Namespaces: ejecuta blue y green en namespaces separados para aislamiento total.

La pieza clave aquí es el Service de Kubernetes. Actúa como balanceador, dirigiendo tráfico a pods blue o green mediante selectores de etiquetas.

Imagina que tienes:

selector:  version: blue

Tras validar la versión green, actualizas el selector del service a version: green y el tráfico se redirige al instante.

Te recomiendo usar readinessProbes para asegurarte de que la nueva versión está lista antes de enrutar tráfico.

Este proceso se puede automatizar con herramientas como Argo Rollouts y Flagger, que gestionan:

• Cambio progresivo de tráfico
• Comprobaciones de salud y monitorización
• Rollbacks automáticos si algo falla

¿Quieres profundizar en la infraestructura centrada en ML? Mira Fully Automated MLOps.

Servicios gestionados cloud‑native

Si usas AWS, Azure o GCP, la buena noticia es que el blue‑green ya viene integrado: solo tienes que activarlo.

AWS CodeDeploy (con Elastic Beanstalk o EC2):

• Ofrece estrategia dedicada de blue‑green deployment
• Defines qué entorno es green y CodeDeploy gestiona el cambio de tráfico y el rollback

Azure Container Apps o Azure App Service:

• Permite preparar versiones como «slots» y conmutarlas sin tiempo de inactividad
• Combínalo con pipelines de Azure DevOps para CI/CD completo

Google Cloud (Cloud Run o GKE):

• Cloud Run admite división gradual de tráfico entre revisiones: ideal para pruebas y lanzamientos
• Con GKE, usa reglas del balanceador o Istio para gestionar la lógica blue‑green

Cada proveedor tiene su configuración y funciones, pero todos te facilitan la vida: implementas menos por tu cuenta. 

Usar servicios gestionados además tiene la ventaja de no tener que mantenerlos tú: los proveedores actualizan y tú solo te ocupas de configurarlos bien.

¿Nuevo en GCP? Revisa Cloud Run: guía para desplegar apps en contenedores en GCP.

Ejemplo con Cloud Foundry y otras herramientas

Cloud Foundry es una plataforma como servicio (PaaS) de código abierto que abstrae gran parte de la infraestructura y permite centrarse en el código. Es popular en grandes empresas por su automatización, cumplimiento y rapidez de despliegue.

Así funciona un blue‑green típico en Cloud Foundry con la CLI oficial:

1. Publica la versión blue de tu app con el subdominio demo-time:

1. cf create-route example.com --hostname my-appcf push my-appcf map-route my-app example.com --hostname my-app

2. Blue ya está corriendo y el router envía todo el tráfico a my-app.example.com.
2. Publica la versión green de tu app con un nombre y ruta nuevos:

1. cf create-route example.com --hostname my-app-tempcf push my-app-greencf map-route my-app-green example.com --hostname my-app-temp

2. Ahora hay dos instancias en marcha, pero con dos rutas (my-app.example.com para blue y my-app-temp.example.com para green).
3. Asigna la ruta de producción a green:

1. bashcf map-route my-app-green example.com -n my-app

2. En este punto, blue y green están en vivo, pero el tráfico va a ambos salvo que elimines blue explícitamente.
4. Verifica la versión green. Puedes probarla por su ruta o monitorizar tráfico real tras el cambio.
5. Desasigna la ruta de blue para pasar del todo a green:

1. cf unmap-route my-app example.com -n my-app

2. El router deja de enviar tráfico a blue.
6. Elimina la app antigua y la ruta green (opcional pero recomendable):

cf delete my-appcf unmap-route my-app-green example.com --hostname my-app-temp

Este proceso minimiza el downtime y te da control total sobre cuándo y cómo cambias de versión.

Si quieres mejorar el flujo con pipelines visuales, aprobaciones manuales o rollback automático, herramientas como Octopus Deploy, Codefresh o Spinnaker son opciones sólidas. Se integran con CI/CD para automatizar ciclos de despliegue complejos.

Buenas prácticas y optimización

Blue‑green suena genial y ayuda mucho, pero puede volverse un lío si no gestionas bien costes, riesgos o automatización. He visto equipos sufrir por configuraciones demasiado complejas o casos límite inesperados. 

Veamos qué hacer para evitarlo y que tu estrategia sea un éxito.

Técnicas de control de costes

Duplicar entornos, claro, cuesta dinero. 

Pero puedes minimizarlo con estas estrategias:

• Autoescalado: usa horizontal pod autoscalers o autoscaling nativo cloud para ajustar a la carga real y evitar despilfarro.
• Instancias spot y preemptibles: ideales para el green si solo estás probando (y aceptas posibles interrupciones).
• Aprovisionamiento temporal: no mantengas el green más de lo necesario. Levántalo con CI/CD y elimínalo después.
• Contenerización: ligera, rápida y rentable, sobre todo en Kubernetes o Azure Container Apps.

Marcos de validación automatizada

Nunca deberías conmutar el tráfico sin estar completamente seguro de que tu aplicación green funciona como debe. 

Usa estas capas de pruebas para ganar confianza antes del cambio:

• Smoke tests: ¿están vivos y sanos los endpoints clave?
• Pruebas de integración: ¿funcionan los flujos core (auth, acceso a datos, etc.) en green?
• Pruebas end‑to‑end: simulan comportamiento real contra la ruta temporal de green (muy útil en Cloud Foundry y Azure).

Intégralas en tu CI/CD para que se ejecuten automáticamente tras un despliegue correcto.

¿Necesitas un repaso para montar estos flujos? CI/CD for Machine Learning cubre cómo estructurar validaciones automatizadas en tu ciclo de despliegue.

Metodologías de migración de bases de datos

Aquí está la trampa: tu app puede correr en dos entornos, pero la base de datos suele ser la misma para ambos. 

Cómo transicionar con seguridad:

• Cambios de esquema retrocompatibles: asume siempre que la versión blue puede seguir usando la BBDD cuando green se active.
• Feature toggles: activa funciones dependientes del esquema solo después de desplegar el nuevo esquema.
• Migraciones versionadas: herramientas como Flyway, Alembic o Liquibase permiten cambios trazables y reversibles.
• Consistencia de sesión/datos: si dependes del estado de sesión, usa almacenes externos (como Redis) compartidos por ambos entornos.

Feature flags y entrega progresiva

Combinar blue‑green con feature flags da aún más flexibilidad.

Con flags puedes:

• Lanzar nuevas funciones a un subconjunto de usuarios dentro del entorno green
• Desplegar funciones pero mantenerlas ocultas
• Probar con seguridad casos límite o impacto en rendimiento sin exponer todo el conjunto

Usa herramientas como LaunchDarkly, ConfigCat o Unleash para simplificar la gestión sin tocar código.

Observabilidad y monitorización sólidas

Monitorización y observabilidad son cruciales para conmutar con seguridad: te permiten evaluar si green está listo para sustituir a blue.

Deberías tener: 

• Health checks: readinessProbes de Kubernetes, URLs de revisión en Azure, etc.
• Logging: centralizado, con búsqueda y etiquetado por entorno (blue vs. green).
• Alertas: umbrales y avisos si suben las tasas de error.
• Análisis de tráfico: compara comportamiento entre blue y green (latencia, error rate, throughput).

Aun así, una observabilidad sólida debería formar parte de tu infraestructura uses o no blue‑green.

Plan de rollback y recuperación ante desastres

A veces las cosas se tuercen. El objetivo es recuperarte lo más fácil y rápido posible. 

Cómo lograrlo:

• Rollback instantáneo: mantén siempre blue activo hasta verificar que green es estable.
• Disparadores de rollback automáticos: usa Argo Rollouts o Spinnaker para revertir si fallan métricas clave.
• Runbooks y playbooks: pasos predefinidos para que todo el equipo sepa qué hacer.

Para más consejos prácticos de automatización DevOps, consulta el Azure DevOps Tutorial.

Refuerzo de seguridad

Tener dos entornos implica dos posibles puntos de ataque.

Algunas sugerencias para una seguridad adecuada:

• Aísla entornos: subredes, namespaces o grupos de recursos cloud separados.
• Rota secretos con frecuencia: especialmente si compartes credenciales entre blue y green.
• Aplica parches en ambos entornos: que green no se quede atrás en actualizaciones por no estar en producción aún.
• Audita logs: registra eventos de despliegue y cambios de entorno para trazabilidad.

Conclusión

El blue‑green deployment no es un capricho de procesos sobre‑ingenierizados. Es una estrategia práctica y fiable para equipos que priorizan disponibilidad, feedback rápido y dormir tranquilos.

Te aporta:

• Rollbacks instantáneos cuando algo falla
• Pruebas de nivel producción sin riesgo para usuarios reales
• Releases más limpios y seguros, incluso en viernes (no es broma)

¿Es perfecto para cualquier situación? Diría que no. Necesitas un CI/CD sólido y herramientas que lo soporten. Si no, puede complicarse.

Pero no es motivo para evitarlo: es una señal de que debes mejorar tus prácticas de despliegue.

Nosotros mejoramos drásticamente nuestro flujo de releases adoptando blue‑green y desde entonces los días de despliegue son mucho más tranquilos, hasta el punto de lanzar en viernes con total confianza.

Si quieres profundizar, empieza por DevOps Concepts o MLOps Deployment and Life Cycling, que te ayudarán a construir la base sobre la que se apoya blue‑green.

Ahora, a publicar tu aplicación con confianza.