Kubernetes Não é Milagre: A Verdade Crua Sobre Escalabilidade Que Ninguém Te Conta

A Dor Real: Onde a Escalabilidade Vira Ilusão

A maioria dos times corre para o Kubernetes como se fosse um passe de mágica para desempenho. **Mas não existe escalabilidade grátis.** Existe CPU, memória e conta de nuvem. E o pior: existe cluster mal dimensionado tentando resolver gargalos que não são de infraestrutura, e sim de modelagem de domínio ruim.

É aqui que muitos devs se queimam: o problema nunca foi falta de pods. Foi falta de entendimento do fluxo de negócio, filas mal configuradas, APIs acopladas e serviços que viraram monolitos distribuídos sem ninguém admitir.

Solução Pragmática: Escale o que importa, não o cluster inteiro

Escalar no Kubernetes só funciona quando você define métricas reais. **Se o HPA está medindo CPU mas o gargalo é I/O na base, você está empilhando pods inúteis.** O caminho é simples: observabilidade antes de escalabilidade.

Você não “ganha” escala — você a projeta. E para isso é obrigatório ter tracing, métricas e logs antes de liberar o HPA para brincar de multiplicar réplicas.

Implementação de Sênior: HPA com métrica correta, não mágica

A seguir, um exemplo real que uso em produção: escalonamento baseado em fila (RabbitMQ) via API customizada e metric server dedicado. Porque CPU quase nunca é o gargalo — mas fila estourada sempre é.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: worker-service
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Pods
      pods:
        metric:
          name: rabbitmq_queue_messages_ready
        target:
          type: AverageValue
          averageValue: 30

Esse HPA escala apenas quando a métrica certa dispara: quantidade de mensagens prontas para processamento na fila.

**Isso é escala de verdade: baseada no que o serviço faz, não no que o cluster acha que ele está fazendo.**

O Custo da Escolha: Kubernetes Não é de Graça e Muito Menos Simples

Escolher Kubernetes significa assumir complexidade operacional, curva de aprendizado e custo financeiro. O trade-off é claro:

Se você precisa de elasticidade fina e isolamento de workload: Kubernetes entrega.
Se sua aplicação é simples, estável e previsível: você está contratando over-engineering por esporte.
Se o negócio não exige escala elástica: o cluster vira dívida técnica disfarçada de modernidade.

**Kubernetes é poderoso, mas cobra aluguel caro.**

Direto das Trincheiras: 3 Dicas Práticas

Não habilite o HPA antes de instrumentar o serviço com métricas reais. Você vai escalar o sintoma, não a causa.
Se seu cluster vive estável com 2 réplicas, você provavelmente não precisava de Kubernetes.
Antes de migrar, desenhe o fluxo de negócio em um quadro branco. Sempre aparece um gargalo que YAML nenhum resolve.

Fontes e Leituras Relacionadas

Arquitetura de Software – Apenas mais um blog de tecnologia,
#TheDevConf 2025 |TDC SÃO PAULO – The Developer’s Conference

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! 😉

Desenvolvimento de software

A Falácia da Escalabilidade Horizontal em Microserviços

Microserviços viraram sinônimo de solução mágica. Mas, nas trincheiras, a tal escalabilidade horizontal infinita se mostra mais fantasia do que arquitetura. Neste artigo, entro direto no ponto: por que adicionar mais instâncias não resolve gargalos reais, onde a dor aparece e como desenhar sistemas que escalam de verdade — sem over-engineering e longe da gourmetização técnica.

Feat

Mensageria vs Chamadas Diretas: o conflito que mais derruba arquiteturas de microserviços

Microserviço não é filosofia zen: é engenharia. E quando a galera mistura hype com decisões de conectividade, nasce uma fábrica de latência, acoplamento e dívida técnica difícil de pagar. Este artigo corta o romance e mostra, no tom direto do Rei Nascimento, quando usar mensageria, quando usar chamadas diretas e como evitar over-engineering que só engorda o diagrama e trava o negócio. Sem gourmetização — só trincheira.

Arquitetura de Software

AWS Lambda Não é Milagre: Por Que a Autoescalabilidade Vai te Deixar na Mão

Muita gente compra a promessa de que o AWS Lambda escala magicamente e resolve qualquer problema de carga. Conversa. Lambda escala, sim, mas escala do jeito que a AWS quer, no ritmo que ela quer e cobrando por cada milissegundo de ilusão. Como arquiteto que já levou bala na trincheira, explico por que confiar na autoescalabilidade do Lambda é abrir espaço para gargalos invisíveis, estouros de custo e comportamentos imprevisíveis no seu sistema.