Implementaciones in-place y blue/green

Automatización de despliegues en AWS

Dunieski Otano

Amazon Web Services Solutions Architect

La caída de las 2 a. m.

• El despliegue de golpe sale mal
• Todos los servidores ejecutan la versión rota
• Las personas usuarias ven errores durante una hora
• Revertir requiere otro despliegue completo

Por qué importa la estrategia de despliegue

• Una mala versión puede tirar el servicio abajo
• De golpe = más rápido, más arriesgado
• Despliegue gradual = más lento, más seguro
• La estrategia limita el radio de impacto si falla

Despliegues in-place

• Despliega en las mismas instancias que sirven tráfico
• Un lote cada vez: mitad y mitad; o una a una
• Verifica la salud de cada lote antes de seguir
• Barato; sin infraestructura extra

Despliegues blue/green

• Blue = flota de producción actual
• Green = flota nueva con la nueva versión
• El balanceador mueve el tráfico de blue a green
• La flota antigua sigue disponible para revertir rápido

Lambda y ECS son blue/green por diseño

• Lambda: el tráfico cambia con alias version pointer
• ECS: el tráfico cambia con replacement task set
• No hace falta duplicar flotas como en EC2
• Aun así eliges una configuración de despliegue

Elegir entre in-place y blue/green

• Presupuesto ajustado, parche de bajo riesgo → in-place
• Necesitas cero tiempo de inactividad o reversión instantánea → blue/green
• Servidor legacy único → in-place es la única opción
• Lambda o ECS → blue/green viene integrado

Reversión en CodeDeploy

• Reversión = volver a desplegar la revisión previa exitosa
• Actívala automáticamente ante fallo de despliegue
• Actívala automáticamente con una alarma de CloudWatch
• En blue/green: vuelve a cambiar el balanceador

¡Vamos a practicar!

Automatización de despliegues en AWS