El tiempo de inactividad durante los despliegues ya no es aceptable para ningún sistema de producción serio. Los usuarios esperan disponibilidad permanente, e incluso interrupciones breves erosionan la confianza y los ingresos. Las tres estrategias dominantes para lograr despliegues sin tiempo de inactividad son blue-green, canary y rolling updates. Cada una presenta distintas compensaciones en coste de infraestructura, velocidad de despliegue y seguridad de reversión. Elegir el enfoque correcto depende de la arquitectura de tu aplicación, los patrones de tráfico y la madurez del equipo. Hemos implementado las tres en diferentes proyectos de clientes y podemos compartir orientación concreta sobre cuándo destaca cada estrategia.
Los despliegues blue-green mantienen dos entornos de producción idénticos. El tráfico se dirige completamente al entorno activo mientras el de reserva recibe la nueva versión. Una vez validada, un cambio en el balanceador de carga mueve todo el tráfico al entorno actualizado instantáneamente. La principal ventaja es la reversión limpia: si surgen problemas, cambias el tráfico de vuelta al entorno anterior en segundos. El coste es mantener el doble de infraestructura durante la ventana de despliegue. Para clientes con requisitos de cumplimiento estrictos o migraciones de base de datos complejas, blue-green proporciona el camino más seguro porque puedes validar toda la pila de forma aislada antes de que ningún usuario vea el cambio.
Los despliegues canary adoptan un enfoque más gradual. Un pequeño porcentaje del tráfico, normalmente del cinco al diez por ciento, se dirige a la nueva versión mientras el resto permanece en la versión actual. Las verificaciones de salud automatizadas y las comparaciones de métricas de negocio se ejecutan continuamente durante la fase canary. Si las tasas de error aumentan o las métricas clave se degradan, el canary se revierte automáticamente. Si las métricas se mantienen estables, el tráfico se desplaza progresivamente hasta que la nueva versión maneja el cien por cien. Esta estrategia es ideal para aplicaciones de alto tráfico donde incluso una versión validada podría revelar casos extremos que solo aparecen a escala.
Las rolling updates reemplazan instancias de forma incremental dentro del mismo entorno. Kubernetes hace de esta la estrategia predeterminada, drenando conexiones de los pods antiguos mientras lanza nuevos. El proceso es eficiente en recursos ya que nunca ejecutas más que un pequeño excedente de instancias. Sin embargo, las rolling updates significan que durante la ventana de despliegue, dos versiones de tu aplicación sirven tráfico simultáneamente. Esto requiere atención cuidadosa a contratos de API retrocompatibles y cambios de esquema de base de datos. Aplicamos una puerta de pruebas de contrato en CI que verifica que la nueva versión puede coexistir con la anterior antes de que cualquier rolling update proceda.