Reservalia ya tiene un artefacto inmutable, un cd.yml que despliega solo y tres entornos que salen del mismo módulo de Terraform. Queda la pregunta que hemos ido esquivando: en el instante exacto en que la versión nueva sustituye a la vieja, ¿cómo se hace ese relevo? Hoy Reservalia deja que ECS reemplace tareas sin criterio y cruza los dedos. Hay al menos seis formas de hacerlo, y elegir mal es la diferencia entre un despliegue invisible y un corte de servicio a las once de la mañana. En esta lección vemos las seis con su coste, su riesgo, su tiempo y su facilidad de vuelta atrás; montamos un rolling update fino y un canary por peso de ALB en Reservalia; entendemos por qué los health checks sostienen todo esto; y aceptamos el requisito que todas comparten: dos versiones del software van a convivir, y tienen que entenderse.

1. Los cuatro ejes con los que se compara una estrategia
2. Recreate: apagar y encender
3. Rolling update: sustituir por tandas
4. Blue-green: dos entornos completos y un interruptor
5. Canary: exponer una fracción del tráfico
6. Pruebas A/B: la que no es una estrategia técnica
7. Shadow: tráfico duplicado sin consecuencias
8. Tabla comparativa de las seis
9. Rolling update en ECS con números reales
10. Un canary por peso de ALB al 10 %
11. Health checks: liveness, readiness y el papel de /salud
12. Compatibilidad hacia atrás: dos versiones conviviendo
13. Qué elige Reservalia para prod
14. Errores Comunes y Consejos
15. Ejercicios
16. Conclusión

Ninguna estrategia es "la buena". Cada una intercambia cuatro magnitudes, y conviene tenerlas nombradas antes de mirar la primera:

• Coste de infraestructura: cuánta capacidad extra hace falta durante el relevo. Duplicar un entorno de producción durante veinte minutos cuesta dinero real.
• Riesgo de exposición: qué porcentaje de usuarios sufre el fallo si la versión nueva es defectuosa. Es la variable que mueve el change failure rate de las métricas DORA.
• Tiempo de despliegue: cuánto tarda el relevo completo. Un despliegue de dos horas no se hace cinco veces por semana.
• Complejidad de la vuelta atrás: cuánto se tarda y cuánto hay que pensar para volver a la versión anterior. Es el time to restore, que en Reservalia está en 68 minutos y debe bajar a menos de 10.

Hay un quinto eje implícito: la complejidad operativa. Una estrategia que nadie del equipo entiende a las tres de la madrugada es una mala estrategia por buenos que sean sus números.

En qué consiste. Se detienen todas las instancias de la versión antigua y después se arrancan las de la nueva. Es lo que hacía el "ritual del viernes" de Reservalia con su SFTP.

Cuándo elegirla. Cuando el corte es aceptable (herramientas internas, procesos por lotes nocturnos) o cuando es inevitable: si la versión nueva es incompatible con la antigua y no pueden convivir ni un segundo, recreate es la única opción honesta. Es la estrategia por defecto de cualquier sistema sin balanceador delante.

En qué consiste. Se sustituyen las instancias por grupos: se arranca una tanda de la versión nueva, se espera a que pase el health check, se retira la misma cantidad de la antigua, y se repite hasta terminar. Durante el proceso conviven las dos versiones.

Cuándo elegirla. Es el valor por defecto razonable para servicios sin estado detrás de un balanceador. Es lo que ECS hace de forma nativa y lo que Reservalia usará como base.

En qué consiste. Se levanta un entorno verde completo con la versión nueva, junto al azul que sigue sirviendo tráfico. Se prueba el verde en aislamiento y, cuando convence, se cambia el enrutado del balanceador de golpe. El azul se mantiene encendido un rato por si hay que volver.

Cuándo elegirla. Cuando el time to restore es la prioridad absoluta y el presupuesto permite duplicar capacidad. Cuidado con un detalle que se olvida siempre: la base de datos no se duplica, así que la compatibilidad de esquema sigue siendo obligatoria.

En qué consiste. Se despliega la versión nueva en un grupo pequeño y se le envía un porcentaje reducido del tráfico —el canario en la mina—. Se observan métricas de error y latencia durante unos minutos y, si se comportan, se sube el peso por etapas: 10 % → 50 % → 100 %. Si se degradan, se baja a 0 %.

Cuándo elegirla. Para cambios de riesgo medio-alto en servicios con tráfico suficiente para que las métricas sean significativas. Con 9.000 citas al mes, un canary al 10 % de Reservalia ve unas 30 peticiones de reserva al día: hay que darle tiempo o combinarlo con métricas de tráfico total, no solo del endpoint crítico.

