O kubernetes gerenciado virou a resposta padrão para quem pergunta como rodar containers em produção, mas nem todo SaaS precisa dele no primeiro dia. Neste comparativo técnico, coloco lado a lado o kubernetes gerenciado (EKS, GKE, AKS e equivalentes de outros provedores) e a combinação clássica de Docker Compose em uma VM Linux, olhando arquitetura, operação, custo e maturidade do time.
A ideia não é declarar um vencedor. É mostrar onde cada abordagem se sustenta e onde ela começa a cobrar juros técnicos.
Como cada arquitetura funciona
Docker Compose em um host único
O Compose descreve serviços, redes e volumes em um arquivo YAML, e o Docker Engine executa tudo em um único nó. Na frente, normalmente fica um reverse proxy como Traefik ou Nginx terminando TLS. A rede é uma bridge local, os volumes ficam no disco da VM e o deploy é, em geral, um docker compose pull && docker compose up -d disparado por pipeline via SSH.
services:
api:
image: registry.exemplo.com/api:1.4.2
restart: unless-stopped
env_file: .env
healthcheck:
test: [CMD, curl, -f, http://localhost:8080/health]
interval: 30s
retries: 3
O modelo é simples e previsível. O custo dessa simplicidade: o host é ponto único de falha, a escala é vertical e atualizações sem indisponibilidade exigem scripts ou um proxy bem configurado.
Kubernetes gerenciado: o control plane fica com o provedor
Em um kubernetes gerenciado, o provedor opera API server, etcd, scheduler e controllers, com alta disponibilidade e upgrades assistidos. Você cuida dos worker nodes (ou escolhe um modo mais abstrato, quando o provedor oferece) e dos manifests. O núcleo do modelo é o reconciliation loop: você declara o estado desejado e os controllers trabalham continuamente para alcançá-lo.
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 1
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
spec:
containers:
- name: api
image: registry.exemplo.com/api:1.4.2
readinessProbe:
httpGet:
path: /health
port: 8080
resources:
requests:
cpu: 250m
memory: 256Mi
limits:
memory: 512Mi
Aqui entram Service, Ingress, HPA, PodDisruptionBudget, ConfigMap e Secret. Cada peça resolve um problema real, mas também adiciona superfície de configuração para o time dominar.
Prós e contras na prática
Docker Compose
- Prós: curva de aprendizado baixa, ambiente de desenvolvimento muito próximo ao de produção, poucos componentes para depurar e custo de infraestrutura mínimo.
- Contras: sem scheduling entre nós, sem autoscaling nativo, rollout sem downtime depende de engenharia própria e a recuperação de falha do host é manual ou semiautomatizada.
Kubernetes gerenciado
- Prós: rolling updates com probes, self-healing, autoscaling horizontal, isolamento por namespace, RBAC, ecossistema amplo (Helm, Kustomize, operators, service mesh) e portabilidade razoável entre provedores.
- Contras: complexidade operacional real, curva de aprendizado íngreme, custo fixo de cluster (muitos provedores cobram pelo control plane; confira a tabela vigente) e risco de overengineering em produtos pequenos.
Um ponto que costuma ser subestimado: o kubernetes gerenciado não elimina operação. Ele muda o tipo de operação. Você deixa de se preocupar com etcd, mas passa a lidar com versões de API depreciadas, upgrades de node pool, CNI, ingress controller, políticas de rede e requests/limits mal dimensionados.
Trade-offs: custo, observabilidade e deploy
Custo. Compose em uma VM bem dimensionada tende a ser a opção mais barata para cargas pequenas e médias. O kubernetes gerenciado compensa quando o aproveitamento de recursos melhora com bin packing, autoscaling e múltiplos serviços compartilhando nós. Sem requests e limits bem calibrados, porém, o cluster vira apenas uma VM cara com mais camadas. Para atacar esse tema com método, vale ler Custo de Cloud: como reduzir até 70% com DevOps na prática.
Observabilidade. No Compose, logs do Docker, métricas do host e um agente de coleta resolvem boa parte dos casos. No kubernetes gerenciado, a observabilidade passa a ser requisito: métricas por pod, eventos do cluster, logs centralizados e alertas sobre estado de rollout. Sem isso, a plataforma fica opaca justamente quando mais precisa de transparência.
Deploy e CI/CD. O pipeline muda de natureza. No Compose, o artefato é uma imagem e o deploy é uma troca de container. No cluster, o artefato é imagem mais manifest versionado, idealmente aplicado por GitOps ou por kubectl/Helm com credenciais restritas. Se você ainda está estruturando essa etapa, o tutorial Deploy Automatizado com GitHub Actions e Docker: Tutorial Passo a Passo mostra uma base sólida que serve de ponto de partida para qualquer um dos dois caminhos.
Time e bus factor. Uma stack só é boa se o time consegue operá-la às 3h da manhã. Um kubernetes gerenciado nas mãos de uma única pessoa que entende o cluster é um risco maior do que um Compose simples e bem documentado.
Quando escolher cada um
- Compose em VM: MVP, SaaS em fase inicial, poucas dependências, tráfego previsível, time pequeno e tolerância a janelas curtas de manutenção.
- Kubernetes gerenciado: múltiplos serviços com ciclos de release independentes, necessidade de autoscaling, requisitos de alta disponibilidade, ambientes efêmeros por pull request e times com capacidade de manter a plataforma.
- Meio-termo: serviços gerenciados de containers do provedor (como plataformas serverless de containers) ou Docker Swarm/Nomad em cenários específicos, quando você quer orquestração sem toda a carga do ecossistema Kubernetes.
Um caminho pragmático é preparar a aplicação para migrar sem pressa: seguir os princípios de 12-factor, expor endpoints de health, externalizar configuração e estado, versionar imagens de forma imutável e manter o pipeline agnóstico ao destino. Assim, a decisão por kubernetes gerenciado vira uma evolução planejada, não uma reescrita de emergência.
Conclusão
O kubernetes gerenciado entrega resiliência, padronização e escala, mas cobra em complexidade e custo fixo. Docker Compose entrega velocidade e simplicidade, mas tem um teto claro. Escolha pela dor real do seu produto hoje, com um plano de evolução definido, e não pela moda do momento. Plataforma boa é a que seu time consegue operar com segurança e que acompanha o crescimento do negócio.
