Kubernetes vs Serverless em 2026: o framework de decisão que usamos no lab
Quando vale a complexidade do K8s, quando Lambda/Cloud Run resolve. Análise por dimensão de custo, escala e equipe.
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
Lambda Cloud Run K8s (EKS)
1 req/s $0.20/mês $0.50/mês $73/mês (cluster)
100 req/s $20/mês $35/mês $73/mês
10k req/s $2000/mês $1200/mês $400/mês (3 nodes)
100k req/s $20k/mês $8k/mês $1200/mês
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
Setup mínimo para K8s saudável:
- 1 SRE/Platform engineer dedicado
- CI/CD configurado (ArgoCD ou Flux)
- Observability stack (Prometheus + Grafana + Loki)
- Política de RBAC + secrets management
- Backup/disaster recovery do etcd
Setup mínimo para Lambda saudável:
- AWS SAM ou Serverless Framework
- CloudWatch alarms básicos
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.