Estratégias de implantação

Toda estratégia de implantação entrega a mesma versão nova, inclusive quando ela está quebrada. O que muda é quantas pessoas encontram o problema antes de você perceber, e quanto tempo leva para desfazer. Este tópico começa por esse tradeoff e depois desce para as configurações da AWS que produzem cada formato, porque na prova o cenário quase nunca cita o nome da estratégia: ele cita uma porcentagem, um padrão ou um estado depois da falha.

O que este tópico cobre

• As duas decisões que geram toda estratégia: substituir os servidores existentes ou construir novos, e quanto tráfego chega na versão nova de uma vez
• All at once, rolling, immutable, blue/green, canary e linear comparados por capacidade extra, exposição de usuários, velocidade de rollback e se as duas versões ficam vivas ao mesmo tempo
• A aritmética de capacidade de uma implantação rolling, e por que o tamanho do batch é uma decisão de pico e não de conveniência
• Por que o ponteiro de tráfego (listener rule, registro DNS, alias de serviço) decide a velocidade real do rollback, e o que o TTL faz com uma troca via Route 53
• O que nenhuma estratégia resolve: schema compartilhado, gravações que não voltam com o tráfego e estado de sessão dentro das instâncias
• Instance refresh do EC2 Auto Scaling: porcentagens mínima e máxima saudáveis, warmup, checkpoints, skip matching e as condições que tornam o auto rollback indisponível
• As três update policies do CloudFormation para um Auto Scaling group, com seus padrões afiados e suas incompatibilidades
• Implantações do ECS: arredondamento de minimumHealthyPercent e maximumPercent, circuit breaker e limiares de falha, bake time e lifecycle hooks em blue/green, linear e canary
• Aliases ponderados do Lambda e implantações blue/green gerenciadas do RDS, incluindo o que acontece com o ambiente antigo depois do switchover

Por que isso importa

O guia oficial do SOA-C03 coloca a implementação de estratégias de implantação dentro de um domínio que vale 22% da prova, e as questões chegam em forma de números. Uma frota que perdeu capacidade durante um update, uma implantação do ECS que não move uma task sequer, um refresh que se recusa a fazer rollback, uma fatura que não caiu depois de um upgrade de banco. Cada resposta depende de conhecer um padrão específico, não a definição de blue/green.

No trabalho a diferença aparece no pior momento possível. Quem sabe qual configuração permite lançar antes de encerrar consegue subir uma release no horário de pico. Quem não sabe descobre o limite quando o alarme dispara e o rollback já não é mais uma opção.