EKS vs. ECS: diferenças inesperadas e dicas práticas de qual usar

Pode ser difícil definir se EKS ou ECS é a melhor opção para um projeto.

Se você analisar característica por característica, fica fácil eleger um vencedor. A dificuldade é que, para fazer uma comparação justa, é preciso enxergar cada produto como um conjunto de características. Por isso, faz mais sentido pensar em cada um como um pacote misto, com prós e contras que andam juntos.

Quando você percebe isso, duas consequências naturais aparecem:

1. Nenhuma opção é a melhor por padrão. A escolha ideal depende dos requisitos e restrições do projeto e da organização.

2. Definir objetivamente qual opção encaixa melhor exige um pouco de pensamento crítico e raciocínio mais elaborado.

Neste artigo, você vai encontrar diferenças, implicações e insights raramente documentados, relevantes para restrições comuns de projeto e organização, além de outros fatores que merecem atenção na hora de decidir.

O melhor é encarar este conteúdo como um raciocínio guiado por meio de conselhos condicionais que, combinados com um projeto específico, viram rapidamente orientações práticas para você tomar uma decisão bem fundamentada.

BLUF (Bottom Line up Front)

Sumário

Público-alvo

Introdução

Seção 1: Diferenças menores entre EKS e ECS

1. O ECS tem preços de Fargate bem melhores (o EKS Fargate é caro).

2. A densidade de containers em EC2 do EKS é bem maior que a do ECS.

3. O ECS oferece opções mais avançadas de service discovery.

4. O EKS tem uma leve vantagem sobre o ECS em multicloud e desenvolvimento local, por ser baseado em Kubernetes.

5. O ECS não cobra pelos custos do control plane, enquanto o EKS cobra.

Seção 2: Insights sobre diferenças potencialmente críticas

1. O EKS oferece escalonamento mais rápido de containers por padrão e suporte avançado a autoscaling, com o uso do add-on keda.sh.

2. O IaC (Infrastructure as Code) do EKS é fundamentalmente superior ao do ECS, porque é padronizado, fácil de ler, desacoplado, declarativo e suporta metadados com estado.

3. O ECS não tem suporte nativo a volumes.

4. O nível de dificuldade do EKS tende a ser variável e paradoxal:

"O EKS costuma ser difícil porque é fácil demais."

5. As atualizações do ECS são extremamente raras, o que é uma grande vantagem em termos de estabilidade e por evitar o trabalho operacional associado a clusters.

6. O EKS tem uma sobrecarga de manutenção inevitável e uma ordem de magnitude a mais de partes móveis em relação ao ECS, que praticamente nunca precisa de manutenção.

Seção 3: Regras práticas para escolher ECS, EKS ou nenhum dos dois.

1. O ECS pode ser a melhor escolha em cenários onde:

2. Justificar objetivamente o EKS como melhor escolha exige uma reflexão um pouco mais cuidadosa sobre fatores situacionais: (Esta seção também traz boas dicas sobre o EKS Auto Mode.)

3. Aplicações com estado são um cenário comum o suficiente para justificar uma discussão baseada em regras práticas:

Conclusão

Este artigo é para quem quer saber como tomar uma decisão bem fundamentada na hora de escolher entre EKS e ECS.

Se você é o público-alvo, vale a pena investir o tempo para ler este artigo relativamente longo, porque depois da leitura você estará bem posicionado para alcançar o objetivo principal de tomar uma decisão bem fundamentada e ainda os três objetivos auxiliares úteis a seguir:

1. Descobrir diferenças, prós e contras inesperados.

(Vou focar naqueles difíceis de googlar e que costumam ficar de fora da documentação.)

2. Aprender metadados de tomada de decisão.

(Como implicações relevantes das escolhas e insights sobre fatores e restrições críticos comumente encontrados, que merecem peso na hora de avaliar opções. Eles também são ótimos candidatos para virar recomendações em forma de regras práticas.)

3. Entender o raciocínio em que as afirmações se baseiam.

Se você consegue entender, concordar e parafrasear o raciocínio e a justificativa apresentados para mostrar que afirmações, implicações ou insights são válidos, dá para usar esse conhecimento para aumentar a confiança (em nível pessoal, de equipe ou organizacional) de que uma decisão é razoável e baseada em afirmações sólidas.

O restante do artigo está dividido em seções que seguem o sumário acima. Cada seção traz uma lista de afirmações, junto com uma combinação de explicações esclarecedoras, evidências factuais e evidências anedóticas para ajudar a sustentar sua validade.

A primeira seção tem uma lista numerada de diferenças específicas entre EKS e ECS que são úteis de saber, mas geralmente não fazem grande diferença.

A segunda seção traz insights sobre diferenças que merecem atenção, porque podem se tornar fatores críticos na hora de decidir.

A terceira seção traz regras práticas condicionais baseadas em preocupações comuns de projeto, equipe ou organização. Combinar essas regras com as suas circunstâncias específicas gera orientações práticas.

Tanto o ECS quanto o EKS podem rodar sobre Fargate ou EC2. Apesar disso, há uma forte tendência de o ECS usar Fargate e o EKS usar instâncias EC2.

As duas primeiras diferenças desta seção apontam um ponto positivo de cada um que explica por que essa tendência faz sentido. As três diferenças seguintes envolvem prós menores, com explicações de por que são relativamente desprezíveis.

1. O ECS tem preços de Fargate bem melhores (o EKS Fargate é caro).

Isso é uma preocupação menor, porque, independentemente do preço, usuários do EKS ainda podem preferir EC2 por conta de vantagens de funcionalidade. (EC2 suporta cache de imagens de container e daemonsets, enquanto o Fargate não.)

• Em teoria, segundo a documentação do Fargate da AWS, instâncias Fargate deveriam ser ligeiramente mais caras que EC2 em troca de benefícios de conveniência e segurança, e essa relação visa promover um menor custo total de propriedade.

Na prática, esse entendimento só vale para o ECS, porque o ECS suporta instâncias Fargate baseadas em AMD (também conhecida como Intel/x86_64), ARM, on-demand e Spot.

• O EKS só suporta instâncias Fargate baseadas em AMD on-demand.

O EKS não suporta "Fargate Spot instances" nem "Fargate baseado em ARM".

• Isso significa que, ao comparar preços para o EKS, você precisa comparar a opção mais cara com a mais barata E ainda lidar com a lógica de arredondamento de tamanho de instância do Fargate, somada aos custos extras.
• Para um exemplo concreto, suponha que um container passou por uma análise de right-sizing que indicou que ele roda melhor com 1,8 CPU e 1,2 GB de RAM.

