Canary Release

Resumen

Canary release toma su nombre de los mineros que llevaban un canario a la mina: si el canario dejaba de cantar, había gas tóxico y evacuaban. En software, desplegás la nueva versión para un pequeño porcentaje de usuarios —1%, 5%, 10%— y monitoreás tasas de error, latencia, y comportamiento. Si las métricas son normales, aumentás el porcentaje gradualmente hasta 100%.

A diferencia de Blue-Green —todo o nada—, canary permite detectar problemas que solo aparecen con tráfico real antes de que afecten a todos los usuarios. Requiere un load balancer o service mesh que soporte enrutamiento por peso.

Alcance y supuestos

Cubre canary releases, métricas clave a monitorear, y herramientas. Asume familiaridad con estrategias de deploy.

Modelo mental

Un restaurante que prueba un plato nuevo. En lugar de cambiar el menú entero, el chef prepara 10 porciones y las ofrece como degustación gratuita. Si los comensales devuelven el plato, el plato no llega al menú. Si lo aman, la semana siguiente es parte del menú oficial.

Uso práctico

• ✅ APIs con alto tráfico, cambios de alto riesgo, pruebas A/B de infraestructura.
• ❌ Aplicaciones con 50 usuarios: 5% es 2.5 personas, la muestra no es representativa.

Ejemplo trabajado: canary en Kubernetes con Istio

Istio enruta 5% del tráfico a la nueva versión. Si error_rate < 0.1% durante 10 minutos, sube a 25%, 50%, 100%. Si error_rate sube, Istio revierte automáticamente a la versión estable.

Evidencia

• Kubernetes soporta canary con Ingress controllers como NGINX o service meshes como Istio. Argo Rollouts lo automatiza.