Descubra quando usar serverless vs containers na cloud. Comparação técnica completa com casos de uso, benchmarks e recomendações práticas para arquitetos.

Use serverless quando:** sua workload é event-driven, tem tráfego esporádico ou imprevisível, e você querzero infrastructure management. Ideal para APIs simples, automações, processamento de eventos e protótipos rápidos.

Use containers quando: precisa de controle total do runtime, portabilidade entre ambientes, deploys frequentes com CI/CD maduro, ou workloads stateful que exigem estado persistente e conexões de longa duração.

O Problema Real: Uma Startup Que Gastou 400% a Mais do Que Precisava

Em 2023, uma empresa brasileira de fintech migrou sua API de pagamentos de containers para AWS Lambda e reduziu custos de R$ 85.000 para R$ 18.000 mensais. Seis meses depois, voltou aos containers porque as funções Lambda estavam dando timeouts em integrações com bancos tradicionais que exigem conexões persistentes de 30+ segundos.

Essa história ilustra uma verdade incômoda: não existe resposta universal para serverless vs containers. A escolha correta depende de padrões de tráfego, requisitos de latência, equipe成熟度, e — fundamentalmente — do problema de negócio que você está resolvendo.

Entendendo Serverless: O Modelo Que Mudou as Regras

O Que Realmente Significa "Serverless"

Serverless não significa "sem servidor" — significa que você não gerencia o servidor. O provedor cloud aloca recursos dinamicamente, escala automaticamente, e cobra apenas pelo tempo de execução.

Principais serviços serverless por plataforma:

  • AWS: Lambda (até 15 minutos por execução, 10GB RAM máx., 1000 concurrent executions no tier gratuito)
  • Azure: Functions (Consumption Plan cobra por execution time em milissegundos)
  • Google Cloud: Cloud Functions v2 (baseado em Cloud Run, até 60 minutos)
  • Oracle Cloud: Functions (baseado em Fn Project, integração nativa com OCI)

O Modelo de Preços Que Você Precisa Entender

A AWS cobra Lambda assim:

  • 1 milhão de requisições gratuitas por mês (永远 no tier gratuito)
  • 400.000 GB-segundos de computação gratuitas por mês
  • Após isso: $0.20 por 1 milhão de requisições + $0.0000166667 por GB-segundo

Para uma função que roda 100ms com 512MB: custo por execução = $0.000000083. Traduzindo: 12 milhões de invocações custam aproximadamente $1.

Containers: O Modelo Tradicional Reinventado

Por Que Containers Ainda Dominam Produções Críticas

Containers continuam sendo a escolha preferida para aplicações de produção em escala porque oferecem:

  • Controle completo do ambiente (SO, runtime, dependências)
  • Portabilidade entre cloud providers ou on-premises
  • Persistência de estado sem cold starts
  • Customização granular de recursos (CPU, memória, networking)

Serviços gerenciados por plataforma:

Provedor Serviço O Que Você Gerencia
AWS ECS / EKS Aplicação e dados
Azure AKS / Container Instances Aplicação e dados
GCP GKE (AutoPilot) Aplicação e dados
Oracle Cloud OKE (Kubernetes Engine) Aplicação e dados

O Custo Real dos Containers em Produções

Um cluster Kubernetes básico na AWS (EKS) custa:

  • $0.10 por hora por cluster (~$73/mês mínimo)
  • Plus custos de EC2: uma instância t3.medium = $30/mês
  • Plus load balancers, storage, networking

Total mínimo realístico: $150-300/mês para um cluster de produção funcional.

Quando Usar Serverless: Casos de Uso Comprovados

1. Processamento de Eventos Assíncronos

Serverless brilha em workloads que reagem a eventos:

  • Trigger S3: Processar uploads de imagens (resize, compressão via Sharp no Lambda)
  • SQS/EventBridge: Processar filas de mensagens com escalabilidade automática
  • API Gateway: Endpoints que recebem webhooks, processam e retornam 202 Accepted

