A história de amor com serverless costuma terminar no primeiro relatório de custos inesperado ou no primeiro incidente que ninguém consegue diagnosticar. É no dia a dia, com o sistema rodando em produção e gente real dependendo dele, que a abordagem revela seu verdadeiro caráter.
Lançar serverless é fácil. Operar serverless é onde mora a dificuldade que ninguém menciona nos tutoriais. Os mesmos atributos que tornam a tecnologia atraente, execução efêmera, escalabilidade automática, cobrança por uso, viram desafios concretos quando você precisa entender, monitorar e pagar pelo que está rodando.
Este texto é sobre essa fase. Não sobre conceito nem implementação, mas sobre o que acontece depois que tudo está no ar e a responsabilidade de manter o barco flutuando é sua. Observabilidade, custos e operação: os temas que separam quem brinca de serverless de quem opera serverless de verdade.
O choque da produção
Em desenvolvimento, tudo parece sob controle. Você testa uma função, ela responde, você segue. Em produção, com tráfego real, comportamentos que você nunca viu começam a aparecer.
Funções demoram mais do que o esperado em certos momentos. Erros surgem em pontos imprevistos. O custo do mês vem diferente do estimado. E, quando você tenta entender o porquê, descobre que não tem visibilidade suficiente para responder.
Esse é o choque da produção serverless. Um sistema distribuído em dezenas de execuções efêmeras é, por natureza, difícil de enxergar. E o que você não enxerga, você não controla.
A tese: serverless transfere o trabalho para a operação
Minha posição é que serverless não elimina o esforço operacional, ele o transforma e, em alguns aspectos, o intensifica.
Você deixou de cuidar de servidores, é verdade. Mas ganhou a responsabilidade de operar um sistema mais espalhado, mais dinâmico e mais difícil de observar. O trabalho não sumiu. Mudou de natureza.
Quem adota serverless imaginando que a operação fica trivial está se preparando para uma decepção. A operação fica diferente, e dominá-la exige investir em três frentes que costumam ser negligenciadas: observabilidade, controle de custos e disciplina de monitoramento contínuo.
Observabilidade: enxergar o invisível
Em uma aplicação tradicional, você pode entrar no servidor e investigar. Em serverless, não há servidor para entrar. As funções nascem e morrem. Quando algo dá errado, o ambiente da falha já não existe mais.
Por isso, observabilidade não é um luxo em serverless, é a única forma de entender o sistema. Isso significa três coisas que precisam estar no lugar desde o começo.
Logs estruturados, que registrem o que cada função fez de forma pesquisável. Métricas, que mostrem padrões de execução, duração, erros e uso ao longo do tempo. E rastreamento distribuído, que permita seguir uma requisição enquanto ela atravessa várias funções e serviços.
Sem essas três camadas, depurar um problema em produção vira adivinhação. Com elas, você consegue responder à pergunta mais importante da operação: o que está acontecendo, agora, dentro do meu sistema?
Custos: o vilão silencioso
O modelo de pagar por uso é vendido como vantagem, e muitas vezes é. Mas no dia a dia ele esconde uma armadilha. Quando o custo é proporcional ao uso, um erro pode custar dinheiro de verdade, em tempo real.
Uma função em loop indevido, um evento que dispara em cascata, um pico de tráfego malicioso, tudo isso vira fatura. E como serverless escala automaticamente, ele escala o problema com a mesma eficiência com que escalaria o sucesso.
Operar serverless com responsabilidade exige acompanhar custos de perto. Definir alertas para gastos anômalos. Entender quais funções consomem mais. Estabelecer limites onde fizer sentido. O fim do mês não pode ser o momento em que você descobre que algo saiu do controle.
Para uma organização pública, isso é ainda mais sensível: orçamento previsível importa, e uma fatura de nuvem que estoura sem aviso é um problema de gestão, não só técnico. Custo precisa ser monitorado como qualquer outra métrica de saúde do sistema.
Operação no cotidiano: o que muda na rotina
Atualizações e versões
Atualizar dezenas de funções independentes exige processo. Sem automação e versionamento, você perde o controle de o que está rodando onde. A rotina operacional saudável trata cada mudança como algo rastreável e reversível.
Lidar com falhas parciais
Em um sistema espalhado, falhas raramente derrubam tudo. Em vez disso, partes falham enquanto outras seguem. Operar bem significa projetar para falhas parciais: tentativas automáticas, filas que retêm o que não pôde ser processado, e clareza sobre o que fazer quando uma peça cai.
Limites do provedor
Toda plataforma serverless tem limites, de execução simultânea, de duração, de tamanho. No dia a dia, esses limites podem te surpreender em um pico. Conhecê-los e monitorar quão perto você está deles faz parte da operação madura.
Um exemplo do cotidiano operacional
Pense num sistema serverless que processa solicitações de cidadãos para um serviço municipal. Tudo funciona bem até que, num dia de prazo final, o volume dispara.
Sem observabilidade, a equipe veria apenas reclamações de lentidão sem saber a causa. Com observabilidade, ela enxergaria que uma função específica está esbarrando num limite de concorrência e que os custos subiram junto com o tráfego.
A operação madura agiria com informação: ajustaria limites, identificaria gargalos, e no dia seguinte revisaria os custos do pico para entender se valeu a pena. Sem essa visibilidade, restaria apagar incêndio no escuro. É essa diferença que define a maturidade operacional.
Operar é onde a verdade aparece
Serverless recompensa quem o opera com seriedade e pune quem o ignora depois do lançamento. A tecnologia entrega flexibilidade e economia, mas cobra atenção contínua em observabilidade e custos.
A lição que carrego é simples. O lançamento é o começo, não o fim. Sistemas vivem no dia a dia, e é lá que se descobre se a arquitetura foi uma boa decisão ou uma promessa não cumprida.
Serverless brilha para quem entende que a conta, técnica e financeira, chega todo dia, não só no lançamento.
Se você opera serverless em produção e sente que falta visibilidade ou controle de custos, vale conversar. Tenho outros artigos no blog sobre o conceito de serverless, casos de uso e implementação que completam essa jornada do começo ao dia a dia.
Leia também
- Performance de aplicativos: o que muda no dia a dia de quem opera um produto
- Cloudflare Workers em produção: o que muda depois do hello world
- Observabilidade além dos logs: o que OpenTelemetry muda na prática
- Serverless para aplicativos: arquitetura com exemplos reais
- Serverless para aplicativos: arquitetura na prática
- GitOps com ArgoCD: Automação de Deploys Declarativos