Se confunde constantemente con el canary porque el mecanismo se parece: dos versiones sirviendo a la vez y un reparto de usuarios. La diferencia está en qué pregunta responde cada una.

Una prueba A/B no es un mecanismo de despliegue: se implementa normalmente sobre feature flags dentro de una única versión desplegada, que es justo el tema de la lección siguiente. Confundirlas lleva a errores caros, como abortar un despliegue técnicamente correcto porque una variante convierte peor, o mantener dos versiones desplegadas durante semanas "para medir".

En qué consiste. El tráfico real se copia hacia la versión nueva, cuyas respuestas se descartan: los usuarios siguen recibiendo las de la versión antigua. Sirve para validar rendimiento y corrección con carga real y riesgo cero de cara al usuario.

La trampa: si la versión espejo escribe en la base de datos, envía correos de confirmación de cita o cobra, el "riesgo cero" desaparece de golpe. El shadow exige aislar los efectos secundarios, y por eso solo compensa en cambios de alto riesgo: reescrituras de un motor de cálculo, migraciones de tecnología, refactorizaciones profundas de calcularHuecos.

ECS implementa el rolling update con dos porcentajes sobre desired_count. En prod, Reservalia tiene 4 tareas del servicio reservalia-api:

• minimumHealthyPercent: el mínimo de tareas sanas que debe haber en todo momento, en porcentaje de desired_count.
• maximumPercent: el máximo de tareas simultáneas, incluyendo las de las dos versiones.

Con desired_count = 4, esos dos números se traducen así:

Reservalia usa 100 / 200 en prod y 50 / 100 en dev, donde un bajón de capacidad no molesta a nadie y el ahorro sí importa. La secuencia que ejecuta ECS con 100/200 es: arrancar 4 tareas v2 → esperar a que las 4 pasen el health check del grupo de destino → registrarlas en el ALB → desregistrar las 4 tareas v1 y esperar el connection draining → detenerlas.

Mientras el despliegue avanza aparecen dos entradas: la PRIMARY (versión nueva) y la ACTIVE (la anterior, en retirada). Cuando solo queda PRIMARY, el relevo ha terminado; es justo lo que espera aws ecs wait services-stable en cd.yml.

Un parámetro más, y es el que evita la mitad de los sustos:

Con el circuit breaker, si las tareas de la versión nueva fallan repetidamente al arrancar, ECS aborta el despliegue y restaura la definición de tarea anterior sin intervención humana. Es la vuelta atrás automática más barata que existe en esta plataforma.

Para cambios delicados —tocar calcularHuecos, por ejemplo— Reservalia añade un modo canary. La pieza clave es que un ALB puede repartir tráfico entre varios grupos de destino con pesos.

Dos detalles importantes:

• TG_ESTABLE y TG_CANARY son dos grupos de destino, servidos por dos servicios ECS (reservalia-api y reservalia-api-canary) que corren el mismo artefacto o distinto: es el peso, no el despliegue, lo que decide la exposición.
• TargetGroupStickinessConfig hace que un usuario que cayó en el canary siga en él durante una hora. Sin esto, un mismo usuario saltaría entre versiones petición a petición, con resultados incoherentes si el cambio afecta a la interfaz.

La promoción por etapas se automatiza como un job con pausas de observación:

comprobar-metricas.sh consulta CloudWatch y devuelve un código de salida distinto de cero si el canary se comporta peor que el estable; el fallo del paso detiene el pipeline con el canary aún al 10 %, es decir, con el 90 % de los usuarios intactos. Cómo se definen esos umbrales con criterio es materia de la lección 03-06.

Todas las estrategias anteriores dependen de una respuesta binaria: ¿esta instancia nueva está lista para recibir tráfico? Quien la da es el health check, y hay dos tipos que se confunden a menudo.

En la 03-02, el smoke test llamaba a un único /salud que hacía las dos cosas a la vez; ahora lo separamos, porque mezclarlas es exactamente el origen del problema. En Reservalia, /salud pasa a ser el liveness: responde 200 con un cuerpo mínimo y no toca la base de datos. Debe ser barato porque se llama cada pocos segundos y porque, si comprobara PostgreSQL, una caída de la base de datos provocaría el reinicio en bucle de todos los contenedores, convirtiendo una degradación en una caída total.