Se você precisa de 2 CPU, o Fargate arredonda automaticamente para 4 GB de RAM, e temos que usar o preço Fargate on-demand baseado em AMD. Em us-east-1, o preço do Fargate é US$ 2,37/dia. Esse container caberia em um nó Spot EC2 EKS t4g.small baseado em ARM, que custaria US$ 0,1512/dia.

• Ou seja, o EKS rodando sobre Fargate pode ser 15x mais caro que o EKS sobre EC2! (Vale lembrar também que essa diferença é baseada na região mais barata; em regiões mais caras, a diferença de 15x é ainda maior!)

2. A densidade de containers em EC2 do EKS é bem maior que a do ECS.

Observação: se a maioria dos seus containers usa pelo menos 1 CPU e 1 GB de RAM, a diferença de preço será mínima, porque t3/t4g.small consegue hospedar 2 ECS tasks desse tamanho.

Se você implanta uma grande quantidade de microsserviços com baixo uso de CPU e RAM, esses containers podem sair bem mais baratos no EKS, graças à maior densidade de containers . (Observação: isso pode ser um diferencial relevante de economia para organizações que fazem implantações em larga escala de múltiplos microsserviços, mas para a maioria das organizações eu não acho que a diferença de custo seja tão expressiva, então considero essa uma diferença menor digna de nota.)

• Muitos usuários do ECS preferem instâncias Fargate, que de qualquer forma só permitem uma task/pod por instância. O que pouca gente sabe é que o ECS sobre EC2 é bem pior do que o EKS sobre EC2.
• Um t4g.small consegue rodar 11 pods EKS, ou 2 ECS tasks.

Um t4g.large consegue rodar 35 pods EKS, ou 2 ECS tasks.

• Calculei isso usando:

aws ec2 describe-instance-types \
--filters "Name=instance-type,Values=t4g.*" \
--query "InstanceTypes[].{Type: InstanceType, MaxENI: NetworkInfo.MaximumNetworkInterfaces, IPv4addr: NetworkInfo.Ipv4AddressesPerInterface}" \
--output table

• A saída do comando mostra que t4g.small suporta 3 ENIs. O ECS precisa de 1 para a VM host e disponibiliza 1 por task. Uma boa fórmula resumida é $MAX_ENI -1 = $MAX_TASKS_PER_EC2_INSTANCE. (3-1=2).
• Observação: o ECS tem um recurso com nome ruim chamado ENI trunking (também conhecido como AWS VPC Trunking). Em teoria, ele deveria aumentar a densidade de containers do ECS, mas na prática só é suportado por tipos de instância que NUNCA fazem sentido do ponto de vista de otimização de custos em FinOps. Por isso, recomendo pessoalmente que você simplesmente finja que ele não existe.
• Algumas observações relacionadas e interessantes:

Normalmente, instâncias AMD são a melhor escolha por padrão, por conta do menor custo e maior desempenho. O "a" em t3a vem de AMD, então, como regra geral: t3a é melhor que t3. No entanto, a densidade de containers do ECS é um caso raro em que t3 ganha de t3a, já que t3a.small estranhamente só tem 2 ENIs e suporta apenas 1 ECS task, enquanto t3.small tem 3 ENIs e suporta 2 ECS tasks.

• Acho que os 2 maiores motivos pelos quais usuários do ECS preferem instâncias Fargate são:

1. Configurar ECS sobre Fargate é praticamente plug-and-play, enquanto ECS sobre EC2 exige um trabalho extra.

2. A ausência de uma densidade de containers significativamente maior em instâncias EC2 reduz o incentivo para migrar do ECS sobre Fargate para o ECS sobre EC2.

3. O ECS oferece opções mais avançadas de service discovery.

Considero essa uma vantagem menor do ECS, pois só é útil em casos de uso raros, e nesses casos o EKS consegue resultados parecidos instalando ferramentas opcionais para estender a funcionalidade básica do EKS.

• O service discovery do EKS é em forma de Inner Cluster DNS Names, que só são resolvíveis por pods dentro do cluster e seguem um padrão previsível: $SERVICE.$NAMESPACE.svc.cluster.local
• O ECS oferece duas opções de service discovery. Uma é baseada em API e suporta Inner ECS Cluster Communications, e a outra é baseada em DNS e suporta Inner VPC Communications. (Você pode ler mais sobre elas aqui se tiver interesse.)

4. O EKS tem uma leve vantagem sobre o ECS em multicloud e desenvolvimento local, por ser baseado em Kubernetes.

Veja por que essa diferença é relativamente desprezível:

• Multicloud é quase sempre uma péssima ideia. A única forma de fazer direito é com um design cloud-agnostic, que também raramente é uma boa ideia. O principal problema do multicloud é que, na prática, é fácil encontrar 10 problemas reais para cada 1 benefício teórico.
• Minikube e Rancher Desktop podem ser usados para rodar Kubernetes localmente, mas, na prática, só vi Engineers individuais altamente habilidosos tirarem proveito disso, implementando manualmente nos próprios laptops.

Existem muitas nuances de integração que tornam proibitivamente difícil oferecer uma experiência consistente de desenvolvimento local com integrações úteis para a equipe inteira sem um investimento significativo. Por isso, na prática, o valor desse benefício costuma ser bem limitado.

• Como o ECS é baseado em Docker, Engineers altamente habilidosos podem fazer desenvolvimento local com Docker nos próprios laptops. O desenvolvimento local com Docker é parcialmente aplicável ao ECS, assim como o Kubernetes local é parcialmente aplicável ao EKS.

Da mesma forma, como apenas Engineers altamente habilidosos conseguem navegar pelas nuances de integração para obter benefícios que se aplicam só a si mesmos como desenvolvedores individuais, ser baseado em Docker tende a ter valor prático limitado para o ECS também.

5. O ECS não cobra pelos custos do control plane, enquanto o EKS cobra.

Considero essa uma vantagem relativamente menor, porque os custos do EKS são bem acessíveis e fáceis de justificar. Dito isso, dá para ver que pode importar para uma startup que precisa rodar o mais barato possível.

• Se você mantém seu cluster EKS atualizado, são US$ 864/ano por cluster. Mesmo assim, é prática comum ter clusters de dev, stage, prod e alguns clusters sandbox temporários, então US$ 3 mil/ano é uma estimativa mais razoável.
• Veja 3 motivos pelos quais os custos do control plane do EKS são fáceis de justificar:
• 1. Eles fazem sentido independentemente do ECS.

