ECS ou EKS: containers nativos da nuvem ou Kubernetes?

A premissa por trás desta escolha está em A nuvem como sistema operacional.

Existem muitos artigos comparando os dois, explicando suas diferenças e quando escolher um ou outro. Vou fazer de um jeito um pouco diferente: vou dizer o que quero alcançar, considerando tecnologia, cultura, operação, custos, suporte e compliance, e o que escolhi para chegar lá.

Quero dar aos times de desenvolvimento uma plataforma onde eles possam construir, fazer deploy e rodar seus apps com facilidade, em conformidade com as boas práticas do time de Cloud Engineering e as políticas do time de Segurança.

Adoção mais rápida da nuvem, detalhes da nuvem abstraídos, boas práticas e políticas de segurança aplicadas, custos e permissões sob controle sem burocracia, e suporte total do provedor de nuvem.

O que eu quero fazer

Não quero gastar o tempo e o dinheiro das pessoas construindo e operando uma plataforma que acabaria limitando o que os serviços nativos da nuvem podem fazer. Quero que os desenvolvedores usem todo o potencial dos serviços nativos da nuvem, aproveitem seus recursos e integrações mais recentes e falem direto com o suporte do serviço, se quiserem. Isso não significa uso descontrolado.

Quero o mais simples possível, sem limitar nenhum serviço nem o potencial de ninguém, e sem lock-in de ferramentas, porque o pessoal de tecnologia não deveria ser limitado por ferramentas.

O que ela precisa cobrir, em mais detalhes:

Para os desenvolvedores

• Uma plataforma para rodar apps em containers, sigam eles a metodologia twelve-factor ou não.
• Os desenvolvedores não precisam se preocupar com a plataforma que roda seus containers, nem com a rede (conectividade, DNS, URLs, load balancers, target groups, regras, WAFs, security groups etc.).
• Cada app tem seu monitoramento configurado automaticamente (logs, alertas, notificações etc.).
• Os desenvolvedores podem ver com facilidade os custos de suas aplicações.

Acesso total à AWS

• Os apps têm acesso total a todos os recursos e integrações da AWS (como disparar uma task num evento do S3).
• Nenhuma camada de abstração que limite recursos nativos da nuvem, ou que exija que o desenvolvimento suporte o que a nuvem já suporta.
• Desenvolvedores com conhecimento de AWS podem usá-la: resolvem problemas sozinhos e abrem chamados no suporte da AWS diretamente, se se sentirem à vontade. O time de Cloud Engineering sempre pode ajudar, mas nunca é um intermediário obrigatório, porque isso atrasa os desenvolvedores.

Custos

• Nenhum custo desnecessário com a própria plataforma (folga de capacidade, um time de operações etc.).
• Nenhum custo quando nenhum app está rodando (para quando os ambientes de não produção estão desligados).

Governança

• As boas práticas do time de Cloud Engineering e as políticas do time de Segurança são aplicadas.
• Descentralizado, mas não descontrolado em custos, segurança e boas práticas: sem uma plataforma central que precise de ferramentas extras para gerenciar custos ou de permissões complexas.
• Os apps rodam na conta do próprio time, seguindo as boas práticas de multi-account: apps e seus serviços de nuvem ficam juntos, onde os desenvolvedores já têm acesso (mesmo que somente leitura) e onde seus custos são conhecidos.

Minha escolha

Escolhi o ECS para oferecer essa plataforma. O EKS, como costuma ser usado, falharia em vários desses requisitos.

Para oferecer tudo isso em cima da nuvem, preciso de apenas duas outras ferramentas: uma para CI/CD e uma para IaC. No meu caso, Bitbucket Pipelines e Terraform. Com Kubernetes, seriam necessárias muitas outras ferramentas, e pessoas para operá-las.

Os módulos Terraform fornecem a camada de abstração para coisas como load balancers, security groups e roles do IAM, com as boas práticas embutidas, e o Bitbucket Pipelines aplica as políticas de segurança.