1. El readiness sí comprueba la conexión al pool de PostgreSQL: una tarea que no puede consultar la base de datos no debe recibir citas.
2. También comprueba que no queden migraciones pendientes; una tarea con esquema desactualizado responde 503 en lugar de romper peticiones reales.
3. El código 503 es el que hace que el ALB no la registre. Devolver 200 con un cuerpo que dice "error" no sirve de nada: el balanceador mira el código, no el texto.

Por qué un health check que devuelve 200 sin comprobar nada es peor que ninguno. Porque miente con autoridad. El rolling update pregunta "¿está lista?", el endpoint responde que sí antes de que la aplicación pueda atender nada, ECS retira las tareas de la versión antigua y el servicio queda servido por instancias que devuelven errores. Sin health check, al menos el operador sabe que no tiene información; con uno falso, el sistema toma decisiones destructivas basadas en una respuesta vacía. La regla: un readiness debe poder decir que no. Si nunca has visto tu /salud/listo devolver 503, probablemente no comprueba nada.

Todas las estrategias salvo recreate tienen la misma consecuencia: durante un rato, v1 y v2 atienden a los mismos usuarios sobre la misma base de datos. Si no son compatibles, la estrategia elegante se convierte en un incidente elegante.

El patrón que resuelve casi todos los casos "no" es expandir y contraer: primero se despliega un cambio que añade lo nuevo sin quitar lo viejo (expandir), después se migran los consumidores, y solo en un tercer despliegue se elimina lo antiguo (contraer). Renombrar duracion se convierte así en tres pasos seguros: devolver ambos campos, actualizar la web, dejar de devolver duracion.

Lo mismo aplica a los datos, y ahí es más grave, porque una migración de esquema no se revierte con un cambio de peso en el ALB. Añadir una columna es compatible; borrarla o renombrarla rompe a la versión que sigue corriendo. Ese terreno tiene lección propia: 04-06, Bases de Datos en el Pipeline: Migraciones Seguras.

Marta lo cierra así: rolling update 100/200 con circuit breaker como estrategia por defecto, y canary por peso de ALB para los cambios marcados como arriesgados (los que tocan calcularHuecos, el cálculo de precios o el flujo de pago).

Las razones, en el orden en que las expuso: el rolling update no cuesta infraestructura permanente y ECS lo hace nativamente, así que es la opción que el equipo puede operar sin ceremonias; el circuit breaker ya cubre el fallo más frecuente, que es una versión que ni siquiera arranca; blue-green se descarta porque duplicar prod de forma sostenida no cabe en el presupuesto de una empresa con 340 clientes de pago; y el canary se reserva para lo que realmente lo merece, porque sus esperas de observación alargan el despliegue y, con el tráfico actual, exigen ventanas largas para que los números signifiquen algo. El shadow queda anotado para el día que haya que reescribir el motor de agenda.

Error 1: elegir canary por moda. Un canary sin métricas fiables ni umbrales definidos es un rolling update lento y caro con una sensación falsa de seguridad. Primero la observabilidad, después el canary. Error 2: creer que blue-green elimina el riesgo de datos. Los dos entornos comparten la base de datos: si la versión verde aplicó una migración destructiva, volver al azul no devuelve los datos.

Error 3: usar minimumHealthyPercent = 0 "para que vaya rápido". Es recreate con otro nombre, y en prod significa corte de servicio. Error 4: un readiness que llama a todas las dependencias. Si /salud/listo consulta un servicio externo de pagos, un fallo de ese servicio saca del balanceador a todas las tareas sanas; comprueba solo lo imprescindible para atender.

Error 5: canary sin adherencia de sesión. El usuario alterna entre versiones petición a petición y ve comportamientos incoherentes; los informes de error resultantes son irreproducibles.

Consejo 1: ensaya la vuelta atrás. Una estrategia con rollback teórico no probado tiene rollback de 68 minutos. Consejo 2: escribe la estrategia en el código de infraestructura, no en la memoria de Nuria; los porcentajes viven en infra/modulos/entorno/. Consejo 3: ante la duda entre dos estrategias, elige la que el equipo entienda mejor a las tres de la madrugada.

Reservalia debe desplegar un cambio que reescribe calcularHuecos con un algoritmo nuevo, más rápido pero con riesgo de devolver huecos incorrectos en casos raros. El resultado es visible para el usuario y afecta a reservas reales. Elige una estrategia, justifícala frente a las otras cinco y describe qué medirías para decidir si promocionar.

El servicio reservalia-api en staging tiene desired_count = 2, minimumHealthyPercent = 100 y maximumPercent = 100. Diego lanza un despliegue y el workflow se queda colgado hasta que wait-for-service-stability agota el tiempo. Explica qué ha pasado y propón dos configuraciones válidas.

