A pergunta volta a cada novo serviço que vamos provisionar: K8s ou serverless? Depois de 3 anos rodando os dois em paralelo no laboratório, sistematizamos a decisão num framework de 5 dimensões.
A regra rápida (pra quem só quer o palpite)
Se você tem menos de 4 microserviços ou não tem time dedicado de plataforma, comece em serverless. Migre para K8s só quando a conta da serverless ficar maior que o custo de manter um cluster.
Esse é o ponto onde a maioria dos times decide errado — começa em K8s “porque é o futuro”, passa 6 meses configurando ingress, secrets, monitoring, helm, e nunca chega a entregar o produto.
As 5 dimensões
1. Custo em escala
1 | Lambda Cloud Run K8s (EKS) |
O ponto de inflexão fica entre 1k e 5k req/s dependendo do payload. Abaixo disso, serverless ganha. Acima, K8s ganha.
2. Cold start tolerância
| Workload | Tolera cold start? |
|---|---|
| Webhook receiver | ✅ sim, raro |
| API pública pra usuário | ⚠️ depende (300ms tolerável, 3s não) |
| Processamento batch | ✅ totalmente |
| Inferência de IA em tempo real | ❌ K8s/SageMaker |
| Conexão WebSocket persistente | ❌ K8s |
3. Estado e conexões persistentes
Serverless não mantém estado entre invocações. Se você precisa:
- Conexão pool de DB persistente
- Cache em memória
- WebSocket de longa duração
- Subscriptions de eventos com state
K8s é o caminho. Lambda + ElastiCache + DynamoDB resolve, mas com mais glue code.
4. Equipe disponível
1 | Setup mínimo para K8s saudável: |
Tempo de setup inicial: 2-4 semanas K8s vs 1 dia Lambda.
5. Lock-in com provedor
Serverless = lock-in alto. AWS Lambda + API Gateway + DynamoDB é difícil migrar pra GCP.
K8s = portável (em teoria). Na prática, manifests rodam em qualquer cluster, mas operadores específicos (AWS Load Balancer Controller, EFS CSI driver, etc.) prendem ao cloud.
Casos reais do laboratório
Pipeline de embedding (jobs assíncronos, batch grande)
Escolha: Lambda + SQS. Cold start de 800ms é irrelevante quando o job inteiro leva 2 minutos. Custo cai pra ~$3/mês fora dos picos.
API de inferência em tempo real (latência crítica, p99 < 100ms)
Escolha: EKS + nodes com GPU. Modelos carregados em memória, sem cold start.
Webhooks de integrações (10-50 req/s, latência não-crítica)
Escolha: Cloud Run. Auto-scaling até zero quando ninguém está chamando, paga só pelo que usa.
Dashboard interno (10 users simultâneos, baixíssima escala)
Escolha: Cloud Run (free tier cobre tudo). K8s seria caro pra esse volume.
Conclusão
Não existe escolha “futura-prova”. Existe escolha certa para o estágio atual do produto e tamanho do time. Comece simples, migre quando a conta ou a complexidade da serverless exceder o custo de operar um cluster.