Diagrama de estrategias de despliegue: rolling, blue-green y canary

La mayoría de las caídas empiezan con un despliegue. El código pasó la revisión y las pruebas, y luego se encontró con tráfico real, datos reales y dependencias reales. Una estrategia de despliegue decide qué parte de tu tráfico se encuentra con la versión nueva a la vez, lo rápido que notas un problema y lo rápido que puedes deshacerlo.

Este artículo compara las tres estrategias entre las que eligen la mayoría de los equipos: rolling update, blue-green y canary. Muestra cómo se mueve el tráfico en cada una, cómo es el rollback, y termina con un diagrama de un despliegue canary en el que la decisión de continuar o volver atrás está automatizada.

Rolling update

Sustituye las instancias de la versión antigua por la nueva unas pocas cada vez. Los Deployments de Kubernetes lo hacen por defecto: con la estrategia RollingUpdate, maxSurge y maxUnavailable controlan cuántos pods de más y de menos se permiten durante el rollout, y los dos valen 25 % por defecto.

• Tráfico: durante el rollout, las dos versiones atienden peticiones a la vez, en proporción a cuántos pods tiene cada una.
• Rollback: otro rolling update hacia la versión antigua. Minutos, no segundos.
• Coste: casi nada extra; como mucho, la capacidad de surge.
• Riesgo: cualquier usuario puede dar pronto con la nueva versión, y las readiness probes son la única barrera automática. Una versión que arranca bien pero falla bajo carga acaba desplegada por completo.

El rolling update es la opción por defecto adecuada para cambios de bajo riesgo y servicios internos con buenas pruebas y probes. Haz que la readiness probe compruebe lo que el servicio necesita para funcionar, no solo que el proceso está arriba, o el rollout sustituirá alegremente pods sanos por pods rotos.

Blue-green

Mantén dos entornos completos. Blue sirve producción; green recibe la nueva versión y se prueba allí mismo. Después, el balanceador de carga o el DNS pasa todo el tráfico de blue a green de golpe. La descripción del despliegue blue-green de Martin Fowler es la referencia clásica.

• Tráfico: todo en blue y luego todo en green. Nunca en los dos, al menos no durante mucho tiempo.
• Rollback: volver a blue, que sigue en marcha. Segundos.
• Coste: el doble de capacidad mientras ambos están activos.
• Riesgo: el cambio mueve al 100 % de los usuarios a la vez, así que un problema que solo aparece con tráfico real afecta a todos. La base de datos es compartida, así que los cambios de esquema deben funcionar con ambas versiones.

Canary

Envía una pequeña parte del tráfico real, por ejemplo el 5 %, a la nueva versión, compárala con la versión estable y amplía la parte por pasos si se comporta bien. El nombre viene del canario en la mina de carbón; consulta el artículo sobre canary release del sitio de Fowler.

• Tráfico: repartido por peso, por cabecera o por segmento de usuarios.
• Rollback: pon a cero el peso del canary. Segundos, y solo unos pocos usuarios de cada cien se vieron expuestos.
• Coste: unos cuantos pods extra, más las herramientas para repartir el tráfico y analizarlo.
• Riesgo: el más bajo de los tres, si vigilas las métricas correctas. Un canary que nadie vigila es un rolling update lento.

Comparativa

La última fila es igual en todas por una razón: en cualquier estrategia, dos versiones del código coinciden en algún momento con la misma base de datos. Usa migraciones expand-and-contract: añade primero las columnas y tablas nuevas, despliega código que funcione con las dos formas y elimina la forma antigua en una versión posterior.

Tráfico en sombra antes del canary

Algunos equipos añaden un paso antes del canary: copian una parte de las peticiones de producción a la nueva versión y descartan sus respuestas. Envoy e Istio pueden reflejar el tráfico de esta forma. Detecta caídas y regresiones de latencia sin ningún impacto en los usuarios, pero solo para lecturas y peticiones idempotentes. Las escrituras reflejadas repiten sus efectos secundarios, como correos, pagos y cambios de inventario, así que déjalas fuera del reflejo o apunta la sombra a dependencias aisladas en un sandbox.

Automatizar la decisión del canary