Por que não o EKS?

Acho que o EKS foi desenhado para quem já depende do ecossistema Kubernetes para muitos serviços e não quer trocá-los por serviços nativos da nuvem.

O Kubernetes é útil em datacenters legados: rodar containers é muito mais eficiente do que rodar máquinas virtuais, e seus certificados, service discovery e load balancing embutidos costumam ser a melhor opção ali. É uma “nuvem numa caixa”, indispensável onde tudo o que você tem é uma plataforma de virtualização: você instala o Kubernetes em cima dela (ou em bare metal, se puder) para dar aos desenvolvedores uma plataforma parecida com a nuvem.

Se você usa Kubernetes numa nuvem e quer migrar para outra, a migração pode ser fácil, desde que você use tudo como serviços do Kubernetes. Se você só o usa para rodar containers, não tem motivo para usá-lo.

Mas se você já está na nuvem, e só na nuvem, Kubernetes é uma nuvem numa caixa, dentro de uma nuvem. Essa caixa precisa ser mantida e gerenciada, e não pelo provedor de nuvem. Isso não faz sentido para mim.

Vamos olhar a configuração de Kubernetes mais comum na nuvem: um cluster EKS central em instâncias EC2 (sem Fargate), na conta do time de Cloud Engineering, rodando todas as aplicações da empresa. Eu não gosto, pelos seguintes motivos:

• Cultura: você precisa de um time para operar o cluster. Isso lembra os velhos tempos dos clusters de virtualização centralizados, operados por um time de infraestrutura a quem os desenvolvedores sempre culpavam pelos problemas de suas aplicações, e que sempre respondia: “Mas muitos outros apps rodam no nosso cluster sem problemas!”. É exatamente o tipo de problema que a cultura DevOps veio resolver.
• Custos: além do custo das pessoas que operam o cluster (que não escala com o número de apps), é difícil separar o custo de cada app. Não só dos containers dele: alguns apps usam mais os serviços do cluster (certificados, recursos de ingress etc.), e alguns times precisam de mais ajuda para resolver problemas do que outros, porque a maturidade deles é diferente.
• Uma rede para todos os apps: a rede precisa ser muito grande, e você não consegue escrever regras de security group para nada que seja acessado pela rede, porque os apps de todos os times compartilham o mesmo espaço de endereços.
• Permissões complexas na nuvem: para a AWS, o cluster é um conjunto de instâncias EC2. Dar a cada pod sua própria role do IAM exige IRSA ou EKS Pod Identity, configurados por cluster e por app, enquanto no ECS toda task simplesmente tem sua própria role do IAM.
• Instâncias EC2 para gerenciar: os limites de CPU, memória e rede variam entre tipos de instância e restringem onde os containers cabem, então você precisa escolher tipos de instância, revisar essa escolha com frequência e evitar muita capacidade ociosa espalhada pelo cluster. Isso custa tempo das pessoas. Existem ferramentas que ajudam, alterando a configuração do cluster para você automaticamente.
• Instâncias Spot trazem complexidade: elas economizam dinheiro, mas você precisa misturar node groups Spot e on-demand, garantir que o cluster sempre tenha capacidade suficiente e manter os containers de um mesmo app fora de instâncias Spot que podem ser recuperadas ao mesmo tempo. O ECS com Fargate Spot não tem esse problema.
• O cluster central é um ponto único de falha: o próprio EKS raramente falha (fora erro humano), mas muitos times compartilhando os mesmos recursos sempre acabam em problemas. Um recurso, opção ou configuração de que um time precisa no cluster pode afetar outro time. Se um time precisa de um parsing de logs especial e você roda o parser como um DaemonSet, esse parser fica mais complexo para atender às necessidades de todos os times. Os problemas crescem com a complexidade, como sempre acontece numa coisa central que atende necessidades diferentes.

