A Armadilha das Automações em Microserviços: Quando o K8s Entra Antes do Domínio

Onde a Automação Vira Areia Movediça

Kubernetes não é o vilão. O problema é colocar automação demais cedo demais. Acontece quando o time ainda nem entendeu os limites de contexto, mas já está criando pipelines, sidecars, retries automáticos e um zoológico de CRDs. Resultado: tráfego fantasma, incidentes que ninguém sabe quem causou e mais tempo configurando do que entregando valor.

Microserviços ruins automatizados continuam ruins.

Referências de campo mostram isso. Em discussões de devs experientes, a reclamação é a mesma: times reinventando roda, criando plataformas que ajudam pouco e geram mais ruído do que solução.

Como Sair do Buraco: Automação Guiada pelo Domínio

Automação só faz sentido quando o limite de contexto está claro e o fluxo de negócio é estável. A base é simples:

• Modelar o domínio primeiro.
• Automatizar apenas o que já é repetitivo e previsível.
• Evitar operadores mágicos e pipelines cheios de lógica não versionada.

Automação boa é entediante: previsível, transparente e barata de manter.

Implementação de Sênior: Orquestração Simples Alinhada ao Domínio

Aqui vai um exemplo de como automatizar o deployment de um bounded context sem transformar o cluster em um parque temático de YAML. Nada de fluxos mágicos ou CRDs obscuros — apenas o essencial.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: billing-context
  labels:
    context: billing
spec:
  replicas: 2
  selector:
    matchLabels:
      app: billing-service
  template:
    metadata:
      labels:
        app: billing-service
        context: billing
    spec:
      containers:
        - name: billing
          image: registry.dev/billing:1.4.2
          env:
            - name: DOMAIN_CONTEXT
              value: billing
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 8080

Note o essencial: labels alinhadas ao contexto, zero malabarismo, probes claras e configuração explícita. Sem isso, qualquer automação posterior vira um castelo de cartas.

O Preço de Cada Escolha: Ou Você Controla a Automação, ou Ela Te Controla

Automatizar tudo cedo demais cria:

• dívida técnica difícil de remover;
• over-engineering embalado como “plataforma”;
• debug impossível quando algo desanda;
• dependência de especialistas em YAML e não do domínio.

Por outro lado, adiar automação onde ela já faz sentido gera esforço manual sem fim e risco de erros operacionais. O equilíbrio é simples: **o domínio manda, a automação obedece**.

Direto das Trincheiras

• Se uma automação precisa ser explicada em mais de 10 minutos, ela está complexa demais.
• Automatize só depois que a equipe conseguir descrever o fluxo de negócio sem hesitar.
• Todo pipeline deve ter dono — se ninguém assume, é porque ninguém entende.

Fontes

Estou curioso para saber as experiências das pessoas com times …, Diego Dias – RotaDefault

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