Serverless na prática: quando faz sentido, quando não faz e um exemplo simples

O que é serverless de verdade, um exemplo de função, os casos em que ele brilha e os pontos de atenção (cold start, limites, custo em escala e dependência do provedor).

E aí pessoal, tudo bem?

O nome engana: serverless não significa que não existe servidor. Significa que o servidor não é problema seu. Você entrega o código, e o provedor cuida de provisionar, escalar, aplicar patches e desligar quando não há uso. Você paga pela execução, e não por uma máquina ligada 24 horas.

Como funciona

O modelo mais conhecido é o de funções (FaaS): pequenos trechos de código que rodam em resposta a um evento.

• uma requisição HTTP chega;
• um arquivo é enviado para um bucket;
• uma mensagem cai numa fila;
• um agendamento dispara (tipo um cron).

Os principais exemplos são o AWS Lambda, o Azure Functions e o Google Cloud Functions. Existe também o serverless de containers, como o Google Cloud Run, o Azure Container Apps e o Knative no Kubernetes: você entrega uma imagem de container e ganha a mesma escala automática, inclusive até zero.

Um exemplo simples

Uma função em Python para o AWS Lambda que responde a uma requisição HTTP:

# handler.py
import json


def lambda_handler(event, context):
    nome = (event.get("queryStringParameters") or {}).get("nome", "mundo")
    return {
        "statusCode": 200,
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps({"mensagem": f"Olá, {nome}!"}),
    }

Repare no que não aparece: nada de servidor web, porta, sistema operacional ou balanceador. Você escreve a função, e a plataforma cuida do resto, inclusive de rodar mil cópias dela se chegarem mil requisições ao mesmo tempo.

Onde serverless brilha

• Tráfego irregular: uma API que recebe muitas chamadas no horário comercial e quase nada de madrugada;
• Processamento por evento: gerar a miniatura de uma imagem enviada, processar um arquivo que chegou, reagir a uma mensagem;
• Tarefas agendadas: relatórios, limpezas e integrações que rodam algumas vezes por dia;
• Protótipos e MVPs: sobe rápido e custa quase nada enquanto ninguém usa.

Onde é preciso cuidado

⚠️ Cold start: se a função ficou parada, a primeira chamada demora mais, porque o ambiente precisa ser criado. Para a maioria das APIs, isso não é perceptível, mas para algo muito sensível a latência pode ser um problema. Os provedores oferecem opções de manter instâncias "quentes", que custam a mais.

• Limites: tempo máximo de execução (no Lambda, 15 minutos), memória e tamanho do pacote. Processos longos precisam ser quebrados ou ir para outro serviço.
• Custo em escala: pagar por execução é ótimo com pouco uso. Com tráfego alto e constante, uma aplicação em containers ou VMs pode sair mais barata. Faça a conta com o volume real, e não com o da apresentação comercial. Falei sobre esse tipo de conta neste post sobre custos de cloud.
• Observabilidade: com dezenas de funções pequenas, entender o caminho de uma requisição exige logs centralizados e tracing desde o começo.
• Dependência do provedor: o código da função até é portável, mas os gatilhos, permissões e serviços em volta são específicos de cada nuvem. Migrar depois dá trabalho.

💡 Um meio-termo que tem ganhado espaço: o serverless de containers (Cloud Run, Container Apps, Knative). Você empacota a aplicação numa imagem comum, que roda em qualquer lugar, e ainda ganha a escala automática. A dependência do provedor fica bem menor.

Como decidir

1. O tráfego é irregular ou baseado em eventos? Ponto para serverless.
2. O processamento é curto (segundos ou poucos minutos)? Ponto para serverless.
3. O tráfego é alto e constante, ou o processamento é longo? Ponto para containers ou VMs.
4. O time tem pouca gente para cuidar de infraestrutura? Ponto forte para serverless.

Considerações Finais

Serverless não é a resposta para tudo, mas para cargas irregulares e orientadas a eventos é difícil de bater: sobe rápido, escala sozinho e custa pouco quando ninguém está usando. O segredo é entrar sabendo dos limites, fazer a conta com o volume real e cuidar da observabilidade desde o primeiro dia.

Abs e até a próxima!!!

:wq!

Post publicado originalmente em agosto de 2024 e atualizado em novembro de 2026.