Se você tentasse rodar uma distribuição Kubernetes cloud-agnostic como Talos ou Rancher, precisaria pagar por 3 VMs para atuar como nós de control plane em HA/FT. Os custos do control plane do EKS são mais baratos que a opção DIY, e ainda oferecem os benefícios de um serviço gerenciado.

• 2. O EKS tem recursos que valem um pequeno prêmio, principalmente debugabilidade mais fácil e ciclos de feedback mais rápidos. (A próxima seção detalha isso melhor.)
• 3. O EKS tem recursos próprios de economia de custos, como o EKS sobre EC2 sair mais barato que o ECS sobre Fargate e, potencialmente, mais barato que o ECS sobre EC2 graças à maior densidade de containers; o Kubernetes Ingress facilita configurar load balancers compartilhados por múltiplos serviços, permitindo pagar por menos AWS LBs; o karpenter.sh oferece autoscaling automatizado e dimensionado corretamente; e o keda.sh oferece autoscaling avançado de containers.
• Esses recursos podem fazer com que o EKS tenha um custo de hospedagem menor que o ECS. Há variáveis condicionais demais para julgar um como mais barato em geral, mas o que é fato é que não é incomum o EKS sair mais barato no total ou ter uma diferença líquida desprezível de custo, e isso torna a existência dos custos do control plane do EKS um ponto potencialmente irrelevante.

Esta seção traz três pontos positivos do EKS, um paradoxo do EKS que costuma ser um ponto negativo, mas pode virar positivo, e em seguida dois pontos positivos do ECS.

1. O EKS oferece escalonamento mais rápido de containers por padrão e suporte avançado a autoscaling, com o uso do add-on keda.sh.

• O EKS tende a escalar mais rápido que o ECS no geral. Ao comparar EKS sobre EC2 vs. ECS sobre Fargate, isso é intuitivo, já que o Fargate não tem suporte a cache de imagens de container.

O que não é intuitivo é que o EKS também tende a apresentar tempos de inicialização rápidos com mais frequência mesmo quando EKS e ECS estão ambos rodando sobre instâncias EC2.

Isso acontece porque o EKS tem uma densidade de containers maior, o que permite aproveitar o cache de imagens com mais frequência. Graças ao cache de imagens, não é incomum um pod do EKS subir em segundos.

• O ECS tem bom suporte a autoscaling e suporta escalonamento baseado em métricas customizadas do CloudWatch, mas não chega ao nível do EKS quando o assunto é escalonamento. O EKS é nitidamente mais rápido e melhor no autoscaling de containers, graças a algumas nuances dos detalhes de implementação do ECS, da resolução de métricas e do suporte a escalar para 0.
• Vou detalhar os pontos problemáticos da implementação do ECS. O autoscaling baseado em meta só consegue escalar por um número fixo de unidades de capacidade, e oferece uma segunda opção de autoscaling baseado em passos para permitir um certo grau de variação no escalonamento, mas acaba havendo um atraso de 1 minuto entre as decisões de escalonamento, porque os pontos de dados de métricas são coletados uma vez por minuto.
• (A frequência com que as métricas são coletadas costuma ser chamada de resolução de métrica.)
• O EKS usa o HPA do Kubernetes (Horizontal Pod Autoscaler), que tem uma resolução de métrica padrão de 15 segundos, e por isso consegue escalar 4x mais rápido.
• O escalonamento do ECS funciona baseado em CloudWatch Metrics, CloudWatch Alarms e uma combinação de defaults subótimos e defaults não editáveis, o que tende a deixá-lo aquém das opções de HPA do EKS.

O ECS tem um cenário de melhor caso em que consegue ganhar do EKS de uma forma, mas em troca de péssimas escolhas. No geral, as opções do ECS não são tão boas.

• Veja como é o cenário de melhor caso de autoscaling baseado em métricas do ECS:

Uma métrica customizada do CloudWatch de alta resolução pode ter resolução de até 1 segundo.

Na prática, só importa a cada 10 segundos, porque o alarme do CloudWatch é o que dispara o escalonamento, e ele tem um período mínimo de avaliação de 10 segundos.

Tecnicamente, isso supera o período de avaliação padrão não editável de 15 segundos do HPA do EKS, mas esse benefício vem acompanhado de uma péssima escolha. Se você implementar uma resolução de métrica de 10 segundos (na verdade, qualquer coisa abaixo de um minuto), só consegue 3 horas de retenção de métricas.

• Veja como costuma ser o autoscaling baseado em métricas do ECS em cenários comuns:
• As métricas de CPU e RAM do ECS têm resolução de 1 minuto, que é um padrão não editável, e isso obriga o período mínimo de avaliação do CloudWatch Alarm a ser de 1 minuto nos cenários mais comuns.
• Mesmo se você implementar uma métrica customizada, talvez prefira fazê-la uma vez por minuto para ter 15 dias de retenção e um preço mais barato.
• Também vale apontar que a resolução de métrica do ECS tem um valor padrão implícito de 1 minuto, e precisa de configuração explícita para habilitar a granularidade de 10 segundos.

O metrics server do Kubernetes tem um valor padrão implícito melhor de resolução de métrica, de 15 segundos.

• O ECS só consegue escalar para 0 quando se usa métricas de fila do SQS; normalmente não consegue escalar para 0.
• O EKS pode instalar um add-on gratuito chamado keda.sh para habilitar capacidades de autoscaling mais robustas, como métricas customizadas, escalonamento de tráfego HTTP para 0 e escalonamento baseado em cron.

A opção de cron é especialmente útil no cenário comum de precisar de capacidade de baseline extra além do autoscaling, para absorver picos de tráfego com tranquilidade durante o horário comercial de pico, e permitir que a capacidade de baseline diminua em períodos previsíveis de baixa atividade.

2. O IaC (Infrastructure as Code) do EKS é fundamentalmente superior ao do ECS, porque é padronizado, fácil de ler, desacoplado, declarativo e suporta metadados com estado.

Essas características produzem vantagens de várias ordens de magnitude em debugabilidade, ciclos de feedback e na experiência geral do usuário em DevOps.

• O EKS segue o padrão do Kubernetes de kubectl + yaml.

É rápido e fácil para humanos lerem, aprenderem e editarem. (O suporte intrínseco do YAML a JSON é um bônus, já que YAML é um superconjunto de JSON.)

