A Dor Real: O dia em que o cluster virou o seu maior inimigo
Microserviços já são complicados por natureza. Agora junte isso com um Kubernetes mal planejado e você cria um monstro corporativo que ninguém controla. **A promessa de elasticidade vira uma fábrica de incidentes.**
O que vejo nas trincheiras é simples: times adotam Kubernetes achando que é “só subir os YAMLs”. Mas esquecem que cada microserviço precisa de:
- Política de rede
- Gerenciamento de secrets
- Health checks bem escritos
- Requests/limits realistas
- Banco de dados resiliente a picos inesperados
Quando o cluster escala errado, quem paga é o banco de dados — e aí nasce a **dívida técnica mais cara**: incidentes silenciosos de performance, difícil rastreabilidade e um grafo de dependências que ninguém mais entende.
A Solução Pragmática: Simplifique antes de orquestrar
A saída não é abolir o Kubernetes. É entendê-lo no contexto de negócio. Se sua empresa não tem tráfego imprevisível e não faz deploy contínuo de centenas de serviços por dia, você provavelmente não precisa de um cluster com 40 operadores rodando de fundo.
Pragmatismo significa:
- Usar plataformas que escondem a complexidade quando faz sentido (como Fury ou soluções gerenciadas).
- Deixar o Kubernetes para times com maturidade real em observabilidade e automação.
- Evitar o over-engineering: container não é desculpa para transformar seu banco em um pesadelo distribuído.
Implementação de Sênior: Observabilidade antes de escalar
Quer evitar que o Kubernetes destrua seu banco? Monitore o impacto de cada microserviço no cluster e no banco antes de liberar autoscaling.
Aqui vai um exemplo realista de configuração HPA com limites seguros e um endpoint bem definido para health check:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: pedidos-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: pedidos-service
minReplicas: 2
maxReplicas: 6
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60
---
apiVersion: v1
kind: Service
metadata:
name: pedidos-liveness
spec:
selector:
app: pedidos
ports:
- port: 8080
targetPort: 8080
---
# Exemplo de endpoint real para saúde do serviço
# (Node.js apenas como referência)
const express = require('express');
const app = express();
app.get('/health', async (req, res) => {
const dbOk = await pingDatabase();
if (!dbOk) return res.status(500).send('DB-error');
res.send('OK');
});
Esse é o mínimo para não transformar o cluster em um canhão apontado diretamente para o seu banco.
Direto das Trincheiras
- Evite autoscaling sem proteção no banco: ele vai escalar antes do seu RDS/CloudSQL conseguir acompanhar.
- Reduza microserviços que só existem para atender diagramas bonitos — serviços “finos demais” explodem o tráfego interno.
- Antes de migrar para Kubernetes, descubra o que realmente dói: implantação? resiliência? rastreabilidade? Kubernetes não resolve cultura ruim.
O Custo da Escolha: Kubernetes não é neutro
Adotar Kubernetes cedo demais cria uma dívida técnica operacional difícil de pagar. Mas ignorá-lo quando o negócio exige escala agressiva também é um erro caro.
Você precisa entender quando:
- Usar: seu tráfego é volátil, você faz centenas de deploys/dia, e seu time domina automação.
- Evitar: você só quer subir meia dúzia de serviços e manter o banco saudável.
No fim, a questão não é Kubernetes. É maturidade.
Fontes
30.000 deploys diários: desvendando os segredos do Mercado Livre
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! 😉
