Los lanzamientos Blue-Green y Canary

(Sección: Arquitectura y Protocolos)

1) Por qué se necesitan «descargas seguras»

En los sistemas modernos, la liberación no es solo la entrega de código, sino también un experimento manejable en la venta: minimizamos al mismo tiempo el riesgo (no rompemos usuarios) y reducimos el tiempo de retroalimentación (vemos rápidamente el efecto). Dos estrategias clásicas - Blue-Green y Canary - lo resuelven de manera diferente, pero con un objetivo común: cero downtime, retroceso rápido, observabilidad por SLO.

2) Definiciones básicas

Blue-Green

Mantenemos dos copias completas del entorno prod: activo (Blue) sirve el tráfico, pasivo (Green) prepara una nueva versión. La conmutación es atómica (switch/flip) a nivel de equilibrador/enrutador. Si ha empeorado, volvemos instantáneamente a Blue.

Canary

Rodamos en partes: primero al pequeño% del tráfico (por ejemplo, 1-5%), observamos métricas/SLO, luego aumentamos paso a paso la proporción (10% → 25% → 50% → 100%). En la degradación, retroceder o detenerse en el paso estable anterior.

3) Cuando qué enfoque es mejor

• Se necesita un retroceso instantáneo sin maniobras complicadas.
• La arquitectura/presupuesto permite duplicaciones de infraestructura duales.
• Queremos realizar migraciones a gran escala o actualizaciones de plataformas (OS/JDK/rantime) de forma aislada.
• La aplicación/grupos de conexiones son sensibles al estado «mixto» gradual.

• Debe minimizar el blast radius y ver el comportamiento en la proporción de usuarios.
• Alta frecuencia de lanzamientos, entrega progresiva como norma.
• Hay una observabilidad madura y gatitas automáticas (error budget, latency, conversion).
• El equipo del producto quiere verificar las hipótesis: impacto en la conversión, retención, LTV, etc.

4) Principios generales para un lanzamiento exitoso

Artefactos Idempotent Build: la misma imagen/paquete en todas las etapas.
Configuración determinista: configuración como código, comparabilidad de entorno.
Observabilidad por diseño: registros, métricas, trazados, alertas; SLI/SLO por adelantado.
Retroceso rápido y automatizado: el botón/comando de retroceso es una parte de la paipline, no una magia manual.
Cambios de esquema compatibles: estrategia expand-migrate-contract (ver § 10).
Enrutamiento de nivel L7 (preferiblemente): flexibilidad para encabezados/cookies/rutas/versiones de API.

5) Blue-Green: arquitectura y proceso

5. 1 Topología

Dos pilas prod: Azul (activo) y Verde (candidato).
Dependencias externas comunes: CDN, API externas, colas; La DB es un caso especial (véase § 10).
Punto de conmutación: balanceador/Ingress/Gateway.

5. 2 Paso a paso flow

1. Levantamos el Verde bajo el nuevo artefacto (vNext), realizamos pruebas de smock.
2. Ejecución de autotestos contra Green (e2e, contrato, regresión).
3. Calentar caché/sesiones (si corresponde), sincronizar jobs/colas de fondo.
4. Cambie el tráfico a Green: flip atómico (DNS TTL bajo, Route/Listener swap, Ingress weight = 100%).
5. Observamos SLO en los primeros minutos/horas (señales de oro: latency, errors, saturation + métricas de negocio).
6. En caso de problemas, un retorno instantáneo a Blue (flip back).

5. 3 pros/contras

Ventajas: retroceso instantáneo, modelo mental simple, aislamiento puro.
Contras: duplicación de la infraestructura, complejidad con componentes stateful y migraciones de datos.

6) Canary: arquitectura y proceso

6. 1 Topología

Un único clúster prod; varias versiones del servicio (stable y canary) detrás de un solo frente.
El tráfico se divide por pesos (1-5-10-25-50-100%) o por objetivos (por título/cookie/ID).

6. 2 Paso a paso flow