• O ECS não tem propriamente um padrão oficial, tanto em termos de IaC quanto de tooling. Isso torna o IaC do ECS mais difícil de aprender, porque já de cara é preciso pesquisar e escolher entre opções comuns de tooling como AWS Copilot, AWS CDK, Terraform ou Pulumi.
• Em opções de IaC e tooling, o EKS oferece mais alternativas, mas em termos de padrão, há apenas um. E todas as opções do EKS são baseadas nesse único padrão; isso dá ao EKS uma vantagem significativa tanto na facilidade de aprendizado quanto nas chances de desenvolver um conjunto de habilidades que provavelmente será transferível entre empregadores que preferem desenvolver de acordo com padrões comuns.
• A falta de desacoplamento conceitual e de IaC no ECS gera várias desvantagens inerentes.

Um ECS Service é conceitualmente equivalente a um deployment, service, configmap, secret e AWS IAM role do EKS fortemente acoplados em um pacote. Isso cria múltiplos problemas:

• 1. Um problema é que o acoplamento forte dos deployments do ECS impõe limites a edições in-place que podem ser feitas em um objeto implantado.

Não é incomum mudanças exigirem redeploys completos ou processos chatos de duas etapas envolvendo deleção e recriação.

Isso enjoa rápido quando você precisa fazer alterações iterativas.

O ECS torna muito chato adicionar, remover ou trocar tipos de load balancer. Você descobre que não consegue usar o mesmo nome de serviço sem deletar e recriar do zero, o que causaria downtime. Dá para contornar isso fazendo um cutover blue-green, mas isso envolve sobrecarga.

Já os Engineers que interagem com o EKS têm uma ótima experiência de uso graças a atualizações declarativas e idempotentes.

• 2. Deployments do ECS são naturalmente mais lentos que os do EKS.
• 3. Quando um deployment do ECS dá errado, é fácil acabar depurando uma caixa-preta, sem sinais claros de feedback de que o estado real convergiu para o estado desejado.

Não é incomum Engineers de ECS precisarem esperar timeouts e gastarem cerca de 4 minutos entre iterações ouvindo o famigerado "computer says no".

Algumas escolhas de tooling, como o AWS Copilot, podem deixar essa experiência de caixa-preta ainda pior. Quando o Copilot encontra certos cenários de debug, o tempo de espera pode chegar a 20 a 60 minutos entre iterações, por causa da necessidade de esperar o ECS, o Cloud Formation e outras camadas de abstração caixa-preta darem timeout.

E não vamos esquecer: quando há falhas, a natureza caixa-preta do ECS frequentemente deixa de dar feedback ou pistas sobre a causa do erro.

• 4. A depuração de problemas em deployments do ECS tende a exigir mais iterações do que a depuração de objetos YAML do EKS, que são mais simples e desacopláveis.

Essa tendência ocorre porque ECS tasks são pacotes fortemente acoplados de múltiplos componentes; o escopo da solução de problemas é maior, sem uma forma fácil de restringir em qual componente focar.

• Quando você eventualmente precisa depurar o EKS, dá para implantar, editar e depurar componentes de forma sistemática e independente uns dos outros. E é fácil chegar a um ciclo de feedback medido em segundos, porque há sinais claros de feedback quando você executa um comando kubectl describe ou output yaml e olha os eventos com estado e o status de um objeto YAML. O ciclo de feedback do EKS costuma ser limitado pela velocidade com que você consegue pensar e digitar.
• Graças ao kubectl port-forward, é trivialmente fácil depurar serviços de IP privado no EKS. O ECS não tem propriamente um equivalente.
• Um elemento essencial da ótima experiência do Kubernetes em termos de feedback é que controllers anexam metadados com estado ao manifesto YAML dos objetos componentes que recebem kubectl apply contra o banco de dados etcd de um cluster ativo.

Graças a isso, Engineers podem usar os comandos kubectl describe e output yaml para ver os metadados de evento ou status de um objeto. Isso fornece feedback rápido e muitas vezes específico sobre o sucesso ou a falha de várias etapas em objetos componentes individuais.

Assim, quando algo dá errado, você rapidamente descobre com confiança qual componente individual falhou e o que deu errado.

• Compare isso com o fluxo de trabalho quebrado do ECS, em que a Web GUI da AWS deixa você criar um ECS service do tipo load balancer, e o questionário de deployment da GUI pergunta em quais subnets você quer fazer o deploy.

Ele avisa que você não pode implantar em ambas, públicas e privadas, e que precisa escolher uma, mas não diz o detalhe crítico da pergunta:

Essas são as subnets para o load balancer ou as subnets para as instâncias de backend?

Além disso, ele faz a pergunta de escolha de subnets uma única vez, quando deveria perguntar duas vezes para você poder seguir a melhor prática padrão de tornar o load balancer público e as instâncias de backend privadas.

O fluxo do ECS permite fazer coisas que ele deveria estar programado para impedir, como implantar um load balancer com IP público em uma subnet privada.

Isso obviamente não vai funcionar e deveria ser pego pela validação de entrada. Em vez disso, você recebe um erro evitável, junto com feedback ruim sobre por que não está funcionando.

• Outro cenário comum de debug em que o EKS brilha:

Suponha que um Engineer crie uma VPC nova para fazer alguns testes e, por engano, implante um cluster EKS ou ECS em uma VPC que não tem um NAT gateway.

• Com o ECS, você obtém zero logs e zero métricas, porque o pull da imagem do container vai falhar por falta de acesso à internet. O problema é que você fica voando às cegas, sem nenhum feedback sobre o que deu errado. O ECS exec não vem turnkey embutido na plataforma por padrão e é difícil de habilitar.

É fácil desperdiçar muitas iterações depurando inutilmente a config da ECS task ou do ECS service se você não perceber que é um problema de VPC, porque o ECS é mais uma caixa-preta com feedback ruim.

Não há nada que sequer indique que o pull da imagem falhou; você é forçado a intuir que essa deve ser a causa da falha.

• Se você cair no mesmo cenário problemático com o EKS, é muito mais fácil de resolver, porque mesmo que os worker nodes não tenham acesso à internet, o control plane é publicamente acessível por padrão. Assim, dá para usar o kubectl para obter feedback como image pull failed, que é uma boa pista sobre falta de conectividade com a internet.

3. O ECS não tem suporte nativo a volumes.

