Introdução

O modelo serverless tem sido frequentemente promovido como uma solução mágica para reduzir custos e simplificar operações.

A narrativa dominante é: “não se preocupe mais com servidores, pague apenas pelo que usar e escale automaticamente”.

De fato, o paradigma trouxe avanços enormes para workloads event-driven e para empresas que buscam agilidade inicial.

No entanto, como em toda decisão arquitetural, os trade-offs precisam ser cuidadosamente analisados.

Ao longo deste artigo, vou explorar não apenas os custos diretos, mas também os custos ocultos que impactam confiabilidade, manutenção e evolução de sistemas.

Escalabilidade automática nem sempre é previsível

Um dos maiores atrativos do serverless é a escalabilidade automática. O provedor ajusta recursos de acordo com a carga, sem intervenção humana.

Porém, essa escalabilidade pode trazer riscos:

Explosão de custos em cenários de picos inesperados de tráfego.
Sobrecarga em sistemas downstream (bancos, APIs internas) que não foram projetados para absorver a elasticidade do serverless.
Falsas expectativas: escalabilidade não é sinônimo de resiliência.
Bugs que aumentam a fatura: loops infinitos, funções mal configuradas ou disparos repetidos podem gerar consumo inesperado e cobranças elevadas.
Ataques e abusos maliciosos: bots, ataques DDoS ou requisições automatizadas podem inflar o consumo de funções serverless, causando custos elevados e potencial indisponibilidade de serviços.

flowchart TD A[Evento Disparado] --> B[Função Serverless] B --> C[Escala Automática] C --> D[(Custos Crescentes)] C --> E[Timeouts e Cold Starts]

Esse tipo de efeito é citado em livros como Release It! (Michael Nygard), que destaca como gargalos muitas vezes aparecem em dependências ocultas.

Escalar apenas a borda pode significar colapsar o núcleo do sistema.

Custo de execução vs. custo de operação

O marketing do serverless foca no custo por execução, mas esse é apenas um pedaço pequeno do TCO (Total Cost of Ownership).

Arquitetos precisam enxergar o quadro completo:

Execução: cobrança por número de requisições e tempo de execução.
Operação: monitoramento, observabilidade, logs, tracing distribuído.
Rede: custos de saída (egress) podem ser mais altos que a própria execução.
Integrações: chamadas entre serviços também geram custos cumulativos.
Ocultos: o debugging pode ser difícil, refatorações forçadas por limites de execução, dependência de APIs proprietárias.

graph LR A[Custos Visíveis] --> B[Execução] A --> C[Armazenamento e Rede] A --> D[Integrações] A --> E[Monitoramento] A -.-> F[Custos Ocultos] F --> G[Vendor Lock-in] F --> H[Complexidade Operacional]

Esse efeito é observado em diversos cases de migração: equipes inicialmente comemoram redução de custos, mas em alguns meses o gasto total supera a alternativa containerizada.

Cold starts e impacto na experiência do usuário

O cold start ocorre quando o provedor precisa inicializar uma nova instância da função, pois não havia nenhuma “quente” disponível.

O tempo de atraso pode variar de 200ms a vários segundos, dependendo da linguagem, bibliotecas utilizadas e configuração de rede.

sequenceDiagram participant U as Usuário participant GW as API Gateway participant F as Função Serverless U->>GW: Request GW->>F: Invocação Note right of F: Cold Start (200ms - 2s) F-->>GW: Resposta GW-->>U: Retorno ao usuário

Impactos reais:

Em aplicações de e-commerce, um atraso de 100ms no carregamento pode reduzir conversões em até 7% (segundo estudo da Akamai, State of Online Retail Performance, 2017).
Em sistemas financeiros, um cold start pode representar tempo de latência crítico para aprovações de pagamento.
Equipes acabam criando workarounds como “funções despertadoras” que invocam lambdas periodicamente - introduzindo custos extras e complexidade artificial.

Vendor lock-in: dependência invisível

Um dos maiores riscos do serverless é a dependência de serviços proprietários.

Exemplo: uma função AWS Lambda que consome eventos diretamente de S3 Events ou DynamoDB Streams não pode ser migrada facilmente para outra plataforma.

Essa dependência pode gerar:

Reimplementação completa em caso de mudança de provedor.
Incompatibilidade com padrões abertos.
Negociação desfavorável de custos, já que sair da plataforma se torna caro demais.

Arquitetos precisam aplicar conceitos do livro Building Evolutionary Architectures (Neal Ford) e projetar portabilidade intencional desde o início.

Complexidade operacional oculta

Muitas equipes acreditam que serverless elimina a necessidade de operações.

Na prática, a equipe ainda precisa de:

Observabilidade avançada: tracing distribuído (ex.: OpenTelemetry).
Estratégias de versionamento: múltiplas versões de funções ativas ao mesmo tempo.
Governança de segurança: controle de permissões granulares (IAM, RBAC).
Planejamento de custos: dashboards em tempo real para evitar “choques de fatura”.

Sem isso, a operação se torna reativa e caótica, com times apagando incêndios em produção.

Boas práticas para reduzir custos ocultos

Observabilidade desde o início: invista em métricas, tracing e alertas.
Design para portabilidade: mantenha a lógica de negócio isolada de integrações proprietárias.
Uso híbrido: adote containers ou workers para workloads críticos e previsíveis.
Avaliação periódica de TCO: calcule custo de execução + operação + manutenção + lock-in.
Simulações de carga: valide custos em cenários de pico antes de ir a produção.
Redução de cold start: minimize dependências pesadas, inicializações complexas e use compilação nativa quando possível.
Verifique os limites do seu provedor: entenda quotas, limites de memória, CPU e requisições para evitar surpresas de custo ou throttling.
Alocação de recursos dedicada: considere provisionar memória ou CPU fixa em workloads serverless críticas para melhorar performance e previsibilidade de custos.

Conclusão

O serverless é uma ferramenta poderosa e transformadora. Ele reduz barreiras de entrada e acelera o desenvolvimento de soluções event-driven.

Porém, não é um atalho para custos baixos nem simplicidade operacional.

Arquitetos e engenheiros precisam considerar:

O perfil do workload.
A maturidade da equipe.
O risco de lock-in.
O impacto de custos invisíveis no médio e longo prazo.

Em muitos casos, a combinação de serverless + containers + filas é o caminho mais equilibrado, aproveitando o melhor de cada paradigma e minimizando riscos.

A decisão deve sempre ser contextual, informada e baseada em trade-offs claros.