Desenvolvimento Serverless: Benefícios Reais, Desafios (Cold Start e Estado) e Quando Ele Não Basta

skail · 2026-07-20 · 8 min

TL;DR: Serverless entrega escala automática e paga-o-que-usa — isso é real. O que ele não resolve é estado entre passos, e é exatamente aí que uma cadeia de agente de IA quebra. Execução durável ataca o problema que sobra depois que a fatura de infra já caiu.

A promessa é real. O problema é o que ela deixa de fora

Desenvolvimento serverless resolve um problema específico e resolve bem: você para de gerenciar servidor. Sobe uma função, ela escala sozinha conforme a demanda, você paga pelo que rodou — não pela capacidade ociosa parada esperando tráfego às 3h da manhã.

Isso não é hype. É a razão pela qual toda equipe que testou serverless nos últimos anos ficou. Só que existe uma pergunta que a maioria dos guias sobre "benefícios do serverless" não faz: o que acontece quando a sua função não termina em uma chamada só?

Essa pergunta importa mais a cada mês, porque cada vez mais sistemas têm um agente de IA no meio do caminho — e um agente não é uma função pura de entrada-e-saída. É uma cadeia: buscar contexto, chamar o modelo, validar a resposta, decidir o próximo passo, talvez chamar de novo. Cada elo dessa cadeia é um lugar onde o processo pode cair. E é exatamente aí que a arquitetura serverless clássica — a que você conhece de FaaS tradicional — mostra o que não foi feita para fazer.

Dando o crédito onde é devido: os benefícios são reais

Antes de ir para o que quebra, vale reconhecer o que funciona — porque descartar serverless por completo seria tão errado quanto usá-lo sem entender o limite.

Escala elástica de verdade. Você não provisiona capacidade adivinhando pico de tráfego. A plataforma sobe e desce instâncias conforme a demanda chega, sem intervenção manual.

Custo alinhado ao uso. Zero requisições, zero custo de computação. Para cargas de trabalho intermitentes — um webhook que dispara três vezes por dia, um relatório mensal — isso é economia real, não promessa de slide de vendas.

Foco no código de negócio. Sem servidor para patchear, sem cluster para dimensionar. O time de engenharia escreve a função e a lógica de domínio, não a camada de infraestrutura embaixo dela.

Esses três pontos sustentam a maior parte do argumento a favor de serverless — e continuam verdadeiros. O problema nunca esteve neles.

Onde a conta não fecha: os desafios que o slide de benefícios não mostra

Cold start é imprevisível, não apenas lento. Uma função que fica ociosa por minutos precisa "esquentar" antes de responder. Para uma chamada isolada, isso é um problema de latência tolerável. Para uma cadeia de agente — busca contexto → chama modelo → valida → decide próximo passo — cada cold start no meio do caminho é uma variável de tempo que você não controla e não consegue prever no seu SLA.

Funções são stateless por design — e isso empurra o estado para fora, sempre. Isso é uma decisão de arquitetura correta para o caso de uso que serverless resolve bem. Mas cada vez que seu processo precisa lembrar "em que passo eu estava" — algo trivial em um agente que decide, espera uma resposta, e continua — você precisa reconstruir esse contexto de fora: banco, cache, fila. Cada camada extra é mais uma peça que pode falhar, mais uma peça que sua equipe precisa operar e monitorar.

Orquestração vira responsabilidade sua, não da plataforma. Encadear três, quatro, cinco funções serverless em sequência — com retry seletivo, com "se o passo 3 falhar, desfaça só o passo 2" — não é algo que a plataforma resolve por você. Você escreve essa lógica de coordenação, geralmente espalhada entre filas, event bridges e um pouco de sorte.

O ponto central é matemático, não filosófico: se cada função individual tem 99% de taxa de sucesso — um número já bom — e o seu processo encadeia cinco delas, a chance de completar as cinco sem nenhuma falha cai para cerca de 95%. Multiplique por mais passos, como uma cadeia de agente de IA costuma ter, e o número piora rápido. É a mesma matemática que detalhamos aqui sobre por que agentes de IA em produção falham mais do que a demo sugeria.

O que resolve o problema que sobra: execução durável

skail não é serverless — e não tenta competir nesse território. É uma plataforma de execução durável: você anota um método com [SkailFunction], os passos internos com [SkailCommand], e cada passo fica persistido automaticamente. Se o processo cair entre o passo 2 e o passo 3, ele retoma do passo 3 — não do zero, e sem você escrever a lógica de "onde eu parei" na mão.

[SkailFunction]
public async SkailTask ProcessarSolicitacaoAgente(Guid solicitacaoId)
{
    var contexto = await BuscarContexto(solicitacaoId);
    var resposta = await ChamarModelo(contexto);
    var validado = await ValidarResposta(resposta);
    if (!validado.Aprovado)
    {
        await RegistrarRejeicao(solicitacaoId, validado.Motivo);
        return;
    }
    await ExecutarAcao(solicitacaoId, resposta);
}
[SkailCommand]
public async SkailTask<ContextoAgente> BuscarContexto(Guid solicitacaoId)
{
    return await ContextoRepository.Carregar(solicitacaoId);
}

Repare no que não muda: ainda é C#, ainda é async/await, ainda é o jeito que você já programa. O que muda é que cada [SkailCommand] fica salvo assim que termina — se ChamarModelo for a chamada que falha, BuscarContexto não roda de novo. Zero paradigm shift, sem novo modelo mental — só dois atributos.

Levando isso para a prática

Os três primeiros pontos abaixo valem tanto para serverless quanto para execução durável — são boas práticas de arquitetura, ponto. Os dois últimos são onde a diferença aparece na prática:

• Modularize por responsabilidade, não por arquivo. Cada função (ou [SkailCommand]) deve fazer uma coisa que você consegue nomear em uma frase.
• Use serviços gerenciados para o que não é diferencial do seu produto — banco, autenticação, mensageria.
• Monitore por execução, não só por log. Você precisa saber qual passo rodou, quanto tempo levou, se teve retry — não só que "algo aconteceu às 14h32".
• Pare de reconstruir estado na mão. Se você está escrevendo código só para lembrar "em que ponto o processo estava", isso é sinal de que o problema não é falta de mais uma fila — é falta de execução durável.
• Teste o caminho de falha, não só o caminho feliz. Derrube o processo no meio de propósito. Se ele não retoma sozinho de onde parou, o gap vai aparecer em produção, não no seu ambiente de teste.

Serverless para o que ele resolve bem. Execução durável para o que sobra.

Serverless não é o vilão — é a ferramenta certa para cargas intermitentes e sem estado. O erro é esperar que ele resolva coordenação de múltiplos passos e memória de processo, que nunca foi o que ele prometeu resolver. Se o seu sistema tem um agente de IA decidindo, esperando, e continuando — ou qualquer processo de negócio que precisa lembrar onde parou — vale conhecer a introdução à execução durável e ver como isso se encaixa no que você já tem, sem reescrever nada.