A Armadilha do Serverless: Quando Funções Lambda Custam Mais que Bare Metal

A ilusão do “paga o que usas”

O manual moderno para construir uma plataforma SaaS dita que se deve começar com uma arquitetura serverless (sem servidor). O argumento de venda é inegavelmente atrativo: zero aprovisionamento, escalabilidade horizontal infinita e a promessa de que “só pagas o que usas”. Escreves uma função em JavaScript, fazes o deploy para o AWS Lambda ou Vercel, e o fornecedor de cloud trata do resto.

À escala zero, isto é economicamente brilhante. Um projeto paralelo que recebe 1.000 pedidos por dia custa exatamente 0,00€.

Mas as equipas de engenharia falham frequentemente em calcular o ponto de interseção onde a curva de preços do serverless cruza o custo fixo de hardware dedicado. Quando uma startup de IA especializada ou uma empresa API-first atinge o product-market fit, o seu perfil de tráfego muda de picos esporádicos para uma linha de base consistente e de alto volume.

Aos 100 milhões de pedidos por mês, o serverless deixa de ser uma estratégia de infraestrutura. Torna-se um imposto sobre a margem de lucro.

A matemática da escala

Vamos analisar a matemática crua de uma API B2B de média dimensão a processar 100 milhões de pedidos por mês (cerca de 38 pedidos por segundo). Assumiremos uma carga de trabalho relativamente leve: cada pedido demora 200ms a executar e requer 512MB de RAM.

Cenário A: AWS Lambda

• Pedidos: 100M * 0,20$ por 1M = 20,00$
• Computação: 100M * 0,2s * 0,5GB = 10.000.000 GB-segundos
• Custo de computação: 10.000.000 * 0,0000166667$ = 166,67$
• API Gateway (necessário para encaminhar HTTP para a Lambda): 100M * 3,50$ por 1M = 350,00$
• Transferência de Dados Outbound (assumindo 100KB por resposta, ~10TB total): ~ 900,00$
• Custo Mensal Total: ~1.436$

Cenário B: Bare Metal (Hetzner ou OVH)

• Um servidor dedicado com um AMD Ryzen 9 7950X3D (16 cores, 32 threads), 128GB RAM ECC e 2x 1.92TB NVMe SSDs.
• Esta máquina consegue facilmente gerir mais de 3.000 pedidos por segundo para uma API Node.js/Go. Só precisamos que gira 38.
• Largura de banda outbound incluída: Ilimitada / ligação de 1Gbit.
• Custo Mensal Total: ~140$

O servidor bare metal é 10 vezes mais barato e matematicamente capaz de lidar com 100 vezes mais tráfego do que a carga atual. E não sofre de arranques a frio (cold starts).

A fricção arquitetónica

A defesa da fatura de 1.436$ da AWS é sempre a mesma: “Estamos a pagar pela falta de DevOps. Não temos de atualizar servidores Linux ou gerir load balancers.”

Este é um argumento válido para uma equipa de dois programadores. Mas as arquiteturas serverless introduzem a sua própria marca única de fricção DevOps que raramente é contabilizada na análise de custos inicial.

1. O Problema das Ligações à Base de Dados: Bases de dados relacionais (PostgreSQL/MySQL) são concebidas para manter um pequeno número de ligações persistentes. Quando um pico súbito desencadeia 1.000 invocações simultâneas de Lambda, elas tentam abrir 1.000 ligações simultâneas à base de dados. A base de dados entra em pânico e rejeita pedidos. Passas a ter de implementar e pagar por um proxy de connection pooling (como o AWS RDS Proxy ou PgBouncer).
2. Arranques a Frio (Cold Starts): Se uma função não tiver sido invocada recentemente, o fornecedor de cloud tem de alocar um contentor, carregar o runtime e iniciar o teu código. Um pedido de 200ms demora subitamente 2,5 segundos. Para aplicações web voltadas para o utilizador, esta latência é inaceitável. Acabas por pagar por “Concorrência Aprovisionada” para manter as instâncias quentes, essencialmente pagando por servidores inativos, derrotando por completo a premissa de “pagar o que se usa”.
3. Vendor Lock-in: Uma aplicação Express em Node.js a correr num VPS pode ser movida para qualquer fornecedor de cloud do mundo numa tarde. Uma aplicação serverless fortemente dependente do AWS Step Functions, DynamoDB streams e roteamento EventBridge está permanentemente amarrada ao ecossistema da AWS.

Quando o serverless está estruturalmente correto

A computação serverless é uma peça incrível de engenharia. Está é a ser sobre-prescrita. É a escolha arquitetónica correta sob três condições específicas:

• Cargas de trabalho com picos imprevisíveis: Se processas 0 pedidos durante 23 horas e depois 50.000 pedidos numa janela de 10 minutos (ex: uma plataforma de venda de bilhetes durante um grande evento), o serverless é a única arquitetura que escala rápido o suficiente sem te levar à falência com hardware inativo.
• Processamento assíncrono em background: Redimensionar imagens submetidas, transcodificar vídeo ou gerar relatórios PDF. São tarefas pesadas em computação onde a latência para o utilizador (cold starts) não importa, e podes iniciar 500 workers paralelos durante 10 segundos e depois desligá-los.
• A fase de exploração: Ao construir um MVP e procurar o product-market fit, otimizar custos de cloud é uma distração. Deves otimizar para velocidade de lançamento.

O movimento de repatriação

Estamos a assistir a uma tendência crescente de clientes de consultoria técnica a pedir a repatriação das suas cargas de trabalho de ambientes serverless de volta para aplicações monolíticas em contentores a correr em hardware previsível.

As ferramentas para gerir bare metal e ambientes VPS simples melhoraram drasticamente. Com Docker, GitHub Actions e ferramentas como Kamal (anteriormente MRSK) ou distribuições Kubernetes simples (K3s), fazer o deploy de uma aplicação balanceada e com zero downtime para um droplet da DigitalOcean de 40$/mês tem quase tão pouca fricção como empurrar código para a Vercel.

Se o tráfego da tua plataforma se assemelha a uma linha horizontal plana com picos diários previsíveis, não estás a beneficiar da elasticidade do serverless. Estás apenas a alugar o computador de outra pessoa com uma margem de lucro de 1000%.

A decisão que importa

O serverless resolve problemas reais para cargas de trabalho reais. Também cria custos invisíveis quando aplicado a cargas para as quais não foi desenhado. A diferença entre uma decisão acertada e um erro caro não está na tecnologia. Está na análise de custos que a maioria das equipas não faz antes de migrar.

Antes de comprometer a arquitetura, faz a conta. O teu padrão de tráfego e o perfil de execução das tuas funções determinam qual abordagem é financeiramente viável.

No terreno, em conjunto com a experiência acumulada na Webxtek Studio, aplicamos exatamente estes padrões operacionais em setores exigentes como especialistas em devops e arquitetura cloud e consultoria em big data e arquitetura cloud. Quando alinhas a tua estrutura através de web apps e consultoria técnica antes de construir, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.