• Algo que me surpreendeu ao aprender sobre o ECS é que, se você quer injetar uma configuração ou um secret (a partir de uma config in-line em um ecs-task-definition.json ou referenciada do AWS Secrets Manager), variáveis de ambiente são a única opção oficial e nativa do ECS para carregar configuração. Não há uma opção fácil, embutida na plataforma ECS, para montar config ou secrets como arquivo.
• Essa incapacidade de injetar arquivos de configuração dinâmica de forma fácil é uma razão importante de o ECS não ter um equivalente ao conceito de Ingress Controller do Kubernetes.
• O ECS pode usar EFS para armazenamento com estado, e existem soluções gambiarra para montar arquivos, mas o ponto é que esses são todos métodos forçados que não são fáceis de implementar, porque não há suporte nativo a volumes no nível da plataforma ECS.

Há uma nuance que vale esclarecer sobre essa afirmação:

O ECS tem suporte a EFS no nível da plataforma AWS, mas não há integrações no nível da plataforma ECS que facilitem a configuração.

(Não só não é fácil, eu argumentaria que muitas vezes é mais difícil configurar EFS no ECS do que em EC2 standalone ou EKS, porque o ECS tende a se comportar como uma caixa-preta difícil de depurar, com um ciclo de feedback lento.)

• O EKS, por outro lado, tem um EFS CSI driver para configurar uma Kubernetes Storage Class. Essa integração e o suporte nativo no nível da plataforma EKS podem facilitar a configuração de EFS no EKS.)
• No EKS, config e secrets podem ser montados como variável de ambiente ou como arquivo. Statefulsets, storage classes, persistent volumes e outros recursos avançados tornam workloads com estado relativamente fáceis de implementar.

4. O nível de dificuldade do EKS tende a ser variável e paradoxal: "O EKS costuma ser difícil porque é fácil demais."

O nível de dificuldade do ECS é relativamente estático, porque o ECS tem mais restrições fundamentais. A relevância dessas nuances é que, quando uma equipe de implementação tem acesso a consultoria perspicaz baseada em experiência e usa uma boa estratégia de implementação, o EKS pode ser mais fácil que o ECS.

(Para quem não sabe, esse é um ponto de vista baseado em pensamento crítico que vai contra uma afirmação comum encontrada na documentação da AWS, de que o ECS é sempre mais fácil que o EKS.)

• Por favor, tenha paciência, porque esse insight em particular leva tempo para ser explicado, já que envolve nuances, um paradoxo empírico e o compartilhamento de algumas linhas de raciocínio essenciais para tornar o insight a seguir intuitivo:
• O EKS tem o potencial de ser mais fácil que o ECS. O ECS tem desvantagens intrínsecas e inevitáveis; a maioria das mais importantes foi mencionada antes. As desvantagens do EKS são fundamentalmente diferentes, porque tendem a ser uma propriedade emergente que surge de um paradoxo causado por vieses naturais.

Se você entende o quadro geral da desvantagem paradoxal do EKS, sua causa e como evitá-la estrategicamente, então o EKS fica muito mais fácil.

• O EKS é um ótimo exemplo de um velho ditado: "Tudo em excesso faz mal. Quando coisas boas são levadas ao extremo, elas costumam dar origem a problemas."
• O Kubernetes é bom demais, capaz demais e tão bem-sucedido que tem um ecossistema massivo. Esse ecossistema massivo é complexo, e essa complexidade, somada ao viés natural de adotar ferramentas Kubernetes que têm benefícios claros acompanhados de custos ocultos, é uma grande razão pela qual o EKS é percebido como difícil.
• Uma percepção importante é que o grande e complexo ecossistema do Kubernetes é todo opcional. Se você escolher estrategicamente minimizar seu uso, o EKS continua fácil.
• Vou dar um pouco de contexto e depois entrar em outro paradoxo relacionado:
• Uma das competências de engenharia em nível principal que tenho é a habilidade de distinguir entre solucionadores de problemas e transformadores de problemas. Transformadores de problemas são ferramentas e técnicas que resolvem 1 problema em troca de criar N novos problemas, e tendem a ser más ideias e coisas a evitar, a menos que você realmente saiba o que está fazendo e tenha refletido sobre várias consequências de segunda ordem.
• Essa lógica é o motivo pelo qual considero más ideias as seguintes:

Kubernetes Operators, Statefulsets, usar APIs que não são v1 (operators que implantam statefulsets usando APIs alpha são um caso clássico), service meshes e nginx-ingress controller. E não podemos esquecer do Hashicorp Vault: "Friends don't let friends use hashi-vault".

• Alguns exemplos de problemas introduzidos: CVEs críticos, sobrecarga de manutenção e atualizações forçadas do EKS levando, eventualmente, a atualizações forçadas das aplicações.

Não é incomum atualizações trazerem breaking changes, e agora há novas formas pelas quais seus serviços podem falhar e um raio de impacto maior se algo der errado, o que significa que você precisa de testes extras.

• Uma configuração suficientemente complexa pode criar problemas relacionados a IaC, automação, documentação, gargalos de competências, questões de pessoal e muito mais.
• Com esse contexto em mente, eis o paradoxo relacionado:

Se alguém tem uma má ideia, o ECS é restritivo, inflexível e difícil o suficiente para deixar claro logo de cara que essa má ideia vai dar trabalho para implementar. Vai ser difícil até para fazer o mínimo, então o mínimo é o que vai ser feito, e como resultado, o ECS acaba sendo visto como mais fácil.

• O EKS, por sua vez, é flexível demais e capaz demais para o próprio bem.

Quando alguém tem uma má ideia, o EKS oferece tanta liberdade e facilidade de implementação que qualquer ideia pode ser implementada, inclusive más ideias.

É chato quando más ideias são compartilhadas, porque o Kubernetes é tão fácil de usar que outras pessoas conseguem facilmente adotar e implementar más ideias sem perceber.

Aí, quando os problemas acontecem, o Kubernetes leva a culpa de ser difícil demais.

A verdade oculta é que muitos problemas podem ser evitados simplesmente evitando más ideias.

Ou, dito de outro jeito: "O EKS é difícil quando as pessoas o tornam difícil."

• Os insights acima podem ser combinados para formar a base de uma boa estratégia de implementação do EKS:

Basicamente, tente se ater a funcionalidades simples do EKS adotando como regra prática preferir funcionalidade nativa, considere regularmente o princípio YAGNI e evite recursos que não estão disponíveis no ECS. (O ECS não tem propriamente operators, ingress controllers, persistent volumes, APIs não estáveis, um ecossistema massivo de ferramentas de terceiros, e o suporte ao AWS App Mesh está sendo removido.)