Exemplo real: O backlog de processing de imagens do Nubank roda 100% em Lambda. Quando um usuário faz upload de um documento, Lambda dispara resize + OCR + almacenamiento — tudo em menos de 3 segundos, custando $0.000012 por imagem processada.

2. APIs com Tráfego Esporádico ou Imprevisível

Se sua API tem padrões assim:

  • Tráfego 0 às 3h, pico de 10.000 req/s às 9h
  • Sazonalidade (Black Friday, lançamento de produto)
    -Períodos de inatividade prolongados

Lambda escala de 0 a milhares de instâncias em segundos. Com containers, você pagaria por instances rodando 24/7 mesmo ocioso.

3. Automação e Tasks Agendadas

Não faz sentido manter um EC2 ou cluster ativo só para rodar um cron job de 30 segundos.

  • AWS EventBridge + Lambda: Agendar backups, gerar relatórios, sincronizar dados
  • Azure Timer Trigger: Functions que executam em cronograma (cron format nativo)
  • Custo: Lambda cobra por 100ms de execução — um job de 5 segundos custa fractions de centavo

4. Prototipagem e MVP Rápido

Para validar hipóteses rapidamente:

  • Deploy em minutos vs horas de setup de CI/CD com Docker
  • Sem custos iniciais (tier gratuito generoso)
  • Iteração rápida: atualizar código é quase instantâneo

Quando Usar Containers: Situações Que Exigem Controle

1. Aplicações Stateful ou Com Conexões Persistentes

Se você precisa de:

  • WebSockets de longa duração (chat, streaming, colaboração real-time)
  • Conexões de banco que não podem ser recriadas frequentemente (pooling complexo)
  • Servidores gRPC que mantêm conexões abertas

Containers wins. Lambda tem limites de 15 minutos por execução e não suporta conexões TCP persistentes entre invocações.

2. Requisitos de Latência Ultra-Baixa

Cold starts em Lambda:

  • Runtime Node.js: ~100-300ms
  • Runtime Java: ~2-10 segundos (!)
  • Com provisioned concurrency: zero cold start, mas custo adicional

Para aplicações que precisam de <50ms consistente (trading, gaming, real-time), containers com warm instances ou mesmo bare metal são obrigatórios.

3. Portabilidade Entre Clouds (Multi-Cloud Strategy)

Se sua arquitetura deve rodar em AWS EKS E Azure AKS (por razões de compliance ou vendor lock-in avoidance):

  • Docker images são portáveis nativamente
  • Kubernetes manifests funcionam em qualquer provedor
  • Sem reescrever código ou refatorar

Serverless é intrinsecamente coupled ao provedor. Lambda só roda na AWS.

4. Equipes com DevOps Maduro e CI/CD Sofisticado

Containers fazem sentido quando:

  • Você tem pipeline de deployment com rollback automatizado
  • Testes de integração rodam em containers idênticos à produção
  • Você precisa de canary deployments, blue-green deployments customizados
  • Performance tuning do runtime é crítica (JVM tuning, node_modules otimizados)

Matriz de Decisão: Serverless vs Containers

Critério Serverless Containers
Tempo de startup 100ms-10s (cold start) Segundos (pode manter warm)
Escalabilidade Automática e instantânea Manual ou horizontal autoscaling
Custo para workloads leves Extremamente baixo Mínimo fixo por cluster
Custo para workloads pesadas Pode escalar descontroladamente Previsível (pague pela instância)
Vendor lock-in Alto (cada provider é diferente) Baixo (standards abertos)
Estado persistente Não suporta bem Suporta nativamente
Debugging local Difícil (emulação imperfeita) Excelente (Docker idêntico)
Customização de runtime Limitada Total

A Estratégia Híbrida: O Que a Indústria Está Fazendo

Empresas maduras não escolhem um ou outro — elas usam ambos estrategicamente.

Arquitetura Híbrida Comum

