• Docker e Kubernetes viraram sinônimo de “DevOps” no Brasil — mas não são, são ferramentas.
• O sinal claro de que a escolha foi equivocada: cluster Kubernetes em produção e deploy ainda levando mais de quinze minutos.
• Cultura, automação de teste e continuous delivery importam uma ordem de grandeza a mais do que a escolha de orquestrador.
• A ferramenta correta é a mais simples que resolve o problema real. Servidor bare-metal, VM, PaaS, Docker, Kubernetes — cada uma tem um nicho distinto.
• Quando o cluster tem mais pods que desenvolvedores, o problema é organizacional, não técnico.

Docker e Kubernetes não são DevOps. São complicação disfarçada de progresso.

A maioria das empresas brasileiras de médio porte que adotaram Docker e Kubernetes entre 2019 e 2024 buscava institucionalizar práticas de DevOps. O resultado operacional predominante foi o oposto: aumento de complexidade sem ganho de throughput de entrega. A CNCF Annual Survey 2023 registra que 84% das organizações estão usando ou avaliando Kubernetes em produção, e que complexidade operacional é o principal desafio relatado pelos próprios usuários. A DORA Report 2023 (Google) reforça o achado: os times de alta performance não adotam Kubernetes por padrão — adotam a ferramenta mais simples capaz de resolver o problema concreto. Plataformas legadas (bare-metal, VM, PaaS) ainda entregam performance equivalente ou superior em times de pequeno e médio porte.

A tese deste post é técnica, não editorial: o problema central nunca foi a infraestrutura. Foi a ausência de cultura, processo e automação. Containers são instrumentos de qualidade elevada quando há conteúdo a ser colocado dentro deles. Quando não há, constituem overhead de origem organizacional.

A história das 47 imagens

Um caso observado com frequência no mercado brasileiro de e-commerce entre 2019 e 2024 ilustra o padrão. Empresa de aproximadamente 300 desenvolvedores, com aplicação monolítica em servidor único Ubuntu e deploy via Capistrano levando doze minutos, decide “modernizar” a infraestrutura. A justificativa formal: alinhar a stack ao que Netflix e Google utilizam.

Linha do tempo do caso:

• 2019: cluster de quatro nós, doze microsserviços, Helm charts, GitLab CI. Deploy: vinte e cinco minutos.
• 2020: dobram o time, dobram os microsserviços. Adotam Istio como service mesh. Deploy: trinta e cinco minutos.
• 2021: incidentes começam a crescer. Adotam Datadog, Sentry, PagerDuty. Contratação de dois SREs.
• 2022: ArgoCD para GitOps. Pipeline de CI/CD vira nova fonte de incidentes.
• 2023: cluster de doze nós, 47 imagens em produção, deploy de trinta minutos. Os dois SREs pedem desligamento no mesmo mês.
• 2024: reescrita de metade dos microsserviços para monolito. Deploy volta para oito minutos.

A pergunta que não foi feita em 2019 era a única que importava: por que o deploy levava vinte e cinco minutos? A resposta era conhecida antes da migração: testes manuais, ausência de pipeline, build local consumindo dezoito minutos. Resolver isso primeiro, com CI/CD maduro e build incremental, teria custado uma fração do investimento realizado em orquestração.

Quando Docker e Kubernetes fazem sentido

Docker e Kubernetes resolvem problemas específicos. Adotá-los fora desses contextos é a fonte predominante de overhead desnecessário observado no mercado.

Docker e Kubernetes fazem sentido quando:

• **O ambiente muda com frequência.** Times polyglot, múltiplas versões de runtime, bibliotecas conflitantes. O problema do “funciona na minha máquina” é recorrente e documentado em ticket.
• **Deploys são frequentes e SLA é alto.** Dez ou mais deploys por dia. Cada minuto de fricção no processo se traduz em feature não entregue.
• **Times estão distribuídos geograficamente.** Container resolve a divergência entre ambiente local e ambiente de produção sem replicar setup manual em cada workstation.
• **CI/CD já está maduro e o container é o artefato final do pipeline.** Container, nesse cenário, é a última etapa, não a primeira.

Em todos esses casos, o ganho é mensurável. Todos os casos, porém, pressupõem que o problema de processo foi resolvido antes. Docker e Kubernetes não resolvem problema de processo. Expõem a ausência dele com mais clareza.

Quando Docker e Kubernetes são overhead que ninguém pediu

O reverso é igualmente frequente. Cenários em que a containerização é pior que a alternativa simples:

• **Aplicação monolítica, deploy semanal, time de cinco desenvolvedores.** Servidor único com `rsync` resolve. Adicionar container é abstração sem função clara.
• **Banco de dados relacional tradicional (Postgres, MySQL) em produção crítica.** Storage persistente, backup e replicação são todos mais simples em VM ou bare-metal do que em cluster Kubernetes.
• **Empresa sem automação de teste.** Container vira repositório de dívida técnica em vez de solução. A desculpa “agora está em container” substitui a correção do problema real.
• **Cultura de deploy sem pipeline de validação automatizada.** Kubernetes amplia a falta de processo. Em vez de um servidor mal configurado, passam a existir doze nós mal configurados sem rastreabilidade da versão em execução.

