Kubernetes Não É Padrão de Ouro: É Armadilha se Você Não Souber Por Quê Está Usando

A Dor Real: Quando o Cluster Vira a Aplicação

O erro clássico é simples: a equipe pega um app de duas APIs, um banco e um worker, e decide que precisa de K8s porque ‘todo mundo está usando’. Resultado: metade do backlog vira YAML, CRD, autoscaler, ingress, service mesh e logs custando um rim.

Aqui nasce a sobreengenharia: quando o problema real não é escala, resiliência ou multi-tenant, mas a ansiedade tecnológica.

Em fóruns como r/kubernetes e r/mlops, o padrão se repete: gente usando Helm charts gigantes, deployments com sidecars sem necessidade e clusters que custam mais do que a própria aplicação gera em receita. Todo mundo repete o mantra da nuvem, mas ignora o contexto de negócio.

A Solução Pragmática: Kubernetes Só Onde Ele Faz Sentido

Use K8s quando você realmente precisa de:

Escala horizontal recorrente
Tráfego instável ou picos intensos
Time multipartes mantendo serviços independentes
Observabilidade padronizada e pipelines maduros

Se o seu caso é menor que isso, considere k3s, ECS Fargate, Nomad ou até uma VM bem configurada. Cloud não é religião.

Implementação de Sênior: Como Checar Sobrecarga no Seu Cluster

Abaixo um checklist automatizável usando uma Job simples no cluster que detecta sobreengenharia básica inspirada em ferramentas como as citadas no r/mlops (ex.: k8s‑detective):

apiVersion: batch/v1
kind: Job
metadata:
  name: k8s-sanity-check
spec:
  template:
    spec:
      containers:
      - name: sanity
        image: bitnami/kubectl:latest
        command:
        - "/bin/bash"
        - "-c"
        - |
          echo "> Pods sem requests/limits:";
          kubectl get pods -A -o json | jq '.items[] | select(.spec.containers[].resources.requests.cpu == null)' | wc -l;
          echo "> Deployments com mais de 3 sidecars:";
          kubectl get deploy -A -o json | jq '.items[] | select(.spec.template.spec.containers | length > 3) | .metadata.name';
      restartPolicy: Never
  backoffLimit: 0

Isso é sênior porque ataca o problema real: excesso de camadas. Nada de poetizar arquitetura; identifique o que está pesando o cluster.

Direto das Trincheiras

Se você precisa de mais de 10 CRDs para rodar sua app, pare e pergunte: o sistema está servindo a você ou você está servindo ao sistema?
Log custa dinheiro. O New Relic já bate nessa tecla. Defina TTL curtos para logs de debug e sempre traceie antes de logar.
Evite service mesh até o último momento. 80% dos sistemas não precisam disso, só confundem o time.

O Custo da Escolha: Kubernetes Não É de Graça

Adotar K8s cedo demais cria três dívidas pesadas:

Custo operacional (clusters inchados, nós subutilizados, storage mal configurado)
Custo cognitivo (onboarding lento, debugging mais complexo)
Custo financeiro (logs, métricas e monitoramento podem virar uma bola de neve)

Não usar Kubernetes também tem custo: menos automação, menos isolamento e menos elasticidade. Mas é um trade-off consciente, não uma receita universal.

Fontes

CodeModeToon : r/mlops, How to Optimize Log Management Costs Ebook | New Relic, K8s é muito complexo. Posso k3s em produção? : r/kubernetes

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

Kafka vs RabbitMQ: a verdade nua sobre escalabilidade em microserviços

Chega de romantizar mensageria. Quando o sistema começa a chiar, fila travando e consumidor engasgando, é aí que o arquiteto leva culpa. Kafka e RabbitMQ não são mágicos, têm propósitos distintos — e escolher errado vira dívida técnica que assombra por anos. Neste artigo, trago a visão de trincheira: onde cada um brilha, onde cada um quebra, e quando abandonar o hype e focar no que realmente resolve o problema do negócio.

Banco de dados

Mensageria em Microssistemas: Quando Ela Entrega Valor — e Quando Só Aumenta Sua Dívida Técnica

A verdade nua e crua: muita gente coloca mensageria em microserviços porque viu num diagrama bonito no slide do arquiteto da moda. Só que hype não paga boleto — e muito menos salva sistema mal modelado. Aqui eu explico onde a mensageria realmente resolve dor de negócio, quando ela vira over-engineering e como implementar sem transformar sua stack em um zoológico distribuído impossível de manter.

Discussões

A Ilusão do Low‑Code: Quando a Promessa de Velocidade Destrói Sua Arquitetura

Low‑code funciona… até o dia em que você precisa entender o que realmente está acontecendo lá dentro. Como arquiteto nas trincheiras, já vi mais projetos ruírem por dependência cega em plataformas mágicas do que por falta de framework moderno. Neste artigo, vou direto à dor: o low‑code vende eficiência, mas frequentemente entrega dívida técnica embrulhada para presente. Hora de desmontar o hype e mostrar onde ele realmente funciona — e onde vira armadilha arquitetural.