Estrategias de despliegue
Las estrategias para mandar un cambio a una carga de trabajo que ya está atendiendo tráfico, y los settings de AWS que producen cada una: instance refresh, update policies de CloudFormation, estrategias de despliegue de ECS, aliases de Lambda y blue/green de RDS.
Todo despliegue manda el mismo código. Lo que cambia entre estrategias es a cuántos usuarios les pega un problema antes de que te des cuenta, y cuánto tardas en deshacerlo. Este tema cubre primero el vocabulario (all at once, rolling, immutable, blue/green, canary, linear) y después los campos concretos de AWS que producen cada forma, porque en el examen la respuesta suele ser un porcentaje o el nombre de una policy y no un concepto.
Qué cubre este tema
- Las 2 preguntas detrás de cada estrategia: reemplazar los servidores que tienes o construir nuevos, y cuánto tráfico llega de una vez a la versión nueva
- Qué cuesta cada estrategia en capacidad extra, usuarios expuestos y velocidad de rollback, con la aritmética del tamaño de un batch rolling
- El límite entre blue/green y canary, planteado como mecanismo de tráfico y no como cantidad de entornos
- Por qué la capa de datos es la parte que ninguna estrategia resuelve: esquemas compartidos, escrituras que no vuelven atrás y estado de sesión
- Instance refresh de Auto Scaling: porcentajes mínimo y máximo de salud, warmup, checkpoints, skip matching y las condiciones que dejan el rollback fuera de alcance
- Las 3 update policies de CloudFormation para un Auto Scaling group, y los defaults que vacían una flota
- Despliegues rolling de ECS, el redondeo que traba los servicios chicos, el deployment circuit breaker, y blue/green, linear y canary nativos con bake time y lifecycle hooks
- Versiones, aliases y routing con pesos en Lambda, más cómo saber qué versión atendió un pedido
- Despliegues blue/green administrados de RDS y qué pasa con el entorno viejo después del switchover
Por qué importa
Las preguntas del examen en esta área casi nunca preguntan qué significa blue/green. Te dan un servicio con 2 tasks y un despliegue trabado, un instance refresh que no puede hacer rollback, o una actualización de CloudFormation que dejó una flota entera afuera, y preguntan qué salió mal. Detrás de cada uno de esos casos hay un setting concreto.
La presión en el trabajo es idéntica. La mayoría de los incidentes de producción no vienen de escribir código malo: vienen de mandarlo de una forma que hizo grande el problema antes de que alguien pudiera verlo.