Docker Compose ou Kubernetes: quando trocar

Docker Compose atende bem até o ponto em que você roda tudo num servidor só e aceita alguns segundos de indisponibilidade ao atualizar. Kubernetes começa a compensar quando você precisa de mais de uma máquina, atualização sem queda e recuperação automática de container que morreu. Na prática, a maioria das empresas troca cedo demais e paga uma complexidade operacional que não estava usando para nada.

Este texto mostra onde fica a linha real da troca, com o custo dos dois lados e os sinais objetivos que indicam a hora certa. A decisão costuma ser tomada por motivo errado, geralmente a sensação de que o projeto ficou importante. Importância de projeto não é critério técnico, e trocar por esse motivo adiciona trabalho sem resolver problema nenhum.

O que cada ferramenta resolve de verdade?

Docker Compose descreve um ambiente inteiro num arquivo único e sobe aquilo numa máquina só. Ele resolve dependência entre serviços, rede interna e volume de dado sem nenhuma ferramenta extra, e reinicia container que caiu. O limite dele aparece quando você precisa de mais de um servidor atendendo a mesma aplicação. Nesse ponto não existe configuração que resolva, porque a ferramenta não foi feita para coordenar máquinas.

Kubernetes gerencia um conjunto de máquinas como se fosse um recurso único e distribui containers entre elas conforme a necessidade. Ele traz descoberta de serviço, balanceamento, atualização gradual e recuperação automática dentro do próprio modelo. O preço disso é uma camada inteira de conceitos novos que alguém precisa aprender e manter atualizada. Quem adota sem precisar dessas capacidades paga o custo de aprendizado e não recebe o benefício.

Quanto custa cada caminho por mês?

O custo que decide essa escolha não é o da máquina, é o das horas de quem opera aquilo todo mês. Um cluster mal cuidado consome mais atenção do que a aplicação que ele hospeda, e essa conta não aparece na fatura do provedor. Servidor é despesa previsível e barata perto de hora de especialista em infraestrutura. Comparar só o valor da máquina é como comparar carros olhando apenas o preço do combustível.

Compose numa máquina virtual: um servidor de 4 a 8 GB resolve muita coisa, com custo entre R$ 40 e R$ 200 por mês e operação que cabe numa pessoa. A curva de aprendizado é curta e o conhecimento necessário é o de administração de servidor comum. Para a maioria dos sistemas de empresa média, essa configuração atende por anos.

Kubernetes gerenciado: o plano do provedor começa barato e a conta real aparece nos balanceadores, no armazenamento persistente e no tráfego entre zonas. O provedor cuida do plano de controle, o que elimina a parte mais chata da manutenção. Ainda assim alguém do seu lado precisa entender o modelo para diagnosticar problema de aplicação. A fronteira de responsabilidade fica no cluster, e a arquitetura do que roda dentro dele continua sendo sua.

Kubernetes próprio: barato em licença e caro em gente, porque alguém precisa cuidar de atualização de versão, certificado interno e rede o tempo todo. A economia aparente some no primeiro incidente que exige conhecimento profundo. Só faz sentido com equipe de infraestrutura dedicada e requisito que realmente justifique. Empresa sem essa equipe acaba pagando consultoria externa toda vez que algo sai do trivial.

Antes de decidir a orquestração, vale conferir se o dimensionamento da máquina está correto, porque servidor subdimensionado cria sintoma que parece falta de cluster. Cobri esse dimensionamento em VPS na prática, como escolher e configurar.

Dá para ter atualização sem queda usando só Compose?

Dá, e essa é a alternativa que quase ninguém testa antes de migrar para Kubernetes. Com um proxy reverso na frente e duas versões do container subindo em sequência, a janela de corte fica curta o bastante para ninguém notar. O proxy passa a mandar tráfego para a versão nova só depois que ela responde como saudável. A versão antiga só é derrubada quando a nova já está atendendo.

O arranjo é simples de montar e resolve o requisito mais comum que empurra empresa para cluster. Ele não cobre falha de máquina inteira, porque com um servidor só não existe para onde mover a carga. Se o seu requisito é apenas atualizar sem derrubar, o proxy resolve por uma fração do custo. Mostrei a configuração em Traefik com Docker Compose, e o mesmo padrão funciona com outros proxies.

Quais sinais indicam que chegou a hora de trocar?

Os sinais são poucos, objetivos e nenhum deles é a sensação de que o sistema ficou importante. Sem pelo menos um dos quatro abaixo, a troca é decisão de currículo e não de engenharia. Com dois ou mais, adiar a migração começa a custar mais caro que fazê-la. A honestidade nessa avaliação economiza meses de trabalho que não entregam valor nenhum ao usuário final.

Uma máquina já não aguenta: quando você precisa somar servidores para atender a carga, e não apenas trocar o atual por um maior. Enquanto crescer verticalmente resolver, crescer verticalmente é mais barato e muito mais simples. Máquinas grandes hoje comportam carga que há dez anos exigia um cluster inteiro. Crescer verticalmente até o limite do provedor costuma adiar a migração por vários anos.

Indisponibilidade custa dinheiro por minuto: nesse cenário a atualização sem queda e a recuperação automática viram requisito contratual e não preferência técnica. O custo do cluster passa a ser menor que o custo de uma janela de manutenção. A conta fica fácil de justificar quando existe cláusula de disponibilidade no contrato.

Muitos times mexendo no mesmo ambiente: isolamento por namespace e controle de acesso por perfil passam a valer o custo de aprender a ferramenta. Com um time pequeno, essa capacidade não é usada e vira complexidade pura. O ganho aparece a partir de três ou quatro equipes independentes.

Demanda que varia muito ao longo do dia: escalar automaticamente evita pagar a capacidade de pico durante o mês inteiro. Para carga estável, essa capacidade não economiza nada e ainda adiciona variável de diagnóstico. Só vale quando a variação é grande e frequente o suficiente para aparecer na fatura. Carga que apenas dobra no horário comercial raramente justifica o custo dessa capacidade.

Existe um meio termo entre os dois?

Existe, e ele resolve bem o caso de quem precisa de mais de uma máquina sem precisar do modelo completo de Kubernetes. Orquestradores mais simples coordenam containers entre poucos servidores com uma fração dos conceitos envolvidos. Distribuições leves de Kubernetes também reduzem bastante a superfície de manutenção. Para três a cinco máquinas, esses caminhos costumam entregar o necessário com muito menos peso.

A desvantagem do meio termo é ter comunidade menor e menos material de apoio quando algo dá errado. Kubernetes completo tem resposta pronta para quase todo problema, porque muita gente já passou por ele. Escolher o meio termo troca simplicidade por menos suporte coletivo. Essa troca compensa quando a equipe é pequena e o requisito é modesto.

Como começar sem escolher errado agora?

Escreva a aplicação sem depender da orquestração, mantendo configuração em variável de ambiente e estado fora do container. Aplicação que guarda arquivo no próprio container ou sessão em memória local trava a migração depois. Feito isso, trocar de orquestrador vira trabalho de infraestrutura e não reescrita de produto. Essa disciplina custa quase nada durante a construção e preserva todas as opções para o futuro.

Se você ainda não tem o ambiente descrito em arquivo, esse é o primeiro passo e ele independe da decisão de cluster. O guia está em Docker Compose do zero, e vale mesmo para quem pretende migrar depois. A documentação oficial do Kubernetes é honesta sobre a complexidade envolvida e merece leitura antes de qualquer decisão.