El valor de un canary está en la comparación, y a las personas se nos da mal mirar paneles durante una hora. Herramientas como Argo Rollouts y Flagger lo automatizan en Kubernetes: mueven el tráfico por pasos, consultan tu proveedor de métricas entre pasos y promueven o abortan según los umbrales que definas.

Las buenas métricas de análisis son pocas y cercanas al usuario:

• Tasa de errores (respuestas 5xx) del canary, comparada con la estable.
• Latencia en un percentil alto, como el p99.
• Una señal de negocio cuando sea posible, como los pagos completados por minuto.

Compara el canary con la versión estable, no con un número fijo, para que una mala noche de una dependencia no haga fallar todas las versiones.

El diagrama de arquitectura

Cómo leerlo:

• Arriba, la ruta del tráfico: los usuarios llegan al ingress, que envía el 95 % de las peticiones al ReplicaSet estable y el 5 % al canary. Ambos reportan a las métricas.
• Abajo, el bucle de control: CI entrega la nueva imagen al controlador de rollout. El controlador fija los pesos del ingress (arista discontinua), lee la tasa de errores y la latencia p99 de ambas versiones y decide.
• La decisión: dentro de los umbrales, pasa al siguiente paso; fuera de ellos, aborta y devuelve todo el tráfico a v1.
• El bloque Markdown enumera los pasos y la regla de aborto, que deben formar parte de la revisión de la configuración de rollout de cada servicio.

Los feature flags son la cuarta estrategia

Una estrategia de despliegue controla qué servidores ejecutan el código nuevo. Un feature flag controla qué usuarios ven un comportamiento nuevo, con independencia de los despliegues. Los equipos que publican a menudo combinan ambos: despliegan con rolling update o canary, mantienen las funciones arriesgadas detrás de un flag y lo activan de forma gradual. El flag es el rollback más rápido, porque no hay que volver a desplegar nada.

Qué poner en un diagrama de despliegue

• Porcentajes de tráfico en las aristas. Cambian durante el rollout; muestra el primer paso.
• Quién cambia los pesos. Un controlador, un pipeline o una persona.
• Los criterios de aborto. Números, no «si tiene mala pinta».
• La base de datos, con una nota de que los cambios de esquema siguen el patrón expand-and-contract.

El diagrama de pipeline de CI/CD muestra las etapas de build y pruebas que van antes, el diagrama de arquitectura de Kubernetes cubre el clúster y el diagrama de arquitectura de observabilidad muestra de dónde salen las métricas.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade una Persona para los usuarios, y un Ingress y dos nodos ReplicaSet del pack Kubernetes para la versión estable y el canary.
3. Añade Métricas y una Canalización del pack DevOps, y un Contenedor del pack Modelo C4 para el controlador de rollout.
4. Añade una Decisión, un Proceso y un Inicio / Fin del pack Diagrama de flujo para promover y abortar.
5. Etiqueta las aristas del ingress con los pesos de tráfico, dibuja los cambios de peso como una arista discontinua y añade un bloque Markdown del pack Básico con los pasos.

El ejemplo usa 11 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Cuál es la mejor estrategia de despliegue? Depende del riesgo y de las herramientas. El rolling update encaja con la mayoría de los cambios de bajo riesgo; el canary, con servicios de cara al usuario en los que una mala versión sale cara; el blue-green, con sistemas que necesitan cambios instantáneos y completos y pueden permitirse el doble de capacidad.

¿Qué diferencia hay entre blue-green y canary? Blue-green cambia todo el tráfico de golpe y conserva el entorno antiguo para un rollback instantáneo. Un canary mueve primero una pequeña parte del tráfico y solo la amplía cuando la nueva versión demuestra que funciona.

¿Cómo gestiono las migraciones de base de datos durante un despliegue? Haz que cada cambio de esquema sea compatible hacia atrás: primero amplía, despliega código que funcione con ambas formas y contrae en una versión posterior.

¿Qué métricas debe usar un análisis canary? La tasa de errores y la latencia en percentiles altos comparadas con la versión estable, más una métrica de negocio si puedes medirla rápido.

¿Los feature flags son una estrategia de despliegue? Son una estrategia de lanzamiento. Separan la activación de una función del despliegue del código, y se combinan bien con cualquiera de las tres estrategias de despliegue.

Empieza gratis — un puesto, sin tarjeta de crédito.