Despliegues blue-green vs. canary — ¿en qué se diferencian realmente y cómo elijo entre ellos?
Ambas estrategias prometen despliegues más seguros, pero blue-green cambia entornos completos al instante mientras canary desplaza el tráfico poco a poco — la elección cambia qué se rompe y qué tan rápido.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
Despliegues blue-green vs. canary — ¿en qué se diferencian realmente y cómo elijo entre ellos?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#La idea central
Blue-green y canary existen para responder la misma pregunta: ¿cómo despliego una versión nueva de un servicio sin romper producción para todo el mundo a la vez? Cada estrategia responde con una mecánica muy distinta, y entender por qué existe cada mecánica —no solo su nombre— es lo que distingue una respuesta memorizada de una respuesta real en una entrevista.
#Blue-green: un intercambio instantáneo, todo o nada
En un despliegue blue-green mantienes dos entornos de producción completos e independientes: blue, que actualmente sirve todo el tráfico en vivo, y green, que está inactivo. Despliegas la versión nueva por completo en green, corres smoke tests y health checks contra él de forma aislada, sin exponer a ningún usuario real, y solo entonces cambias el router, el load balancer o el registro DNS para que el 100% del tráfico se mueva a green en un solo paso atómico. Blue se mantiene caliente y sin tocar durante un periodo de observación, así que si algo falla después del cambio puedes volver atrás instantáneamente: sin volver a desplegar, sin esperar a que un rollout gradual se revierta solo.
El costo es la infraestructura y la forma del radio de impacto: estás corriendo dos entornos completos de tamaño producción, al menos temporalmente, y en el momento del cambio, absolutamente todos los usuarios quedan en el código nuevo de manera simultánea. No hay gradiente de exposición: descubres un bug durante los smoke tests previos al cambio, o te enteras con el 100% del tráfico de golpe.
#Canary: un despliegue gradual, ponderado por tráfico
Un despliegue canary mantiene corriendo la versión anterior ("estable") y enruta solo una porción pequeña del tráfico en vivo —1%, 5%, lo que decidas— hacia la versión nueva. Luego observas tasas de error, latencia y métricas de negocio antes de decidir si aumentas el porcentaje (25%, 50%, 100%) o abortas y drenas el tráfico de vuelta a cero. El nombre viene del canario en la mina de carbón: un pequeño número de usuarios reales absorbe el riesgo para que el resto de tu tráfico no tenga que hacerlo.
La verdadera fortaleza del canary es detectar la clase de bugs que solo aparecen bajo patrones reales de tráfico de producción: una fuga de memoria que solo se manifiesta después de una hora de presión del garbage collector, una condición de carrera que solo se dispara con cierta mezcla de peticiones, una dependencia downstream que se comporta distinto bajo carga parcial de lo que hizo en staging. El cambio instantáneo y total de blue-green no puede detectar nada de eso a tiempo; el canary existe precisamente para detectarlo mientras el radio de impacto todavía es pequeño.
#Comparando ambas estrategias
| Dimensión | Blue-green | Canary |
|---|---|---|
| Cambio de tráfico | Instantáneo, 100% de una vez | Gradual, por porcentajes ponderados |
| Costo de infraestructura | Dos entornos completos, temporalmente | Capacidad anterior más una porción nueva y creciente |
| Velocidad de rollback | Instantánea — se revierte el switch | Rápida, pero requiere drenar el tráfico primero |
| Detecta bugs que solo aparecen con tráfico real | No — se descubren después del cambio completo | Sí — es exactamente su propósito |
| Complejidad de enrutamiento | Simple, un solo switch | Necesita enrutamiento ponderado: service mesh, load balancer inteligente o feature flags |
| Mejor uso | Servicios sin estado, cambios de bajo riesgo, necesidad de rollback inmediato garantizado | Cambios riesgosos, necesidad de confianza estadística, buena observabilidad ya instalada |
#Ambas siguen necesitando datos compatibles hacia atrás
Esto es lo que más se les escapa a los candidatos: en ambas estrategias, el código viejo y el nuevo pueden leer y escribir la misma base de datos al mismo tiempo —en blue-green, durante la ventana del cambio y cualquier periodo en que el entorno anterior se mantenga caliente; en canary, durante toda la rampa—. Eso significa que los cambios de esquema deben seguir un patrón de expandir-contraer: agregar la columna nueva como nullable, desplegar código que escriba ambas formas, rellenar los datos históricos y solo después —cuando toda versión que lee la tabla ya esté actualizada— eliminar la columna vieja. No puedes desplegar una migración de esquema incompatible junto con ninguna de las dos estrategias asumiendo que la ventana de solapamiento es "demasiado corta para importar."
#Eligiendo en la práctica
Lo que realmente evalúa un entrevistador es si recurres al canary por defecto para cualquier cambio genuinamente riesgoso —un motor de precios nuevo, un algoritmo de recomendación reescrito, un cambio de proveedor de pagos— y reservas blue-green para cambios donde la velocidad y la simplicidad importan más que la exposición gradual al riesgo: un cambio de configuración, un parche bien probado, o cualquier despliegue donde tu plan de rollback necesite ser "inmediato" en vez de "vamos a drenar tráfico y ver." Muchas plataformas maduras combinan ambas: infraestructura blue-green para garantizar rollback instantáneo, con una rampa de porcentaje estilo canary encima del entorno nuevo antes de que reciba el tráfico completo.
🧠 Check your understanding
0/2 · 0/2 answered1. ¿Cuál es la ventaja principal de un despliegue canary frente a uno blue-green?
2. ¿Por qué tanto blue-green como canary requieren cambios de esquema de base de datos compatibles hacia atrás?