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

Inteligência Artificial

Escalabilidade: O Engano da Resiliência em Microserviços com Kafka

Muita gente veste Kafka como se fosse armadura de resiliência e escalabilidade. Mas quando o contexto de negócio não pede, o hype vira dívida técnica. Aqui eu bato direto no ponto: microserviços não ficam magicamente resilientes só porque você jogou um Kafka no meio. Vamos destrinchar onde o dev se queima, quando Kafka realmente resolve e quando ele só adiciona latência, custos e uma bela dor de cabeça operacional.

Banco de dados

MongoDB em Produção Crítica: Quando o ‘Bala na Agulha’ Vira Risco Calculado

MongoDB é rápido de colocar no ar, flexível e ótimo para protótipos. Mas quando o jogo é sério — missão crítica, consistência, auditoria, garantias duras — ele começa a cobrar juros altos de dívida técnica. Como arquiteto que vive nas trincheiras, escrevo aqui o que quase ninguém fala: o risco não é usar MongoDB; o risco é usá‑lo sem entender o preço real.

Automação de processos com IA

O Microserviço Perfeito é um Mito — e Está Tudo Bem

Microserviço não é salvador da pátria — é ferramenta. E, como qualquer ferramenta, corta dos dois lados. Depois de anos nas trincheiras vendo sistemas virarem Frankensteins distribuídos, fica claro: o microserviço perfeito não existe porque o negócio real não é perfeito. Neste artigo, mostro onde os devs se queimam, como evitar a gourmetização arquitetural e quando reduzir complexidade vale mais do que ficar perseguindo um ideal técnico que só existe em conference talk.