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.