Se você comparar os dois com essa estratégia em mente, chega bem mais perto de uma comparação justa; só que agora o EKS começa a parecer uma saborosa Maçã Honeycrisp.

5. As atualizações do ECS são extremamente raras, o que é uma grande vantagem em termos de estabilidade e por evitar o trabalho operacional associado a clusters.

• Em teoria, uma instância Fargate on-demand poderia passar anos sem atualizar; isso evita interrupções causadas por breaking changes de atualizações.
• A plataforma EKS, mais cedo ou mais tarde, vai forçar os adotantes a atualizar, e se as aplicações rodando no cluster foram negligenciadas e nunca atualizadas, há o risco de uma atualização forçada da plataforma quebrar versões desatualizadas de aplicações rodando no cluster EKS, projetadas para funcionar com versões específicas do Kubernetes.
• O nginx-ingress controller é um bom exemplo de aplicação bem conhecida que tem uma tabela listando versões específicas do Kubernetes em que versões específicas do ingress controller devem rodar.
• Um cenário relativamente comum, autoinfligido e problemático, em que algumas organizações se metem com o EKS, é contratarem um terceirizado para configurar uma solução baseada em EKS o mais rápido e barato possível. Aí, quando o contrato termina, o cluster EKS e seus workloads podem ficar intocados por anos.

Eventualmente, alguém descobre que a plataforma EKS, mais cedo ou mais tarde, força atualizações. Isso geralmente acontece depois que algo quebrou ou quando a organização designa alguém para atualizar seu(s) cluster(es) EKS no último minuto antes de uma atualização automática forçada.

É comum que um Engineer descubra que subestimou o esforço envolvido na tarefa, porque tem que atualizar múltiplos workloads implantados no cluster, além de atualizar o próprio cluster.

• Normalmente isso não é grande coisa, mas pode ser estressante fazer com prazo apertado. E, se o prazo for perdido, pode causar interrupções em produção. Especialmente porque, em geral, essas organizações jogam essa tarefa para alguém que não é especialista em Kubernetes, e clusters EKS negligenciados costumam ser resultado de trabalhos apressados mal planejados, então não têm IaC nem documentação sobre como foram configurados por um Engineer que saiu há mais de 2 anos.
• Além das atualizações forçadas, os nós EC2 do EKS têm mais cenários em que worker nodes precisam reiniciar do que um cluster ECS sobre instâncias Fargate.

(Nós EC2 podem ser reduzidos por um cluster autoscaler que economiza custos, como o karpenter.sh, que também por padrão reinicia nós on-demand a cada 30 dias para que recebam os patches mais recentes para EKS Worker Node VMs.)

• O EKS também facilita introduzir complexidade opcional em forma de karpenter.sh, kubernetes gateway-api controllers, ingress controllers e service meshes.
• A adoção desses componentes opcionais introduz risco em forma de novas formas de falhas ocorrerem, mais coisas que podem dar errado, novos cenários de modos de falha como configurações incorretas, atualizações ruins, vulnerabilidades de cadeia de suprimentos, vulnerabilidades críticas que exigem atualizações apressadas, reinicializações semifrequentes como recurso, ou breaking changes associados a atualizações.
• Uma ironia é que service meshes como o Istio têm recursos projetados para melhorar uptime, como formar um mesh multirregional entre múltiplos clusters, lógica de retry e algumas outras coisas embutidas. Na prática, no entanto, não é incomum eles serem fontes comuns de downtime.
• Uma vez que um app é implantado e está rodando, o ECS tende a ser livre de manutenção.
• Setups de EKS frequentemente têm pelo menos 3 clusters, e cada um tem múltiplos componentes, todos eles atualizam e, no conjunto, geram um trabalho de manutenção inescapável.
• Felizmente, muitos avanços permitiram minimizar esse trabalho de manutenção; um grande exemplo é o EKS Auto Mode, mas mesmo sem ele, AWS Managed Add-ons e APIs estáveis v1 para ingress e karpenter tornaram as atualizações mais fáceis, mais rápidas e sem dor de cabeça.

6. O EKS tem uma sobrecarga de manutenção inevitável e uma ordem de magnitude a mais de partes móveis em relação ao ECS, que praticamente nunca precisa de manutenção.

Esses 2 pontos negativos do EKS, aparentemente menores, geram efeitos de segunda ordem que resultam em desvantagens significativas em termos de sobrecarga operacional. Para dar um pouco de clareza ao significado contextual de "significativo", vamos usar 2 a 14 dias/ano de tempo de engenharia dedicado à manutenção do EKS como uma estimativa aproximada do que esperar.

• As características do ECS o tornam bem indulgente quando boas práticas comuns de DevOps não são conhecidas ou são intencionalmente ignoradas/minimizadas.

Admins de ECS podem ter confiabilidade apesar de padrões malvistos como:

• 1. Implementar fluxos de trabalho com uma mistura de operações manuais e automação parcial, com pouco IaC, ou automatizar o deployment de workloads, mas não o provisionamento de clusters.

(Isso pode dar certo, porque uma vez que uma equipe põe o ECS para funcionar, ele tende a continuar funcionando.)

• 2. Ignorar os benefícios de segurança de múltiplos clusters e jogar tudo em 1 cluster ECS.

(Mesmo se dev e prod forem misturados em 1 cluster ECS, isso raramente afeta a confiabilidade graças aos padrões arquitetônicos comuns do ECS, que fazem com que a maioria dos problemas possíveis tenha um pequeno raio de impacto:

É comum ECS services terem seu próprio AWS Managed LB em vez de um Kubernetes Ingress Load Balancer compartilhado. Containers Fargate recebem suas próprias VMs individuais, o que melhora o isolamento.)

• 3. Não implementar limits e requests de recursos com precisão.

(Como instâncias Fargate têm proporção de 1 ECS task para 1 VM, isso vira apenas um problema de otimização de custos, em vez de ser tanto um problema de otimização de custos quanto de confiabilidade.)

• O EKS tem partes móveis e complexidade suficientes para que a implementação rigorosa de boas práticas seja praticamente um requisito para admins que querem manter seus clusters EKS confiáveis e mantíveis a longo prazo.
• A necessidade de implementação rigorosa de boas práticas tem uma desvantagem significativa.

Tarefas associadas à implementação de manutenção e boas práticas consomem tempo de engenharia, e horas de engenharia são caras. Pior ainda, a busca por boas práticas pode levar Engineers para tocas de coelho de DevOps Yak Shaving.