1. Versión canaria deploy en el mismo clúster/ASG/NSG.
2. Enrutamiento de parte del tráfico (por ejemplo, 1-5%) en Canarias.
3. Comprobaciones automáticas de SLI/SLO y métricas de negocio; gates en CI/CD (error rate, p95 latencia, CPU/RES, conversión, rechazo/devolución).
4. Incrementando paso a paso la proporción de tráfico al pasar las gatitas.
5. Rollout completo hasta 100% y desactivación de la versión anterior; cuando la degradación es auto-rollback.

6. 3 pros/contras

Ventajas: riesgo mínimo para la mayoría de los usuarios, solución data-driven.
Contras: se necesita una observabilidad madura, un enrutamiento competente, el riesgo de «version skew» entre instancias.

7) Enrutamiento del tráfico

Nivel L4: balance de IP/puertos; simple, pero poca flexibilidad.
Nivel L7: reglas HTTP/S - en ruta, host, encabezado, cookies, agente de usuario, GeoIP, SNI.

• Ruta Weighted (pesos 1-100%).
• Header-based/Cookie-based (fijación del usuario en el grupo).
• Session stickiness (importante para scripts stateful/caché).
• Mirroring de Shadow/Traffic (espejamos las solicitudes en una nueva versión «apretada»).

8) Herramientas e implementaciones (ejemplos)

Kubernetes: Ingress (NGINX, Contour), Service Mesh (Istio/Linkerd), Argo Rollouts, Flagger.
Облака: AWS ALB/ELB, Route 53 weighted records, ECS/EKS; GCP Load Balancing + NEG; Azure Front Door/App Gateway.
Plataformas de CD: Spinnaker, Argo CD, GitHub Acciones + complementos de entrega progresiva, GitLab/CD.

9) Observabilidad, SLI/SLO y gates

Golden signals: Latency (p95/p99), Error rate (5xx/4xx по типам), RPS, Saturation (CPU/Memory/GC), Queue lag.
Métricas de negocio: conversiones, autorizaciones, pagos/aciertos, cheque promedio, denegación de pasos de embudo.

• Umbral de error (por ejemplo, error rate canary ≤ baseline + X%).
• La latencia p95 no es peor que la baselina en más de Δ.
• Umbral de negocio (por ejemplo, caída de la conversión
• Error budget por SLO no debe quemarse aceleradamente.

Duración del paso: tiempo mínimo suficiente para la significación estadística (depende del tráfico).

10) Migración de la DB y compatibilidad de esquemas

Regla principal: las versiones son seguras si las versiones de ida y vuelta son compatibles.

1. Expansión: agregamos nuevas columnas/índices/tablas sin romper la versión anterior.

2. Deploy app vNext (lee/escribe en el nuevo diagrama, pero también sabe trabajar con el antiguo).

3. Datos migratorios (fondo/batch, idempotente, con cecpoints).

4. Contrato: eliminamos los campos/fiches antiguos una vez estabilizados.

Anti-patrones: migraciones que requieren un bloqueo exclusivo en el momento de cambiar Azul-Verde; imposibilidad de downgrade del esquema; «doble registro» sin deduplicación.

11) Reversión (rollback) y planes de accidentes

Azul-Verde: flip instantáneo en Azul; monitorim «colas» de los jobs de fondo de Green.
Canario: retroceso de peso (por ejemplo, del 25% hacia atrás al 5% o 0%); abort automático con alertas.
Datos: una política de repetición/compensación bien pensada (idempotency keys, «inbox/outbox» patrón, deduplicación de mensajes).
Fichflags: Rápido kill switch para desactivar las capacidades parcialmente enrolladas.

12) Trabajar con el estate y las sesiones

Sesiones Sticky para Canarias, o almacenamiento de sesiones externamente (Redis/Memcached) para que las versiones sean intercambiables.
Calentar la caché con antelación (Green warm-up) y tener en cuenta la invalidación al flip.
Workers de fondo: no permita «carreras» entre versiones - separación de colas o «liderazgo» según la versión.

13) Seguridad y cumplimiento

Acceso a Green/Canary - por Zero Trust: cuentas de servicio, roles mínimos necesarios.
Secretos y claves: a través de KMS/Secrets Manager; habilita la rotación.
Tráfico - sólo TLS; las versiones de endpoint's están claramente marcadas; auditar el enrutamiento y las acciones de lanzamiento.

