A questão de deploy costumava ser simples: alugue um servidor, faça deploy do código, reze para ele continuar no ar. Em 2026, a escolha se dividiu em dois paradigmas dominantes — funções serverless e containers — cada um com defensores apaixonados, vantagens reais e custos ocultos que só aparecem em escala.
Escolha errado e você vai pagar demais por computação ociosa ou lutar contra cold starts durante a demo do seu produto. Escolha certo e sua infraestrutura se torna invisível — como deveria ser.
Aqui está a comparação honesta, baseada no que vimos ao fazer deploy de produtos SaaS em ambos os modelos.
O Que Serverless Realmente Significa em 2026
Serverless não significa "sem servidores." Significa que você não gerencia servidores. O provedor de nuvem cuida do provisionamento, escalabilidade, patches e disponibilidade. Você faz deploy de funções ou aplicações, e a plataforma as executa sob demanda.
As principais plataformas serverless em 2026:
- Vercel — Otimizada para Next.js e frameworks frontend, com edge functions e API routes serverless
- AWS Lambda — O serverless original, agora com até 10GB de memória e limite de execução de 15 minutos
- Cloudflare Workers — Baseado em isolates V8, cold starts de menos de um milissegundo, 300+ localizações edge
- Google Cloud Functions — Integração forte com Firebase e serviços Google Cloud
- Azure Functions — Integração sólida com .NET, durable functions para orquestração
Serverless amadureceu enormemente. As reclamações iniciais sobre cold starts, suporte limitado a runtimes e dificuldade de debug foram endereçadas. O edge runtime da Vercel inicia em menos de 5ms. O AWS Lambda agora suporta imagens de container de até 10GB. Os Cloudflare Workers rodam em todos os continentes.
O Que Containers Significam em 2026
Containers empacotam sua aplicação com suas dependências em uma unidade isolada e reproduzível. Docker é o formato padrão. A orquestração acontece via Kubernetes (k8s), Amazon ECS, Google Cloud Run ou Docker Compose para deployments mais simples.
O ecossistema de containers:
- Docker — O runtime e formato de imagem que iniciou tudo
- Kubernetes (k8s) — A plataforma de orquestração para rodar containers em escala, agora o padrão da indústria
- Amazon ECS/Fargate — Orquestração de containers nativa AWS sem gerenciar k8s
- Google Cloud Run — Containers serverless, combinando flexibilidade de containers com escalabilidade serverless
- Railway, Render, Fly.io — Plataformas de containers amigáveis ao desenvolvedor que abstraem a complexidade do k8s
Containers dão controle total sobre o ambiente de execução. Você pode rodar qualquer linguagem, qualquer framework, qualquer dependência de sistema. Se roda no Linux, roda em um container.
A Comparação Real
Custo em Diferentes Escalas
Com tráfego baixo (0–10K requisições/dia): Serverless vence de forma decisiva. Você não paga por tempo ocioso. Um plano Vercel Pro custa $20/mês. O tier gratuito do AWS Lambda cobre 1 milhão de requisições por mês. Um container equivalente rodando 24/7 no ECS custa $30–50/mês mesmo quando ninguém está usando seu app.
Com tráfego médio (10K–1M requisições/dia): O cenário muda. Custos serverless escalam linearmente com invocações. Containers custam o mesmo seja para 10K ou 100K requisições — até você precisar de mais instâncias. Nessa escala, containers podem ser 30–50% mais baratos dependendo dos seus padrões de requisição.
Com tráfego alto (1M+ requisições/dia): Containers quase sempre vencem em custo de computação bruto. O preço por invocação do serverless acumula. Uma função Lambda processando 10 milhões de requisições/mês com duração média de 200ms custa aproximadamente $40. O container equivalente custa $15–20. A economia se multiplica com o tráfego.
O custo oculto do serverless: egress, armazenamento e chamadas a serviços externos. Lambda é barato, mas o API Gateway na frente dele não é. CloudWatch Logging custa dinheiro. Acessos ao S3 acumulam. Calcule o custo da stack completa, não só o da computação.
O custo oculto dos containers: operações. Alguém precisa atualizar imagens base, rotacionar certificados, corrigir vulnerabilidades, ajustar limites de recursos e monitorar health checks. Na Meld, vimos startups gastar 15–20 horas por mês em manutenção de containers — tempo que poderia ir para desenvolvimento de produto.
Cold Starts: A Verdade Honesta
Cold starts continuam sendo a fraqueza mais discutida do serverless, mas a narrativa está desatualizada:
- Vercel Edge Functions: Cold starts de menos de 5ms. Efetivamente zero para requisições de usuários.
- Cloudflare Workers: Menos de 1ms. O modelo de isolates V8 elimina cold starts tradicionais por completo.
- AWS Lambda (Node.js): Cold start de 100–300ms para runtimes padrão. Provisioned concurrency elimina cold starts por $15–20/mês por instância concorrente.
- AWS Lambda (Java/.NET): Cold starts de 1–5 segundos sem SnapStart. Aqui o serverless ainda dói.
Para aplicações web construídas com Next.js — que é o que a maioria dos MVPs SaaS usa em 2026 — os cold starts da Vercel são imperceptíveis. O problema de cold start é real para runtimes pesados (Java, .NET) e funções com árvores de dependências grandes, mas está amplamente resolvido para workloads JavaScript/TypeScript.
Containers têm zero cold starts quando rodando, mas têm cold starts de provisionamento. Escalar de 2 para 10 instâncias leva 30–60 segundos no ECS. O scheduling de pods do Kubernetes adiciona latência similar. Durante picos de tráfego, containers podem ser tão lentos para responder quanto cold starts do serverless — a latência apenas acontece em uma camada diferente.
Experiência do Desenvolvedor
Vitórias da DX serverless:
- Deploy com
git push. Vercel, Netlify e Cloudflare suportam deploys automáticos a partir do Git. - Sem Dockerfile para manter. Sem docker-compose para debugar. Sem "funciona na minha máquina."
- Preview deployments para cada pull request. QA em ambientes similares a produção antes do merge.
- Observabilidade embutida. Vercel e Cloudflare fornecem logging, analytics e rastreamento de erros nativamente.
Vitórias da DX de containers:
- Controle total sobre o runtime. Instale dependências de sistema, rode processos em background, use WebSockets nativamente.
- Desenvolvimento local igual à produção.
docker compose upe você tem a stack completa. - Sem vendor lock-in. Um container Docker roda em qualquer nuvem, qualquer provedor, qualquer servidor bare-metal.
- Debug direto. SSH no container, inspecione o filesystem, leia os logs.
Para desenvolvimento de MVP em um cronograma de oito semanas, a DX serverless é difícil de bater. O pipeline de deploy é instantâneo, ambientes de preview são gratuitos e você nunca troca contexto para debugar infraestrutura.
Comportamento de Escalabilidade
Serverless escala para zero e escala para o infinito (dentro dos limites da plataforma). Isso é ideal para:
- MVPs com tráfego imprevisível
- SaaS B2B com uso apenas em horário comercial
- Receptores de webhooks que picos durante operações em lote
- Sites de marketing com potencial de tráfego viral
Containers escalam dentro de limites configurados. Você define contagens mínimas e máximas de instâncias, e o orquestrador escala entre elas. Isso é ideal para:
- Workloads consistentes e previsíveis
- Processos de longa duração (pipelines de dados, inferência de ML)
- Conexões WebSocket que precisam de processos persistentes
- Aplicações que exigem controle total sobre connection pooling e caching
Quando Serverless Falha
Serverless é a escolha errada quando:
- Você precisa de processos de longa duração. Lambda tem limite de 15 minutos. Se seu job em background leva 30 minutos, você precisa de containers ou uma arquitetura baseada em filas.
- Você precisa de conexões WebSocket. Funções serverless são request-response. Features em tempo real (chat, dashboards ao vivo, edição colaborativa) precisam de conexões persistentes que serverless não mantém eficientemente.
- Você precisa de computação pesada. Inferência de modelos de ML, processamento de vídeo ou operações intensivas em dados precisam de acesso a GPU ou CPU sustentada que serverless não fornece economicamente.
- Você tem árvores de dependências enormes. O limite de deploy do Lambda é 250MB (ou 10GB com imagens de container). Containers não têm limite prático de tamanho.
Quando Containers Falham
Containers são a escolha errada quando:
- Seu time é pequeno. Kubernetes exige conhecimento operacional dedicado. Se ninguém no seu time tem experiência com k8s, você vai gastar mais tempo lutando com infraestrutura do que construindo produto.
- O tráfego é instável e imprevisível. Pagar por containers ociosos durante períodos de baixo tráfego desperdiça dinheiro. Serverless escala para zero; containers escalam para o mínimo.
- Você quer deploy com zero operações. Mesmo plataformas gerenciadas de containers (ECS, Cloud Run) exigem mais atenção operacional que Vercel ou Cloudflare Workers.
- Você está construindo um site com muito conteúdo. Páginas de marketing, blogs e sites de documentação não têm motivo para rodar em containers. Geração estática mais edge functions resolvem perfeitamente.
A Abordagem Meld: Arquitetura Híbrida
Na Meld, não escolhemos um ou outro. Usamos ambos, adequados às características do workload.
Serverless para aplicações web: Nossos MVPs fazem deploy na Vercel. Next.js com React Server Components, API routes e edge middleware. A plataforma de aviação AeroCopilot — 173 tabelas no banco de dados, 18 pacotes monorepo — roda inteiramente na infraestrutura serverless da Vercel. Preview deployments para cada PR. Escalabilidade automática. Zero gerenciamento de infraestrutura. Ao escolher uma stack para MVPs, Vercel mais Next.js é nossa recomendação padrão para aplicações web.
Containers para serviços pesados em dados: Quando um cliente precisa de inferência de modelo de ML, processamento de vídeo ou computação em background sustentada, fazemos deploy de containers no Cloud Run ou ECS Fargate. O container faz o trabalho pesado; a aplicação web se comunica com ele por APIs.
Edge functions para caminhos críticos de performance: Verificações de autenticação, roteamento por geolocalização, testes A/B e feature flags rodam em Cloudflare Workers ou Vercel Edge Functions. Execução em menos de um milissegundo no edge do CDN, mais perto do usuário.
Essa abordagem híbrida funciona porque aplicações SaaS modernas não são monolíticas. Elas têm um frontend web (serverless), endpoints de API (serverless), jobs em background (containers) e lógica edge (edge functions). Tratá-las como uma única unidade de deploy força um compromisso. Tratá-las como workloads separados permite otimizar cada um.
Nossa arquitetura monorepo suporta isso naturalmente. Cada pacote no monorepo pode ter seu próprio destino de deploy — o web app vai para a Vercel, o pipeline de dados vai para um container, as bibliotecas compartilhadas são consumidas por ambos.
O Framework de Decisão
Responda estas cinco perguntas:
- Seu workload precisa de conexões persistentes? Sim → Containers. Não → Serverless.
- Seu time tem expertise em operações? Sim → Qualquer um. Não → Serverless.
- Seu tráfego é previsível? Sim → Containers (mais barato). Não → Serverless (escala para zero).
- Você precisa de GPU ou computação pesada? Sim → Containers. Não → Serverless.
- Você está construindo uma aplicação web? Sim → Serverless (Vercel/Cloudflare). Não → Avalie caso a caso.
Se você respondeu "Serverless" a 4+ perguntas, comece serverless. Você sempre pode adicionar containers depois para workloads específicos. A migração reversa — de containers para serverless — é significativamente mais difícil.
O Resumo Final
Para a maioria dos MVPs SaaS em 2026, serverless é o ponto de partida certo. O pipeline de CI/CD é mais simples, o custo com baixo tráfego é menor, a experiência do desenvolvedor é superior, e o problema de cold start está amplamente resolvido para workloads JavaScript/TypeScript.
Containers continuam essenciais para workloads específicos — processos de longa duração, computação pesada, conexões em tempo real — mas devem ser introduzidos quando necessário, não adotados por padrão. Os dias de fazer deploy de toda aplicação em um container Docker acabaram. Os dias de fazer deploy de toda aplicação como funções serverless também acabaram. A resposta certa, em 2026, é ambos — adequados ao workload, não à ideologia.