# Kubernetes não é para todo mundo, e tudo bem

> Como decidimos se um projeto precisa de orquestração de containers ou se uma estrutura mais simples resolve melhor.

URL: https://www.mfactor.dev/blog/kubernetes-nao-e-para-todo-mundo
Autor: MFactor
Publicado em: 2026-10-31
Assuntos: Kubernetes, Cloud, Infraestrutura, MHost
Site: MFactor — https://www.mfactor.dev

A MHost, frente de infraestrutura da MFactor Tecnologia, gerencia mais de 75 mil nós em produção, boa parte em Kubernetes. Mesmo assim, uma das recomendações que mais fazemos para clientes novos é não usar Kubernetes. Pelo menos não agora.

Ele resolve muito bem um conjunto específico de problemas. Fora desse conjunto, traz custo, complexidade e um tipo de falha que uma equipe pequena não tem tempo de investigar.

## O que o Kubernetes resolve

Na prática, ele pega um grupo de máquinas e trata como um lugar só para rodar containers. Você descreve o estado que quer (quantas cópias de cada serviço, quanta memória e CPU, como eles se comunicam) e ele trabalha para manter esse estado. Se um container morre, sobe outro. Se uma máquina cai, redistribui a carga. Se o acesso aumenta, pode escalar sozinho.

Isso faz muita diferença quando há muitos serviços, tráfego que varia bastante ao longo do dia e várias equipes publicando versões com frequência.

## Sinais de que faz sentido

- Dezenas de serviços que precisam escalar de forma independente
- Picos de acesso em que pagar pela capacidade máxima o tempo todo sai caro
- Várias equipes publicando várias vezes por dia
- Necessidade de rodar a mesma estrutura em mais de um provedor ou em ambiente próprio
- Alguém na equipe, ou um parceiro, com tempo dedicado para operar o cluster

O último item é o que mais se ignora. Um cluster precisa de atualização de versão algumas vezes por ano, monitoramento, política de rede, gestão de certificados e de segredos. Não é instalar e esquecer.

## Sinais de que é exagero

Um sistema web com um backend, um banco de dados e algum processamento em segundo plano raramente precisa disso. Uma aplicação com tráfego estável e equipe de duas ou três pessoas, também não.

Nesses casos, serviços gerenciados de containers (Cloud Run, ECS com Fargate, Azure Container Apps), uma ou duas máquinas virtuais bem configuradas ou uma plataforma como serviço resolvem com uma fração do esforço. O deploy é mais simples, a conta é mais fácil de entender e, quando algo dá errado, há menos camadas para olhar.

## O custo que não aparece na fatura

O cluster em si custa pouco nos provedores gerenciados. O que pesa é o tempo das pessoas. Entender por que um pod reinicia em loop, por que um serviço não encontra o outro ou por que a requisição some no meio do caminho exige um conhecimento que demora para construir.

Já vimos empresas migrarem para Kubernetes porque "é o padrão" e passarem os meses seguintes resolvendo infraestrutura em vez de entregar funcionalidade. O sistema não ficou mais estável. Ficou mais difícil de entender.

## O que vale para qualquer projeto

Seja qual for a estrutura escolhida, algumas decisões entram em todo projeto da MHost desde o começo:

- Aplicação empacotada em container, mesmo rodando numa máquina simples. Isso barateia muito uma migração futura.
- Infraestrutura descrita em código (Terraform ou equivalente), para que o ambiente possa ser recriado do zero.
- Banco de dados gerenciado ou com backup testado. Backup que nunca foi restaurado não conta.
- Métricas, logs e alertas desde o primeiro dia.
- Configurações e segredos fora do código.

Com essa base, ir para Kubernetes quando o projeto crescer vira uma mudança de onde a aplicação roda, e não uma reescrita. Enquanto o problema de escala não aparece, a estrutura mais simples que atende costuma ser a escolha mais madura.