Serverless: quando funções fazem sentido e quando viram armadilha
Serverless é um dos termos mais mal compreendidos da engenharia moderna, a começar pelo nome: os servidores continuam existindo, você é que deixa de gerenciá-los. A promessa é sedutora: escreva a função, faça o deploy e o provedor cuida de servidores, escala e disponibilidade, cobrando só quando o código roda. Para certos problemas, isso é próximo da mágica. Para outros, é uma armadilha que só mostra a conta quando já é tarde.
Este guia trata serverless com realismo. O que ele realmente é, onde brilha de verdade, e os limites técnicos e de custo que decidem se ele será a melhor escolha ou um erro caro de arquitetura.
O que serverless significa de fato
Em serverless, você não provisiona nem administra servidores. Não há máquina para dimensionar, atualizar ou manter no ar. A forma mais comum é o FaaS (Function as a Service): você escreve funções pequenas, cada uma disparada por um evento, e o provedor as executa sob demanda.
Dois traços definem o modelo:
- Escala automática até zero. Sem requisições, nada roda e nada é cobrado. Com um pico, o provedor sobe milhares de execuções paralelas sozinho.
- Cobrança por execução. Você paga pelo número de invocações e pelo tempo de processamento real (em frações de segundo), não por um servidor ligado 24 horas esperando tráfego.
O gatilho é sempre um evento: uma requisição HTTP, um arquivo enviado a um bucket, uma mensagem em uma fila, um horário agendado. A função acorda, processa aquele evento e dorme de novo.
Onde serverless brilha
Serverless entrega o máximo de valor em cargas event-driven, esporádicas ou muito variáveis, exatamente onde manter um servidor ligado o tempo todo é desperdício. Casos em que costuma ser a melhor escolha:
- Processamento por evento: redimensionar uma imagem assim que ela é enviada, processar um webhook, reagir a um novo registro.
- Tarefas agendadas (cron): relatórios noturnos, limpezas periódicas, sincronizações, sem um servidor dedicado só para isso.
- Tráfego irregular ou imprevisível: APIs com picos raros e vales longos, onde pagar por servidor ocioso não faz sentido.
- Backends de baixo volume: protótipos, MVPs e ferramentas internas que rodam pouco e não justificam infraestrutura fixa.
- Colas de integração: pequenas funções que conectam serviços, transformam dados e movem eventos entre sistemas.
Nesses cenários, o custo acompanha o uso de verdade: quase zero quando ninguém usa, elástico quando o pico chega.
Os limites que viram armadilha
O mesmo modelo que encanta esconde restrições técnicas que, ignoradas, transformam serverless em dor de cabeça.
Cold start
Quando uma função não é chamada há um tempo, o provedor "desliga" seu ambiente. A próxima invocação precisa inicializar tudo do zero, o cold start, adicionando latência (de dezenas de milissegundos a alguns segundos, conforme a linguagem e o tamanho do pacote). Para uma tarefa em segundo plano, ninguém nota. Para uma API sensível à latência na frente do usuário, esse atraso intermitente é um problema real.
Limite de tempo de execução
Funções serverless têm teto de duração (tipicamente alguns minutos por invocação). Não servem para processos longos: um job que roda por horas, uma transcodificação pesada, um treinamento. Cargas demoradas pedem outro modelo, como containers ou workers dedicados.
Statelessness
Cada invocação é sem estado: não há garantia de que a próxima chamada caia no mesmo ambiente, e a memória local não persiste entre execuções. Todo estado precisa morar fora, em um banco, um cache ou um armazenamento de objetos. Isso é saudável para escala, mas exige desenhar a função como uma peça verdadeiramente stateless.
Depuração e observabilidade
Depurar centenas de execuções efêmeras e distribuídas é mais difícil que acompanhar um processo único e contínuo. Sem logs, métricas e tracing bem instrumentados desde o início, um sistema serverless vira uma caixa-preta na hora do incidente.
O custo que ninguém previu
O modelo "pague só pelo que usar" é imbatível em volume baixo. A conta se inverte em volume alto e constante. Uma função chamada milhões de vezes por minuto, sem parar, pode custar mais do que alguns servidores dedicados fazendo o mesmo trabalho. O ponto de virada existe e precisa ser calculado, não presumido.
| Fator | Serverless favorece | Servidor dedicado favorece |
|---|---|---|
| Padrão de tráfego | Esporádico, com picos e vales | Constante e previsível |
| Volume | Baixo a médio | Alto e sustentado |
| Duração da tarefa | Curta (segundos) | Longa ou contínua |
| Sensibilidade a latência | Tolerante a cold start | Latência baixa e estável exigida |
| Gestão de infraestrutura | Quer terceirizar por completo | Time preparado para operar |
A regra é simples de enunciar e fácil de esquecer: serverless é ótimo quando o uso é intermitente; deixa de compensar quando o uso é alto e ininterrupto.
Vendor lock-in: o custo estratégico
Funções serverless tendem a se amarrar profundamente ao ecossistema do provedor: os gatilhos de eventos, os serviços vizinhos, os formatos e as integrações são específicos de cada nuvem. Isso acelera o desenvolvimento no começo, mas cria vendor lock-in: migrar para outro provedor depois pode significar reescrever boa parte da lógica de integração. Não é motivo para evitar serverless, e sim para entrar com os olhos abertos e isolar a lógica de negócio do código específico da plataforma sempre que possível.
Como decidir sem modismo
Serverless não é o futuro que substitui tudo, nem uma moda a evitar. É uma ferramenta com um encaixe muito claro. Um roteiro de decisão:
- A carga é orientada a eventos, esporádica ou de tráfego imprevisível? Serverless provavelmente é a melhor escolha.
- É um processo longo, contínuo ou de altíssimo volume constante? Containers ou servidores dedicados tendem a custar menos e sofrer menos com limites.
- A latência na frente do usuário é crítica? Avalie o impacto do cold start antes de colocar a função no caminho quente.
- O dado precisa de estado forte e persistente na própria execução? Repense; serverless empurra todo estado para fora.
- O melhor desenho é misto? Quase sempre. Muitos SaaS maduros usam serverless para eventos e tarefas assíncronas e mantêm o núcleo transacional em containers, o melhor de cada modelo no lugar certo.
A maturidade não está em escolher um lado, e sim em usar cada modelo onde ele rende. Serverless para o esporádico e o reativo; infraestrutura tradicional para o constante e o intensivo. Errar esse encaixe é o que transforma uma tecnologia excelente em uma armadilha cara.
Está avaliando serverless e não sabe onde ele encaixa no seu produto? Na ConstructorTI, ajudamos a desenhar arquiteturas híbridas que colocam funções serverless onde elas realmente reduzem custo e complexidade, sem cair em cold start no caminho crítico nem em contas surpresa no fim do mês. Se você quer decidir com números, não com hype, fale com a nossa engenharia e receba um diagnóstico da sua arquitetura.