┌─────────────────────────────────────────────────────┐
│                    API Gateway                       │
└─────────────────┬───────────────────────────────────┘
                  │
        ┌─────────┴─────────┐
        ▼                   ▼
   ┌──────────┐      ┌────────────┐
   │  Lambda  │      │  EKS/AKS   │
   │(轻量级API) │      │(核心业务逻辑)│
   └──────────┘      └─────┬──────┘
                           │
                    ┌──────┴──────┐
                    ▼             ▼
              ┌──────────┐  ┌──────────┐
              │RDS/Dynamo│  │  Redis   │
              │  (持久)   │  │ (Cache)  │
              └──────────┘  └──────────┘

Exemplo prático:

  1. Lambda: Webhook receivers, thumbnail generation, notificações push, scheduled jobs
  2. EKS/AKS: Microserviços críticos com estado, APIs que exigem low latency, workers de processamento pesado

Ferramentas de Orquestração que Unificam Ambos

  • AWS SAM ou Serverless Framework: Deploy Lambda + infraestrutura como código
  • KEDA (Kubernetes Event-driven Autoscaling): Escala containers baseados em eventos (inclusive triggers de Lambda)
  • AWS Fargate: Containers serverless — você não gerencia instâncias, paga por task

Fargate pricing example:

  • 4 vCPU, 8GB RAM: ~$40/dia ($1.200/mês)
  • Ideal para workloads que precisam de containers mas não querem gerenciar EC2

Perguntas Frequentes dos Arquitetos

"Serverless é mais caro em escala?"

Depende do padrão de uso.

Para 10.000 requisições/dia com 500ms cada: Lambda = ~$0.15/mês. Container (t3.medium sempre-on): ~$30/mês.

Mas para 10 milhões de requisições/dia com 2s cada: Lambda = ~$1.500/mês. Container cluster (20 instâncias): ~$2.000/mês (mais previsível).

Regra prática: Lambda vence em <1M invocações/mês; containers vencem em workloads sustentadas de alta intensidade.

"E se meu Lambda precisa de uma library que não existe para Node/Python?"

Você tem opções:

  1. Lambda Layers: Include binários customizados (FFmpeg, Python packages com C extensions)
  2. Custom runtime: Rodar qualquer linguagem (Rust, Go, C++ compilado)
  3. Container image (Lambda): Até 10GB, qualquer runtime, mas perde cold start benefits

Se você precisa de dependencies complexas que precisam compilar, containers são mais simples.

"Como fazermigration de containers para serverless?"

Step-by-step:

  1. Identifique stateless handlers: Funções que recebem request, processam, retornam — sem estado entre invocações
  2. Extrac lógica de negocio: Preserve domínio como pure functions
  3. Crie handlers thin: Lambda é só orchestrator — lógica vai para libraries compartilhadas
  4. Teste com load real: Simule pico com Locust ou k6 antes de production
  5. Migre gradualmente: API Gateway → Lambda para novos endpoints primeiro

Armadilha comum: Tentar migrar tudo de uma vez. Faça incrementally, monitore custos e latência.

Conclusão: A Decisão Depende de Quem Está Perguntando

Escolha serverless se:

  • Você é uma startup ou equipe small que precisa mover rápido
  • Sua workload é event-driven ou tem padrões imprevisíveis
  • Você quer minimizar operações e infrastructure overhead
  • Tráfego varia significativamente (90% do tempo ocioso)

Escolha containers se:

  • Você tem equipe DevOps estabelecida
  • Precisa de controle granular de performance
  • Workloads são stateful ou exigem conexões persistentes
  • Portabilidade multi-cloud é exigência de compliance
  • Você está operando em escala massiva e precisa de previsibilidade de custos

A verdade? A maioria das arquiteturas modernas usa ambos. O trabalho do arquiteto cloud não é escolher um winner — é identificar quais componentes de sua arquitetura se beneficiam de cada modelo e desenhá-los para coexistirem harmoniosamente.

Na prática, comece serverless para MVP e funcionalidades auxiliary. Migre para containers quando identificar bottlenecks de performance ou custos. Essa abordagem permite iterar rapidamente sem over-engineering, e scale com confiança quando o producto validar product-market fit.

Weekly cloud insights — free

Practical guides on cloud costs, security and strategy. No spam, ever.

Comments

Leave a comment