Docker virou sinônimo de “projeto profissional”, está em toda vaga, todo curso, todo repositório no GitHub, E isso criou um efeito colateral perigoso: a ideia de que todo projeto precisa estar dentro de um container. Não precisa.
Saber quando não usar Docker é um divisor de águas entre quem entende a ferramenta e quem só segue tendência.
Docker resolve problemas reais: padronização de ambiente, deploy previsível, escalabilidade, isolamento de serviços. O problema começa quando esses desafios não existem e, mesmo assim, o Docker entra em cena.
Nesse momento, ele deixa de ser solução e passa a ser ruído.
Em projetos muito pequenos, por exemplo, o uso de Docker costuma atrapalhar mais do que ajudar. Um script simples, um CRUD local, um job que roda pontualmente… nada disso exige camadas extras de abstração. Criar imagens, mapear volumes, configurar redes e variáveis de ambiente consome um tempo que poderia estar sendo investido no que realmente importa: o código.
Quando a infraestrutura se torna mais complexa do que o próprio sistema, algo está errado.
Outro ponto pouco falado é a realidade da infraestrutura. Nem todo ambiente aceita Docker de braços abertos. Empresas com servidores legados, políticas rígidas de segurança ou restrições de acesso simplesmente não permitem esse tipo de solução. Forçar Docker nesses cenários geralmente resulta em gambiarras, conflitos com times de infra e ambientes difíceis de manter.
Às vezes, uma VM bem configurada é mais estável, mais previsível e muito mais alinhada com o contexto do projeto.
Também há casos em que Docker simplesmente não nasceu para resolver o problema. Aplicações que dependem diretamente de hardware, drivers específicos ou dispositivos proprietários costumam sofrer dentro de containers. Mesmo quando funciona, o custo de adaptação é alto e a manutenção vira um pesadelo. Nesses cenários, rodar direto no sistema operacional ainda é a escolha mais sensata.
Existe ainda um erro clássico: usar Docker para esconder falta de base.
Quando conceitos como rede, portas, permissões e processos Linux não estão claros, o container vira uma caixa-preta. O sistema “funciona”, mas ninguém sabe explicar por quê. Isso não é robustez — é risco.
Docker potencializa conhecimento. Ele não compensa ausência dele.
Em aplicações onde cada milissegundo importa, como sistemas de altíssima performance ou workloads intensivos de I/O, qualquer camada extra pode pesar. Docker é leve, mas não é mágico. Há situações onde bare metal ainda entrega resultados superiores, e ignorar isso é fechar os olhos para a realidade técnica.
Outro cenário comum é tentar encaixar Docker em aplicações desktop ou com interface gráfica tradicional. Dá para fazer? Dá. Mas o esforço raramente compensa. Containers brilham no mundo de servidores e serviços. Fora disso, costumam ser a ferramenta errada.
Dominar o Docker
Se o time não domina Docker, não entende seus conceitos ou não está disposto a aprender, ele deixa de acelerar e passa a travar entregas. Ferramenta boa só funciona quando quem usa sabe o que está fazendo.
Simplicidade bem compreendida sempre vence complexidade mal aplicada.
Docker não é status. É decisão.
Docker não é um selo de profissionalismo, nem algo que você aplica para deixar o projeto mais “bonito” no GitHub. Ele é uma decisão técnica que só faz sentido quando existe um problema real a ser resolvido. Quando Docker entra na hora certa, ele deixa de ser peso e passa a ser vantagem estratégica — e aqui eu comento um pouco sobre o quando devo usar o Docker.