Então, rodando assim, o Kubernetes é o novo VMware, na minha opinião. Não estou falando da tecnologia em si: ele traz de volta os problemas da virtualização centralizada tradicional, os que a cultura DevOps queria resolver e que a nuvem resolveu por design.

Quando os provedores de nuvem não tinham uma plataforma gerenciada de containers, Kubernetes em máquinas virtuais era certamente a escolha. Mas hoje todo provedor de nuvem tem formas melhores de rodar aplicações em containers, com melhor integração com seus outros serviços.

Realmente não há motivo para não usar a plataforma gerenciada que se integra nativamente com todos os serviços do seu provedor de nuvem. Sério. Na minha opinião.

Por que o ECS?

Clusters ECS não custam nada por si só: são apenas uma unidade lógica de organização.

Então você pode ter um cluster ECS em cada conta de time, ou até um por aplicação, e não faz diferença: nenhum custo e nenhum esforço operacional. Com o Fargate, o ECS não é baseado em instâncias EC2, então não há políticas de scaling de EC2, folga de capacidade no cluster, atrasos de inicialização de instâncias nem limites de rede do EC2 para gerenciar.

Nenhum custo para o cluster em si, e nenhum tempo das pessoas para gerenciá-lo.

A visibilidade de custos e a complexidade de permissões se resolvem porque a aplicação roda na conta do próprio time. O modelo multi-account é a resposta para as duas.

Com ECS e Terraform você só diz: “Ei, AWS, pegue a imagem do meu container neste registry e escale conforme a necessidade, dentro dos limites X e Y.”

Você pode usar os recursos e integrações mais recentes da AWS, como disparar uma task num evento do S3 ou escalar tasks pelo tamanho de uma fila SQS, e a AWS dará suporte ao uso deles.

E isso não vale só para a AWS. Toda nuvem tem sua plataforma gerenciada para containers; no Google Cloud é o Cloud Run.

Você também pode economizar com Spot no ECS, até no Fargate! Como não há instâncias EC2, você nunca lida com a capacidade do cluster: você diz quantas das suas tasks devem rodar on-demand, e o resto roda em Spot. Uma task recuperada é simplesmente relançada, sempre mantendo o número de tasks que sua política de scaling pede.

Em outras palavras: seu app não tem impacto de desempenho, mesmo rodando em Spot, no ECS sem instâncias.

Minha opinião

Quando você está construindo algo novo, não há motivo para ir de Kubernetes.

Se você não sabe por que PRECISA de Kubernetes, não adote. Ele vem com complexidade e custo. Claro que você pode construir camadas de abstração com ferramentas, mas isso é resolver problemas que você não precisa ter.

Se você precisa de Kubernetes porque seu deploy já o usa, você não precisa dele de verdade: só está com preguiça demais de se livrar dele. Pode ser um motivo justo, já que adaptar seu deploy ao ECS custa tempo das pessoas antes de economizar dinheiro.

Se você precisa de Kubernetes porque realmente precisa, por um motivo que você conhece, e sabe que o ECS e a AWS não o atenderiam, tudo bem, mantenha! Ele funciona muito bem se você conseguir resolver os problemas de cultura que ele traz. Mesmo assim, eu preferiria deixar o app simples o bastante para ser agnóstico de tecnologia e portável para os serviços nativos de qualquer nuvem.

E o Kubernetes para multicloud?

Não acho que vale a pena. Por quê?

Todos os problemas que listei acima eram só na AWS. Imagine repeti-los em várias nuvens.

Alguém pode argumentar que o Kubernetes, com todos os serviços dentro dele, facilitaria um ambiente multicloud ou uma migração. Concordo totalmente. Mas quem quer isso?

Se você quer o mesmo app rodando containers simultaneamente em mais de uma nuvem (para ser claro), você está muito errado. Um dia vou escrever sobre isso, mas não há motivo para querer isso. Seriam tantas camadas de rede e de compatibilidade que você deixaria de usar a nuvem: teria transformado ela numa camada de virtualização legada.

Minha ideia de multicloud