O sinal mais claro de que o cenário é o segundo: cluster Kubernetes em produção cuja documentação é mais complexa que a documentação do código que executa. Quando ninguém consegue explicar o que cada pod faz ou por que ele existe sem consultar Confluence, o overhead venceu o ganho.

O que é DevOps de verdade, e por que Kubernetes não entrega isso

DevOps é cultura antes de ferramenta. O framework CALMS (Culture, Automation, Lean, Measurement, Sharing), formulado por Jez Humble e Damon Edwards, descreve a arquitetura conceitual. Em termos operacionais, a aplicação prática se reduz a três pilares:

1. CI/CD maduro. Build, teste e deploy automatizados. O desenvolvedor executa git push e a mudança chega a produção sem intervenção manual. A maioria das empresas brasileiras autodenominadas “DevOps” não atende a esse critério.

2. Observabilidade. Métricas, logs e traces integrados. Quando algo falha, a resposta para o que, onde e por que chega em menos de cinco minutos, não quarenta e cinco.

3. Post-mortem sem culpados. A pergunta após incidente é “o que o sistema ensinou sobre essa falha”, não “quem foi o responsável”. Sem essa prática, o medo domina o processo de release e ninguém executa deploy.

Kubernetes, isoladamente, não entrega nenhum dos três. É possível operar o cluster mais avançado do mercado e ainda assim o pipeline permanecer travado em vinte e três minutos de build, e a investigação de incidente exigir consulta a logs distribuídos em 47 pods.

Critério de três perguntas antes de subir cluster

Antes de aprovar a próxima proposta de adoção de Kubernetes, três perguntas merecem resposta objetiva:

1. O deploy atual leva mais de quinze minutos? Em caso afirmativo, o gargalo é teste manual ou build lento, não orquestração. A ordem de solução é outra.

2. A cobertura de testes automatizados no caminho crítico é superior a setenta por cento? Em caso negativo, container amplifica a distribuição de bugs. Bugs passam a ser entregues em 47 imagens em vez de uma.

3. O time tem capacidade de operar Kubernetes em regime 24/7? Em caso negativo, a previsão é de seis incidentes críticos por trimestre. A contratação de SRE precede o cluster, ou o cluster não é aprovado.

Se qualquer resposta é “não” ou “depende”, a decisão correta é não adotar Kubernetes ainda. A sequência é voltar para VM, automatizar o que é automatizável e reavaliar a questão em horizonte de dezoito meses. A organização poupa burnout e capital.

Como decidir sem transformar tecnologia em religião

O critério de seleção é direto: a ferramenta mais simples capaz de resolver o problema real entra antes; a substituição por ferramenta mais complexa ocorre quando a anterior não aguenta a demanda. A complexidade não é objetivo; é consequência inevitável de problema real não resolvido.

Faixas de decisão operacional:

• **1 a 5 desenvolvedores, 1 aplicação, deploy diário ou menos** → servidor único (VM ou bare-metal) com script de deploy manual ou Ansible. Investimento: R$ 0 a R$ 2 mil por mês.
• **5 a 20 desenvolvedores, poucos serviços, deploy de 5 a 10 por dia** → Docker com Docker Compose, ou PaaS (Fly.io, Render, Railway). Investimento: R$ 2 a R$ 10 mil por mês.
• **20 ou mais desenvolvedores, microsserviços, deploy de 50 ou mais por dia** → Kubernetes **condicionado** à existência de SRE dedicado. Em ausência, EKS, GKE ou AKS gerenciado com suporte empresarial. Investimento: R$ 20 a R$ 100 mil por mês.
• **Acima desse porte** → Kubernetes gerenciado com platform team dedicado de 3 a 5 SREs sênior. Investimento em pessoas: R$ 200 mil ou mais por ano.

A variável determinante da decisão é orçamento e estrutura organizacional, não tecnologia. Kubernetes é caro não em licença, mas em gente qualificada para operá-lo. Quando a estrutura de gente não existe, a estrutura de cluster é investimento sem retorno.

A ferramenta é a parte fácil

A porção difícil do problema é ter testes automatizados, ter CI/CD maduro, ter observabilidade, ter prática de post-mortem e ter cultura de responsabilidade compartilhada pela produção. Nenhum desses elementos é entregue por kubectl apply. Cada um exige anos de investimento organizacional e nenhuma biblioteca mágica.

A próxima vez que uma proposta de “subir Kubernetes para resolver o deploy lento” chegar para aprovação, a investigação prioritária é outra: por que o deploy está lento. A resposta, em padrão de mercado observado entre 2019 e 2024, está no pipeline de testes, no tempo de build ou na ausência de automação — não no orquestrador. Cluster é consequência de processo maduro, não substituto para ele.