DevOps Yak Shaving pode ser uma atividade perfeitamente razoável, mas também é uma toca de coelho potencialmente problemática, porque é difícil distinguir entre perfeitamente razoável, potencialmente exagerado e completamente desnecessário.

Gostaria de detalhar a importância disso, apontando que admins de ECS não só são poupados de tarefas, como também encontram menos cenários de DevOps Yak Shaving.

• Qualquer equipe que gerencie EKS rapidamente conclui que precisa de pelo menos 2 clusters EKS por questão de confiabilidade.

É fácil descobrir que atualizações de componentes do EKS ou configurações incorretas podem causar breaking changes, e que problemas em muitos componentes como ingress, DNS, CNI, karpenter.sh, service meshes e nós não saudáveis têm grandes raios de impacto.

Isso torna intuitivamente óbvio que ambientes isolados e testes de atualizações em ambientes inferiores são essenciais para a confiabilidade do EKS.

• Quando equipes de EKS se acostumam com um fluxo de promoção de ambientes, surge outra percepção comum:

Testar em um ambiente inferior só faz sentido quando os ambientes inferior e superior são relativamente parecidos entre si.

• Muitas equipes de EKS investem tempo desenvolvendo implementações rigorosas de infrastructure as code, automação ponta a ponta e pipelines de CICD que garantam que seus ambientes inferior e superior fiquem em sincronia.
• Outra experiência comum é que ambientes de dev têm mais probabilidade de mudar mais rápido, com mais frequência, e lidar com mudanças manuais. Mudanças manuais break-glass em produção para resolver interrupções e incidentes também não são incomuns.

Por isso, não é raro equipes de EKS sofrerem com config drift, em que um ambiente ativo não corresponde ao IaC e à automação definidos em um git ou em um pipeline de CICD.

Garantir que o ambiente ativo corresponda ao IaC exige ainda mais implementação rigorosa de boas práticas, o que geralmente envolve uma combinação de pipelines de CICD e implementações de GitOps.

1. O ECS pode ser a melhor escolha em cenários onde:

• Você quer projetar um app para rodar de 2 a 10 anos com máximo uptime e mínima manutenção.

Suponha que você tenha uma aplicação que raramente atualiza, como serviços de tooling internos (uma aplicação de auditoria interna customizada, por exemplo) ou uma aplicação voltada para o público que não causaria problemas significativos se fosse atingida por uma vulnerabilidade crítica de execução remota de código zero-day. (Por conta de boas práticas como usar uma imagem distroless sem shell e direitos IAM seguindo o princípio do menor privilégio.)

Nesses casos, pode fazer sentido priorizar o ponto forte do ECS de sobrecarga operacional quase zero em detrimento do ponto forte do EKS de depuração mais fácil e ciclos de feedback mais rápidos.

• Você tem aplicações relativamente simples, faz deploy de atualizações para os ambientes apenas algumas vezes por dia, tem necessidades aplicacionais e arquitetônicas estáveis que raramente mudam, ou planeja investir em um pipeline de CICD ECS customizado que só implanta padrões simples e que sempre funcionam.

Nessas circunstâncias, você provavelmente vai minimizar sua exposição às desvantagens do ECS de ser difícil de depurar quando algo dá errado e ter um ciclo de feedback lento.

• Você tem uma equipe pequena, só com desenvolvedores, e nenhum dos membros tem o mínimo de interesse ou disposição para aprender a implementar boas práticas de DevOps com rigor.

Nesse caso, o ECS é mais indulgente (em comparação com o EKS) quando boas práticas operacionais são insuficientes ou minimizadas.

2. Justificar objetivamente o EKS como melhor escolha exige uma reflexão um pouco mais cuidadosa sobre fatores situacionais:

• Tanto ECS quanto EKS são pacotes mistos, com benefícios e desvantagens que andam juntos. Dito isso, dá para pensar no ECS como mais equilibrado, com benefícios e desvantagens relativamente moderados (baixo risco, baixa recompensa). O EKS, por outro lado, é um caso de benefícios mais significativos e desvantagens moderadas (risco moderado, recompensa significativa).
• Antes de entrar nos benefícios do EKS, é prudente começar pelas desvantagens, pois considerá-las de antemão coloca você em um melhor estado mental para tirar mais proveito de uma pergunta que adiciona uma boa perspectiva:

"Os benefícios que estou enxergando, no mínimo, compensam, ou até superam, as desvantagens?"

• 1ª desvantagem do EKS: a adoção bem-sucedida do EKS exige a implementação rigorosa de boas práticas de DevOps, o que por sua vez exige disposição e um investimento significativo de recursos.

Isso pode levar mais tempo do que muita gente espera, porque "Problemas de DevOps" frequentemente exigem "Soluções de DevOps", que muitas vezes precisam vir acompanhadas de transformadores de problemas antes que soluções genuínas possam ser aplicadas.

Essa também é a razão pela qual profissionais de DevOps às vezes brincam dizendo que são yak shavers profissionais. Transforme um problema infinitas vezes, e ele degenera em tosar um yak.

(Vamos estimar grosso modo isso em 1 a 4 meses de um investimento único em esforço de engenharia.)

• Se você quer influenciar positivamente esse compromisso de tempo de 1 a 4 meses, pague o suficiente para contratar pensadores críticos que entendam as diferenças sutis entre soluções de problemas e transformações de problemas. Garanta que sua equipe entenda a lógica e o raciocínio por trás do paradoxo perspicaz de que "O EKS costuma ser difícil porque é fácil demais."

E favoreça princípios e conselhos como:

