Lambda: serverless sem sustos
Funções que reagem a eventos e fatura que dorme junto: o modelo mental do Lambda, os 5 sustos (cold start, 15 min, conexões, duplicatas, monolambda) e o antídoto de cada um.
A promessa do Lambda é a mais radical da nuvem: esqueça servidores. Você escreve uma função, a AWS a executa quando algo acontece, e a fatura cobra pelos milissegundos usados (aws.amazon.com/lambda). Zero uso, zero custo; um milhão de execuções simultâneas, a AWS que se vire.
A promessa é real. Os sustos também, e todos são evitáveis quando se entende o modelo.
O modelo mental: função que reage a eventos
Lambda não é "um servidor menor"; é outra categoria. Sua função reage: a uma requisição HTTP (via API Gateway, o próximo artigo da série), a um arquivo no S3, a uma mensagem na fila SQS, a um agendamento, a um evento do DynamoDB.
// handler.js: redimensiona imagens que chegam no S3
export async function handler(event) {
for (const registro of event.Records) {
const { bucket, object } = registro.s3;
const original = await s3.getObject(bucket.name, object.key);
const thumb = await redimensionar(original, 400);
await s3.putObject(bucket.name, `thumbs/${object.key}`, thumb);
}
}
Repare no que não existe: servidor, cluster, pod, processo rodando à espera. Cada evento materializa uma execução; mil arquivos ao mesmo tempo materializam mil execuções paralelas, sem você configurar nada.
Os sustos (e o antídoto de cada um)
1. Cold start. A primeira execução (ou após ociosidade) paga o boot do ambiente: de dezenas de ms (Node, Python) a segundos (JVM pesada com VPC mal configurada). Antídotos: dependências enxutas (o zip pequeno importa), runtimes leves, e provisioned concurrency para os endpoints em que o p99 é contrato, pagando por instâncias quentes.
2. O limite de 15 minutos (e ele é seu amigo). Lambda encerra em no máximo 15 min. Tarefa maior? Não é caso de Lambda: é fila com worker, Step Functions orquestrando pedaços, ou um container. O limite força o desenho certo: funções pequenas e focadas.
3. Conexões de banco. Mil execuções paralelas = mil conexões, e o Postgres desmaia. Antídotos: RDS Proxy (pool compartilhado), DynamoDB (que casa nativamente com o modelo), ou HTTP APIs de dados.
4. Execuções duplicadas. Gatilhos assíncronos entregam pelo menos uma vez: a idempotência não é opcional, e as DLQs de destino continuam valendo.
5. O monolambda. O antipadrão de empurrar um Express inteiro para dentro de uma função gigante: cold start pior, observabilidade borrada, deploy tudo-ou-nada. Lambda pede granularidade: uma responsabilidade por função.
Quando o Lambda brilha (e quando foge)
Brilha: cola entre serviços (o S3→thumbnail acima), processamento de eventos e filas, crons sem servidor dedicado, APIs de tráfego imprevisível ou baixo (paga zero na madrugada), automações internas, webhooks.
Foge: cargas contínuas de alto volume constante (um container fica mais barato no platô), latência p99 rígida sem verba para concurrency provisionada, processos longos, e dependências pesadas de estado local.
A conta de custo tem um ponto de virada: tráfego constante e alto favorece containers; variável e com vales, Lambda. Times maduros misturam: a API principal no ECS, os eventos e colas em Lambda.
Checklist de produção
- Uma responsabilidade por função; dependências mínimas.
- Idempotência e DLQ nos gatilhos assíncronos.
- RDS Proxy (ou Dynamo) para dados; segredos no Secrets Manager.
- Logs estruturados com IDs de correlação; alarmes de erro e duração.
- Tudo declarado como código, o assunto do artigo de CloudFormation desta série.
Desenhar essa fronteira (o que vira função, o que fica em container, e a esteira dos dois) é parte do nosso serviço de Cloud e Infraestrutura.
Tem um cron rodando numa EC2 ligada 24h só para isso? Conte para a IA da Rabelo Digital, aqui no canto da tela, e ela mostra a versão Lambda (e a economia). Sem formulário, sem espera.
Deixe um Comentário