Marta quiere retirar el campo duracion de la respuesta de GET /citas y sustituirlo por duracionMin. La web de Reservalia consume ese campo y hay integraciones de tres clientes que también lo usan. Diseña la secuencia de despliegues y di qué estrategia usarías en cada uno.

Solución 1. La elección es canary, complementado idealmente con una fase previa de shadow. Razonamiento: recreate y rolling update exponen a todos o a una fracción no controlada, y aquí el fallo produce reservas incorrectas —daño de negocio, no solo error técnico—. Blue-green expone al 100 % en cuanto se conmuta, así que no acota el daño. Las pruebas A/B no aplican: la pregunta es de corrección, no de preferencia. El shadow es ideal porque calcularHuecos es una función de lectura y se pueden comparar las salidas de v1 y v2 con tráfico real sin que el usuario vea nada; su límite es que no valida el flujo completo de reserva. Con el canary al 10 % mediría, además de errores 5xx y latencia p95: el número de reservas creadas por sesión (una caída indica huecos que desaparecen), la tasa de conflictos al confirmar cita (dos usuarios reservando el mismo hueco indica huecos duplicados) y las reclamaciones de soporte. Con ~30 reservas diarias en el canary, la ventana de observación debe medirse en días, no en minutos, o hay que subir el peso inicial al 25 %.

Solución 2. Con minimumHealthyPercent = 100 y maximumPercent = 100, ECS no puede retirar ninguna tarea antigua (rompería el mínimo de 2 sanas) ni arrancar ninguna nueva (rompería el máximo de 2 totales). El despliegue queda bloqueado: es una configuración imposible. Dos arreglos válidos: (a) 100 / 200, que permite arrancar hasta 2 tareas nuevas antes de retirar las antiguas, sin pérdida de capacidad y con coste extra transitorio; (b) 50 / 100, que permite retirar una tarea antigua para hacer sitio a una nueva, sin coste extra pero con la capacidad reducida a la mitad durante el relevo. En staging, la (b) es perfectamente razonable; en prod, la (a).

Solución 3. Tres despliegues siguiendo expandir-contraer. Despliegue 1 (expandir): la API devuelve duracion y duracionMin con el mismo valor. Es un cambio aditivo y compatible, así que basta un rolling update normal. Despliegue 2 (migrar consumidores): la web pasa a leer duracionMin; se avisa a los tres clientes de integración con una fecha límite y se instrumenta el uso del campo antiguo para saber cuándo deja de leerse —sin ese dato, la fecha límite es una suposición—. Despliegue 3 (contraer): cuando la telemetría confirme que nadie consume duracion, se elimina de la respuesta; aquí conviene un canary, porque es el único paso que puede romper a un tercero desprevenido y el peso permite revertir en segundos. El error clásico es intentar hacerlo en un solo despliegue confiando en que "la web se despliega a la vez": durante el rolling update conviven ambas versiones de la API y ambas de la web, así que la incompatibilidad se manifiesta igualmente.

Ya no hay una sola forma de sustituir una versión por otra, sino un menú con precios. Recreate es simple y corta; rolling update es el valor por defecto sensato; blue-green compra un rollback instantáneo pagando capacidad doble; canary compra riesgo bajo pagando tiempo; A/B no es una estrategia técnica sino una herramienta de producto; y shadow valida con carga real sin exponer a nadie, siempre que se aíslen los efectos secundarios. Reservalia se queda con rolling update 100/200 más circuit breaker, y reserva el canary por peso de ALB para lo arriesgado.

Debajo de todas ellas hay dos cimientos que conviene no olvidar: un readiness honesto que sepa decir 503, porque es la señal sobre la que se apoyan todos los automatismos, y la compatibilidad hacia atrás, porque en cuanto se abandona recreate hay dos versiones conviviendo sobre la misma base de datos.

Aun así, seguimos atados a una suposición optimista: que el fallo se detecta durante el despliegue. Muchos fallos aparecen horas después, cuando el canary ya se promovió y la ventana de observación se cerró. Además, hay un problema previo: desplegar código y activar una funcionalidad son la misma acción, así que una funcionalidad a medias obliga a mantener ramas de vida larga. La siguiente lección, Feature Flags, Rollback y Recuperación ante Fallos, separa el despliegue del lanzamiento, construye el botón de vuelta atrás de Reservalia y convierte los 68 minutos de time to restore en un objetivo alcanzable.