Querer poder rodar apps em mais de uma nuvem (talvez o mesmo app numa nuvem ou em outra) é justo, e eu concordo.

Eu faria isso como uma abstração na camada de IaC (Terraform, no meu caso): módulos Terraform que parecem iguais para quem os usa e que usam os serviços próprios de cada nuvem para fazer o trabalho.

Ambientes de nuvem híbrida

Sim, essa é a única situação em que acho que o Kubernetes ainda é desejável.

Se você precisa rodar seus apps num ambiente híbrido, simultaneamente, vá de Kubernetes.

Você pode rodar Kubernetes em virtualização ou em bare metal no datacenter tradicional, e um cluster Kubernetes gerenciado em qualquer provedor de nuvem. Você mantém o modelo tradicional de virtualização centralizada e seus problemas, claro, mas agora com containers, que são muito melhores do que máquinas virtuais completas.

Bons artigos sobre ECS vs EKS

A maioria não toma partido: compara os dois e diz para que cada um é melhor.

Nops.io, “EKS vs ECS: The ultimate guide”

Destaques:

• “EKS has higher operational overhead due to Kubernetes’ complexity, with a higher learning curve and deeper understanding of Kubernetes required. However, it provides deeper control. In addition, the Kubernetes ecosystem is vast, with a wealth of tools, extensions, and a large community for support and development with solutions for logging, monitoring, CI/CD, security, and more. EKS is a powerful platform for developers looking to leverage the flexibility and extensibility of Kubernetes, supported by robust AWS infrastructure.”
• “AWS ECS is a proprietary AWS container management service that provides an efficient and secure way to run and scale containerized applications on AWS. ECS is deeply integrated with AWS services. It provides a seamless experience for AWS users and is designed for simplicity, with the inherent trade-off of offering less fine-tuned control and flexibility. With ECS, there’s no need to manage a control plane, nodes, or add-ons, making it easier to get started. It is advantageous for quick deployments or when a more straightforward approach suffices. In addition, with ECS you don’t have to pay for a control plane, meaning that it can potentially be cheaper.”
• “AWS EKS brings Kubernetes, an open-source container orchestration platform, into the AWS cloud. Kubernetes offers high flexibility, a robust ecosystem and community, and consistent open-source API which offers extensibility and portability. As a result, it is often more suited to complex applications, multi-cloud environments, and other situations which require more fine-grained control. EKS abstracts away some of the complexity of managing Kubernetes, allowing users to leverage the power of Kubernetes without the operational overhead of setting up and maintaining the control plane. It also automates numerous aspects of running a Kubernetes cluster, including patching, node provisioning, and updates.”

Reddit, “EKS vs ECS”

Destaques:

• “Kubernetes is like a cloud in a box. But if you’re already in the cloud, then there’s no need to have a cloud in a box, in the cloud. I used Kubernetes exclusively for about 8 months after a bunch of ECS time, and just kept thinking “this would be so much easier on ECS”. Kubernetes is like the new WordPress.. everyone just uses it because there are so many plugins/helmcharts. The whole vendor lock-in is overstated in my opinion because so much of it now makes use of cloud specific APIs anyways.”
• “ECS is the old clunky model. You need ECS, Parameter Store, Secrets Manager, ACM, SSM, Cloudwatch, etc to do what you can do in EKS. My personal pet peeve about ECS is how long it took them to give you reasonable access to your containers, especially for Fargate. It is a must for debugging. With Kubernetes it is a kubectl exec away. Look at just how much software you can install via Helm, Artifact Hub.“
• “ECS is best if you are OK with the AWS ecosystem. Fargate == ECS except you don’t have to manage the underlying hosts yourself and can fit into their performance tiers. EKS is best if you already rely on Kubernetes features, or are pursuing a scenario where you run cloud+onprem, or multi-cloud, such that you want a consistent application experience across all of those environments. IMO use ECS unless you have a compelling reason otherwise. It is just less work for you.”