KIS (Keep it Simple), YAGNI (You aren't gonna need it), APIs estáveis v1 são suas amigas, serviços gerenciados como o AWS LB Controller devem ser preferidos no lugar de Ingress Controllers DIY como Nginx (Dica: o primeiro é uma solução e o segundo, uma transformação de problema; a varredura de vulnerabilidades do quay.io mostrou que uma imagem de 6 anos do nginx-ingress-controller tinha 76 vulnerabilidades críticas, uma média de 1 CVE crítico por mês!), e o EKS Auto Mode vale a pena considerar.

(O Auto Mode também é uma transformação de problema, pois tem algumas desvantagens como introduzir um efeito caixa-preta e aumentar custos; ainda assim, frequentemente vale a pena para clusters greenfield de pequena escala.)

Faça essas coisas, e o EKS pode permanecer relativamente fácil.

Lembre-se: "O EKS é difícil quando as pessoas o tornam difícil."

• 2ª desvantagem do EKS: ele tem um grau inescapável de trabalho de manutenção.

(Vamos estimar grosso modo em 2 a 14 dias de manutenção por ano para 3 clusters.)

• Vale apontar que o EKS Auto Mode, lançado em dezembro de 2024, pode ser de grande ajuda para minimizar as 2 principais desvantagens do EKS.
• O Auto Mode do EKS elimina muito trabalho de pré-requisitos (envolvido na configuração de add-ons comuns), conhecimento prévio necessário, manutenção contínua, e até modos de falha, já que consegue evitar breaking changes usando e automatizando upgrades apenas de add-ons baseados em APIs estáveis v1.
• Dito isso, ele não elimina a manutenção totalmente, e tem algumas desvantagens em termos de custos adicionais e de transformar o EKS em uma caixa-preta maior, o que prejudica a debugabilidade.

(Ele roda pods karpenter.sh nos nós gerenciados do control plane, então você não consegue acessar os logs dos pods karpenter.sh, e esses logs frequentemente são necessários para depurar casos extremos.)

• Pré-requisitos são outra coisa que o EKS Auto Mode não elimina totalmente. Esta página vinculada menciona que você precisará fornecer uma classe de ingress específica do Auto Mode, anotações de serviço de load balancer e uma storage class que faça referência a um EBS Volume Provisioner específico do Auto Mode para usar todos os recursos do Auto Mode.
• Também é útil saber de antemão que é difícil migrar de Auto Mode desabilitado para Auto Mode habilitado. À primeira vista, o portal web do EKS faz parecer que o Auto Mode do EKS pode simplesmente ser ligado e desligado.

No entanto, se você ler esta página de Referência de Migração, vai descobrir que uma migração in-place é um processo manual muito doloroso, a tal ponto que frequentemente é mais fácil simplesmente implantar um novo cluster e fazer uma migração blue-green para ele. A dificuldade da migração ocorre porque o EKS Auto Mode tem sua própria classe de ingress única, classe de load balancer e EBS CSI volume provisioner. Por isso, se você tentar fazer uma migração in-place do EKS Auto Mode desabilitado para habilitado em um cluster preexistente, vai precisar recriar serviços do Kubernetes do tipo Load Balancer, objetos Ingress e quaisquer PVCs que você criou antes do Auto Mode ser habilitado.

• Diante dessas questões menores e dos custos adicionais, não faz sentido recomendar o EKS Auto Mode em todos os casos. Mesmo assim, acho que frequentemente é uma boa escolha para clusters greenfield de pequena escala que precisam ser gerenciados por equipes novatas em EKS. Também acho que o EKS Auto Mode faz muito sentido para quem planeja ter mais de 6 clusters de longa duração.
• Agora dá para falar sobre benefícios, e o mais importante a destacar é uma economia de tempo que tem o maior impacto em compensar os custos de tempo mencionados antes.
• O EKS oferece um benefício significativo em depuração mais fácil e rápida e em ciclos de feedback mais ágeis, e nas circunstâncias certas (geralmente o desenvolvimento envolve depuração contínua) só essa característica já garante uma vitória, gerando economia de tempo suficiente para compensar os custos de tempo e produzir uma economia líquida, somada aos outros benefícios do EKS.
• Veja alguns cenários comuns em que o EKS fica fácil de justificar: seu app faz deploy para os ambientes com frequência suficiente para justificar um pipeline de CICD que seja o mais rápido possível, tem mudanças frequentes, integrações complexas, arquitetura orientada a serviços, está passando por uma transformação de monolito para arquitetura orientada a serviços usando o padrão strangler, ou tem complexidades que tornam a capacidade de depurar facilmente com um ciclo de feedback rápido um ativo de altíssimo valor.
• Você espera que alguns dos seus apps tenham tráfego muito instável e que escalar o mais rápido possível possa ser um fator decisivo?

Se sim, as opções avançadas de escalonamento do EKS (alimentadas pelo add-on keda.sh), como escalar para zero e escalonamento baseado em cron schedule, podem virar vantagens significativas, além de oportunidades de economia de custos.

• Algum dos seus apps tem requisito rígido de carregar configuração de aplicação como arquivos? Opções de armazenamento robustas?
• Você precisa, ou vê benefício suficiente, em ter acesso a funcionalidades avançadas e padrões de engenharia como RBAC em nível de cluster, policy as code, GitOps, load balancing avançado, integrações OIDC/Authn/z e, em geral, customização que torne fácil implementar qualquer ideia de formas que ofereçam uma ótima experiência para os Engineers?
• O EKS pode ser uma ótima escolha para projetos em que seus benefícios superam a sobrecarga de manutenção de 2 a 14 dias/ano que sua adoção exige, e em que você consegue convencer os stakeholders a topar 1 a 4 meses de tempo único de investimento para implementá-lo de acordo com as boas práticas.

3. Aplicações com estado são um cenário comum o suficiente para justificar uma discussão baseada em regras práticas:

• O EKS facilita rodar aplicações com estado e tem bom suporte para elas, mas só porque é fácil não quer dizer que seja automaticamente uma boa ideia. Tentei oferecer uma visão bem informada do nível de dificuldade do EKS que vem junto com seus benefícios. Mas eis um esclarecimento importante: o nível de dificuldade que mencionei até aqui assume que você está rodando aplicações stateless (e talvez alguns apps com estado em que perda de dados é aceitável, como caches valkey/redis ou ferramentas de monitoramento auto-hospedadas como o stack de observabilidade PLG do Grafana Lab).
• Muitas vezes, as pessoas instalam aplicações com estado no Kubernetes sem considerar o ciclo de vida completo da aplicação, incluindo backups automatizados, restaurações automatizadas, testes e integrações de pipeline de CICD.

Quando esses pontos são considerados de verdade, a sobrecarga operacional necessária para manter uma ótima confiabilidade no longo prazo costuma ser extremamente alta.

• Alta o suficiente para considerar 3 opções:
• 1. Aceitar um risco maior de ver várias horas de downtime cerca de uma vez por ano em troca de evitar sobrecarga operacional significativa, optando intencionalmente por não implementar com rigor as boas práticas associadas a workloads com estado.
• 2. Se você precisa de uptime altamente confiável e opções mais fáceis de recuperação de desastres, transferir para um serviço gerenciado caro pode resultar em um menor custo total de propriedade.
• 3. Verificar se os stakeholders têm apetite e disposição para investir 1 a 6 meses (por aplicação/banco de dados com estado individual) de tempo e esforço de engenharia dedicados para implementar com rigor as boas práticas associadas a workloads com estado, junto com uma sobrecarga de manutenção maior.