Escolher entre Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), AWS Fargate, AWS Lambda e AWS Batch é uma decisão sobre onde o código é executado e quem é responsável pelas tarefas operacionais. Neste curso, criamos uma estrutura replicável que associa os requisitos da carga de trabalho ao comportamento de escalabilidade, aos limites de falha, à responsabilidade operacional e aos fatores que determinam o custo total. Evitaremos a abordagem de simples catálogo de serviços e, em vez disso, tornaremos cada escolha justificável com base em restrições e evidências.
Vamos definir primeiro o eixo de responsabilidade, pois ele explica a maioria das compensações (trade-offs). Responsabilidade operacional refere-se a quem aplica patches no sistema operacional, gerencia a capacidade e executa o agendador (scheduler) que aloca o trabalho nos recursos de computação.
No Amazon EC2, operamos máquinas virtuais; portanto, escolhemos a AMI, a estratégia de aplicação de patches e a abordagem de escalabilidade. No Amazon ECS ou no Amazon EKS, operamos um orquestrador que agenda contêineres, e ainda precisamos decidir o que fornecerá a capacidade subjacente. No AWS Fargate, a camada de capacidade de contêineres é gerenciada pela AWS; assim, concentramo-nos nas definições de tarefas e na escalabilidade do serviço, em vez de em frotas de nós. No AWS Lambda, a AWS gerencia a infraestrutura de computação e a escalabilidade, enquanto nós focamos no código da função e em seu modelo de invocação. No AWS Batch, a AWS gerencia o enfileiramento e o agendamento de tarefas em lote (batch), podendo alocar essas tarefas em recursos do ECS, EKS, Fargate ou EC2.
Vamos analisar, em alto nível, como a responsabilidade é distribuída entre essas opções.
Podemos agora tratar a seleção de recursos computacionais como um exercício de adequação a restrições, em vez de um debate sobre preferências. O modelo de execução refere-se a como a tarefa é executada: como um serviço de longa duração, uma função acionada por eventos ou um job em fila com início e fim definidos.
O padrão de tráfego costuma ser a primeira restrição crítica. Tráfego com picos e longos períodos de ociosidade tende a favorecer modelos baseados em requisição, enquanto tráfego constante tende a favorecer capacidade sempre ativa, mantendo a utilização elevada.
A duração e o estado restringem rapidamente as opções. O AWS Lambda possui um tempo limite máximo (timeout) que atualmente é de 900 segundos; portanto, tarefas de longa duração geralmente são migradas para containers ou processamento em lote (batch). Cargas de trabalho com estado (stateful), que mantêm estado local ou exigem ajustes especializados no host, frequentemente se adequam melhor ao Amazon EC2 ou a containers executados em instâncias EC2.
A sensibilidade à latência também tem implicações operacionais. Para fluxos de requisição-resposta, consideramos o risco de cold start (inicialização a frio), o posicionamento na rede e a velocidade com que a plataforma pode adicionar capacidade paralela. Para fluxos assíncronos, consideramos o crescimento da fila de pendências, o comportamento de novas tentativas (retry) e como as falhas são isoladas e reprocessadas.
Vamos visualizar como esses requisitos se mapeiam para as restrições de computação.