14) Costo y rendimiento

Blue-Green duplica la infraestructura (durante el tiempo de lanzamiento o en todo momento) - deposita tu presupuesto.
Canarias es más económica, pero requiere herramientas de observación y tiempo de ingeniería para la automatización.
Optimización: auto skaling, entorno ephemeral, reducción de la ventana de la existencia paralela de versiones.

15) Hojas de cheques

Antes de la versión

• La imagen/build es promocionada desde una sola fuente, las firmas son verificadas.
• El plan de prueba, las alertas y las getas SLO están configuradas.
• Migraciones DB - en modo expand, planes downgrade están disponibles.
• Plan de reversión: verificado en staging/production-like.

Durante la versión

• Las métricas y los registros se comparan con la baselina.
• Para Canarias: los pasos y umbrales están fijados; para Blue-Green - listo para flip-back.
• Los comandos on-call están al día, hay una ventana de retroalimentación.

Después de la versión

• SLO no se ha hundido, error budget es normal.
• Migraciones/limpiezas posteriores al lanzamiento completadas.
• Retrospectiva y actualización de los playbooks.

16) Errores frecuentes y anti-patrones

Desechar sin métricas: no hay datos - no hay una solución administrada.
Mezcla de esquemas de DB incompatibles, falta de estrategia de downgrade.
Agitación aleatoria del tráfico: sin stickiness, los usuarios «saltan» entre versiones.
Dependencias ocultas de estado (discos locales, cachés in-memory).
El DNS-TTL largo interfiere con el flip rápido (Azul-Verde).
Falta de autogates: las soluciones manuales «a la vista» frenan y aumentan los riesgos.

17) Enfoques combinados

Blue-Green + Canary: primero enrollar Green, luego dentro de Green enrollar Canary para servicios individuales.
Shadow/tráfico migratorio: Antes de Canary, ejecutamos el tráfico espejado en una nueva versión.
Flags de características (entrega progresiva): la funcionalidad se activa sobre una versión estable con banderas «oscuras» por segmentos.

18) Ejemplos de scripts (bocetos)

1. Desplegamos Green (v2) detrás del nuevo Listener/Ingress.

2. Calentamos las cachés, realizamos revisiones readonly, smoke.

3. Cambie el peso a Verde = 100%.

4. Observamos SLO durante 30-60 minutos; Si todo está bien, desactivamos Blue.

1. Deploy canary vNext (réplicas del 5%).

2. Incluimos el tráfico del 5% para las cuentas internas/segmento de prueba.

3. Autogate: error rate ≤ baseline + 0. 3%, p95 ≤ +20ms.

4. Elevamos el 10% → el 25% → el 50% cada N minutos al pasar las gatitas.

5. Traducimos 100% fichflag en todos los segmentos; eliminamos la versión anterior.

19) Variaciones para diferentes arquitecturas

Monolito: Blue-Green es más simple, Canary es más difícil debido a la indivisibilidad del fich; use fichflags.
Microservicios: Canary es natural; Siga los contratos entre servicios (contratos consumer-driven).
Servicios Stateful: prefiera Blue-Green con migraciones cuidadosamente elaboradas y stickiness.

20) Breve comparación (resumen)

Velocidad de retroceso: Azul-Verde = instantáneo; Canary = rápido, pero con un derrame de peso.
Costo de la infraestructura: Blue-Green ↑; Canary ↔︎/↓.
Riesgo para los usuarios: Canarias es menor (controlamos la participación).
Dificultad de implementación: Blue-Green es más fácil de iniciar; Canarias requiere una fuerte observabilidad y automatización.
Compatibilidad de datos/esquemas: crítica para ambos; planificar un contrato expand-migrate.

21) Resultado

Blue-Green y Canary no son estrategias mutuamente excluyentes, sino elementos de entrega progresiva. La elección depende de las limitaciones de costo, la madurez de la observabilidad y la naturaleza de los cambios. Independientemente del enfoque, la liberación sostenible se mantiene sobre cuatro pilares: automatización, observabilidad, compatibilidad inversa y retroceso rápido.