Serverless amadureceu — mas não é para tudo
Em 2026, serverless (AWS Lambda, Azure Functions, Google Cloud Functions) não é mais novidade — é uma ferramenta madura com casos de uso bem definidos. O hype inicial deu lugar a uma compreensão mais realista de onde serverless brilha e onde cria problemas.
O modelo de pagamento por execução e escalabilidade automática são atrativos, mas cold starts, vendor lock-in e complexidade de debugging continuam sendo desafios reais.
Quando serverless é a escolha certa
Event-driven workloads: processamento de uploads, webhooks, integrações assíncronas. APIs com tráfego variável: endpoints que têm picos e vales pronunciados. Automações e scheduled jobs: tarefas periódicas sem necessidade de infraestrutura dedicada. MVPs e protótipos: quando velocidade de entrega é mais importante que otimização.
Nesses cenários, serverless pode reduzir custos em 40-70% comparado com servidores always-on.
Quando evitar serverless
Workloads com latência crítica: cold starts de 100-500ms são inaceitáveis para real-time. Processamento contínuo: jobs que rodam 24/7 são mais baratos em containers. Aplicações stateful: serverless é inherentemente stateless — gerenciar estado adiciona complexidade. Vendor lock-in inaceitável: cada cloud tem seu runtime e limitações específicas.
O ecossistema em 2026
AWS Lambda suporta até 10GB de memória e SnapStart praticamente elimina cold starts para Java. Azure Functions ganhou Durable Functions v3 com orquestração complexa. Cloudflare Workers opera no edge com latência < 10ms. E o framework SST simplificou drasticamente o desenvolvimento serverless com infraestrutura como código.
Serverless containers: o meio termo
AWS Fargate, Google Cloud Run e Azure Container Apps oferecem a experiência serverless (sem gerenciar servidores) com a flexibilidade de containers. É o meio termo ideal para workloads que precisam de mais controle sem a complexidade de Kubernetes.
Como a Nobug decide
Usamos uma matriz de decisão que avalia: padrão de tráfego, requisitos de latência, complexidade do estado, budget e necessidade de portabilidade. Não somos dogmáticos — escolhemos a ferramenta certa para cada caso, incluindo arquiteturas híbridas que combinam serverless, containers e VMs.
