Tools: Precisa mesmo containerizar tudo?

O hype da containerização ## Onde eu vi container mais atrapalhar do que ajudar ## Vale a pena containerizar por padrão? Nos últimos anos apareceu uma “regra não escrita” na nossa área: se não está em container, está errado. Mas será que tudo precisa nascer dentro de um Dockerfile, com Kubernetes, Helm, Istio e a sopa de letrinhas inteira, ou a gente só está surfando hype sem pensar muito? ​ Minha ideia aqui é dar uma opinião bem pé no chão, contar um pouco da experiência em empresas onde trabalhei e explicar como fazemos hoje na Codetech Software, onde a decisão de usar container ou não é bem mais pragmática do que “porque o mercado faz assim”. Container tem muita coisa boa. Você empacota a aplicação de um jeito mais padronizado, diminui aquele clássico “na minha máquina funciona” e consegue aproximar bastante dev, staging e produção. Fica mais fácil automatizar build, testes e deploy dentro de um pipeline de CI/CD, e fazer rollback vira uma troca de imagem somente. Isso faz muito sentido em cenários onde você realmente precisa escalar, rodar muitos serviços diferentes, ter ambientes dinâmicos ou multi-cloud, e o time tem maturidade pra cuidar de observabilidade, segurança, recursos e tudo que vem junto com esse pacote mais sofisticado. O problema não é o container em si, é quando ele vira religião: “se não está em container, está errado”, mesmo quando o contexto não pede nada disso. Em várias empresas por onde passei, só uma parte delas usava containers de verdade em produção. Curiosamente, as que estavam mais “moderninhas”, cheias de containers e orquestração, eram justamente as que mais apanhavam em ambiente produtivo. Não porque container é ruim, mas porque a complexidade que vem junto não estava sendo tratada como algo sério, que exige tempo, especialização e cuidado. ​ Vi muito sistema simples rodando em infra absurdamente complexa para o que precisava. Kubernetes gigante pra aplicação relativamente pequena, time enxuto sem ninguém realmente especialista em infra (colocaram a galera fullstack pra ser especialista em infra), e uma coleção de problemas que, no fundo, eram bug de código, falta de teste, fluxo mal desenhado ou requisito mal entendido (falta de documento de história, contato com cliente, etc). A infra só deixava tudo mais difícil de depurar. Em contrapartida, também trabalhei em empresas mais “old school”, rodando em VM ou servidor gerenciado, com uma stack mais estável. Os problemas que apareciam eram de regra de negócio, de QA, de processo – não aquela chuva de incompatibilidade esquisita entre ambiente de desenvolvimento e produção. ​ Como a gente faz na Codetech Software Na Codetech Software, a minoria dos projetos roda em container, e isso é totalmente intencional, não falta de conhecimento ou de ferramenta. Para a maior parte dos sistemas que desenvolvemos, um setup mais direto resolve melhor: app rodando em ambiente bem controlado, com runtime e versões padronizadas, sem a sobrecarga de operar um ecossistema de containers completo. ​ A gente trabalha mantendo padrões rígidos de versão de Node, JavaScript, SQL e demais componentes, tanto em desenvolvimento quanto em produção. Isso reduz muito o risco de incompatibilidade de servidor, justamente porque não tem aquela bagunça de cada ambiente com uma configuração aleatória. Quando aparecem erros em produção, normalmente estão relacionados a outra coisa: falta de testes mais profundos, QA que não cobriu um cenário crítico, detalhe de negócio que passou batido. Não é container que vai resolver esse tipo de problema, é disciplina de teste, revisão, validação com o usuário, etc. ​ Claro que a gente também usa container quando faz sentido. Em projetos que precisam de ambientes mais dinâmicos, vários serviços independentes, escalabilidade mais agressiva ou cenários em que o próprio cliente tem uma infra baseada em containers, a gente abraça essa abordagem e faz direito. A questão é: a escolha vem do contexto do negócio e da realidade do time, não de um checklist “moderno” que diz que todo sistema sério tem que estar dentro de uma imagem Docker. Hoje, a pergunta que eu gosto de fazer não é “como coloco isso em container?”, e sim “o que esse sistema realmente precisa para funcionar bem e com segurança?”. Em muitos casos, container é a resposta certa. Em outros tantos, é só um complicador a mais, que vai consumir tempo de um time que deveria estar focado em entregar valor de negócio, corrigir bugs e melhorar a experiência do usuário. ​ Vejo muita gente tentando resolver problema de qualidade de software com camada de infra. Só que bug de regra de negócio, feature mal pensada, fluxo confuso e falta de teste não somem porque você colocou tudo em container e subiu no Kubernetes. No máximo, você ganha um cenário mais padronizado, o que é ótimo, mas ainda assim vai precisar encarar as causas reais dos problemas. Na Codetech Software, a gente tenta justamente seguir esse caminho mais honesto: escolher a arquitetura que faz sentido pro contexto e pro cliente, mesmo que isso signifique não usar a buzzword da moda naquele projeto específico. Se você está nessa fase de decidir se vai containerizar tudo por padrão num projeto novo ou num sistema que já está sofrendo em produção, eu curto bastante trocar ideia sobre isso. É um tipo de decisão que parece só “técnica”, mas mexe direto com custo, prazo, operação e até com o humor do time no dia a dia. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse