O Buraco Onde Todo Mundo Cai: O Cluster Que Vira Monstro
O problema não é o Kubernetes. O problema é usar K8s para resolver dores que você não tem.
Já vi empresa com 5 microsserviços rodando em um cluster mais complexo do que o próprio produto. O time começa animado: autoscaling, deployments, sidecars, operators… e no fim estão enterrados em YAML, debugging distribuído e um pipeline CI/CD que parece um ritual arcano.
A real: a abstração prometida vira dívida técnica quando o time não domina a ferramenta ou quando o contexto de negócio não justifica esse nível de orquestração.
As referências não mentem: comunicação excessiva, serviços demais, camadas demais — tudo vira ruído. (Azure Architecture Center, LinkedIn sobre complexidade, Nous sobre stack inflada).
Como Resolver Sem Sofrer: Orquestração Na Medida Certa
Não existe bala de prata, mas existe pragmatismo:
- Se seu tráfego é baixo a moderado: prefira plataformas gerenciadas (ECS Fargate, Cloud Run, Nomad).
- Se precisa mesmo de K8s: use distribuições simplificadas (K3s, AKS com profiles enxutos).
- Evite a gourmetização: nada de Service Mesh para app interno de CRUD.
Orquestração só é valor quando reduz o caos, não quando o amplifica.
Implementação de Sênior: Um Deployment Enxuto e Real
Aqui vai um exemplo direto da trincheira: um deployment limpo, sem plugins mágicos, sem abstrações desnecessárias — apenas o essencial para rodar um serviço stateless.
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-pedidos
spec:
replicas: 2
selector:
matchLabels:
app: api-pedidos
template:
metadata:
labels:
app: api-pedidos
spec:
containers:
- name: api-pedidos
image: reymaster/api-pedidos:1.0.0
resources:
requests:
cpu: "150m"
memory: "256Mi"
limits:
cpu: "300m"
memory: "512Mi"
ports:
- containerPort: 8080Simples. Direto. Funcional. É isso que 80% das aplicações realmente precisam.
Direto das Trincheiras: 3 Dicas Para Evitar o Over-Engineering
- Comece pequeno: valide se o problema realmente precisa de K8s antes de montar um cluster corporativo.
- Não copie arquiteturas da Netflix: eles têm centenas de engenheiros só para manter isso. Você não.
- Cuidado com abstrações sobre abstrações: cada camada adicionada tem custo real em debugging, latência e governança.
O Custo da Escolha: Quando Usar K8s é Genial e Quando é Burrice
Escolher Kubernetes é assumir um contrato caro. Ele exige especialistas, monitoramento maduro, esteira robusta e serviços que realmente justifiquem a elasticidade.
Vale a pena quando:
- Você opera dezenas de serviços independentes.
- Tráfego é altamente variável.
- Precisa de portabilidade entre clouds.
É burrice quando:
- Seu sistema cabe em um monolito saudável.
- O time não tem experiência com infraestrutura distribuída.
- O contexto de negócio muda mais rápido do que sua infra consegue acompanhar.
Fontes
Estilo de arquitetura de microsserviços – Azure Architecture Center …, A Complexidade É Inerente? Sim, Mas Nem Sempre É Necessária, Stack sob medida: como escolher tecnologias que não travam o …
Obrigado por acompanhar essa reflexão até o fim!
Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog, onde descascamos outros hypes da nossa área.
Valeu e até a próxima! 😉
