Serverless: quando usar, quando evitar e como não transformar economia em problema

Serverless é uma das abordagens mais atrativas para empresas que querem lançar produtos com rapidez, reduzir operação de servidores e pagar de forma mais proporcional ao uso. Mas a mesma arquitetura que acelera um MVP pode se tornar complexa quando adotada sem critérios.

Na Kernobras, avaliamos serverless como decisão arquitetural, não como moda. O ponto central não é apenas "não gerenciar servidores", mas entender perfil de carga, latência, observabilidade, custos, limites de execução e dependência de serviços gerenciados.

Onde serverless costuma funcionar muito bem

Serverless é excelente para workloads orientados a eventos: processamento de arquivos, webhooks, jobs assíncronos, integrações entre sistemas, APIs com tráfego variável e automações internas. Nesses cenários, a elasticidade automática reduz a necessidade de provisionamento antecipado.

Também é uma boa escolha para MVPs e produtos em validação. A equipe consegue entregar rápido, conectar serviços gerenciados e evitar complexidade operacional antes de existir escala real.

Onde serverless pode atrapalhar

Aplicações com execução longa, baixa tolerância a cold start, alto volume constante ou forte dependência de estado em memória podem sofrer em arquiteturas serverless. Nesses casos, containers, serviços dedicados ou arquiteturas híbridas podem oferecer previsibilidade maior.

Outro risco está na fragmentação. Quando cada pequena regra vira uma função isolada, o sistema pode ficar difícil de observar, versionar e depurar. Serverless mal desenhado troca complexidade de infraestrutura por complexidade distribuída.

Custo baixo no início não significa custo baixo para sempre

Um dos argumentos mais fortes para serverless é pagar conforme o uso. Isso é real, especialmente em aplicações com tráfego intermitente. Porém, integrações mal planejadas, chamadas excessivas, logs volumosos, retries descontrolados e uso intensivo de serviços gerenciados podem elevar a fatura rapidamente.

Por isso, decisões de arquitetura precisam considerar custo por transação, volume esperado, retenção de logs, tráfego entre serviços e limites de concorrência. Serverless exige FinOps desde cedo, mesmo em projetos pequenos.

Boas práticas para uma arquitetura serverless saudável

Trabalhar com filas, idempotência, rastreamento distribuído e alarmes é essencial. Funções devem ser pequenas, mas não minúsculas a ponto de quebrar o fluxo de negócio em dezenas de pontos difíceis de entender. O equilíbrio está em agrupar responsabilidades por evento e contexto.

Também é recomendável automatizar deploy com infraestrutura como código, padronizar variáveis de ambiente, separar ambientes e criar métricas de negócio além de métricas técnicas. Sem observabilidade, serverless vira uma caixa-preta elástica.

A melhor arquitetura pode ser híbrida

Na prática, muitas empresas se beneficiam de uma composição: APIs principais em containers, processamentos assíncronos em funções, filas para desacoplamento e serviços gerenciados para reduzir operação. O objetivo não é ser 100% serverless, mas usar serverless onde ele gera vantagem real.