Serverless — Lambda, Cloud Functions e os trade-offs que ninguém conta

O nome "serverless" é marketing bem-sucedido: servidores existem, você simplesmente não os vê. O que muda é o modelo de responsabilidade — você entrega código de uma função, o provider executa esse código em resposta a eventos, e você paga exatamente pelo tempo de execução. A unidade de deploy deixa de ser um serviço persistente e passa a ser uma função efêmera que vive apenas durante a execução.

AWS Lambda foi lançado em 2014 e popularizou o modelo. Em 2024, Lambda executa trilhões de requisições por mês para milhões de clientes. O modelo claramente escala — mas o que os casos de sucesso não mostram com clareza são os trade-offs que aparecem quando você ultrapassa os casos de uso ideais.

O modelo de execução serverless

O ciclo de vida de uma invocação Lambda é:

1. Init: o provider baixa o código (ou container image), inicializa o ambiente de execução (runtime, JVM, Python interpreter), e executa o código de inicialização fora do handler
2. Invoke: o handler recebe o evento e produz uma resposta
3. Shutdown: após um período de inatividade (tipicamente 5-15 minutos), o ambiente é destruído

O estado sobrevive apenas durante a fase de Invoke e no período em que o ambiente permanece "aquecido" (entre invocações do mesmo ambiente). Variáveis globais e conexões de banco criadas fora do handler persistem entre invocações do mesmo ambiente — mas não entre ambientes diferentes ou após reinicialização. Isso cria uma peculiaridade: você pode ter estado acidental em Lambda, mas não pode depender dele.

Cold start — o problema que ninguém quer ter

Cold start é a latência de inicialização de um novo ambiente de execução. Acontece quando:

• Primeira invocação após deploy
• Invocação após o ambiente ter sido destruído por inatividade
• Aumento de concorrência além dos ambientes já aquecidos (burst de tráfego)

O cold start tem três componentes:

Uma função Python simples tem cold start de 50-100ms — irrelevante. Uma função Java com Spring Boot pode ter cold start de 5-10 segundos — catastrófico para APIs síncronas onde SLA p99 é de 200ms.

Mitigando cold start

Provisioned Concurrency: mantém N ambientes pré-inicializados e aquecidos, eliminando cold start para aqueles N ambientes. Custo: você paga pelas instâncias aquecidas mesmo quando não há invocações — o mesmo modelo de custo de containers.

resource "aws_lambda_provisioned_concurrency_config" "api" {
  function_name                  = aws_lambda_function.api.function_name
  qualifier                      = aws_lambda_alias.api_live.name
  provisioned_concurrent_executions = 10   # 10 ambientes sempre aquecidos
}

SnapStart (Lambda para Java): tira um snapshot do estado do ambiente após a inicialização, e restaura do snapshot em vez de reinicializar. Reduz cold start de JVM de segundos para centenas de milissegundos. Não é gratuito: o snapshot tem restrições (não pode usar state que muda entre invocações, como random seeds ou IDs).

Keep-warm com EventBridge: acionar a função a cada 5 minutos com um evento de ping. Evita destruição do ambiente por inatividade. Gambiarra funcional para baixo volume — para alto volume, provisioned concurrency é mais correto.

Otimizar o código de inicialização: mover imports pesados para dentro do handler (lazy loading), usar connection pooling para banco (RDS Proxy para Lambda), e preferir runtimes com cold start menor (Node.js, Python, Go > Java, .NET).

Limites que importam

O limite de concorrência de 1.000 por região é o que pega mais times desprevenidos: se você tem 10 Lambdas e um deles recebe um burst de 900 invocações simultâneas, os outros 9 podem ficar sem concorrência disponível e retornar throttling. Reserve concorrência explicitamente por função crítica:

resource "aws_lambda_function_event_invoke_config" "api" {
  function_name = aws_lambda_function.api.function_name

  maximum_retry_attempts = 0   # para APIs síncronas — não retentar em erro
}

# Reservar concorrência para função crítica
resource "aws_lambda_provisioned_concurrency_config" "api_reserved" {
  function_name  = aws_lambda_function.api.function_name
  qualifier      = "$LATEST"
  # reserved_concurrent_executions — bloqueia X para essa função
}

Vendor lock-in real em serverless

O código de uma função Lambda é portável: é uma função que recebe um evento e retorna uma resposta. Mas o ecossistema ao redor não é:

• Triggers: SQS, SNS, EventBridge, DynamoDB Streams, S3 Events — cada um tem formato de evento específico da AWS. O código que processa um DynamoDB Stream Event tem que conhecer a estrutura do evento AWS.
• Permissões: IAM roles e políticas são específicas da AWS
• Observabilidade: X-Ray para tracing, CloudWatch Logs Insights para consulta — não portável
• State: Step Functions para orquestração de workflows — proprietário
• API Gateway: autorizers, rate limiting, CORS — específico da AWS

Uma arquitetura serverless madura na AWS é tão locked-in quanto possível — cada serviço integrado adiciona camada de integração proprietária. Isso não é necessariamente ruim: a produtividade de integrar SQS + Lambda + DynamoDB é genuinamente alta. Mas é uma decisão consciente, não uma consequência ignorada.

A forma mais eficaz de reduzir lock-in sem perder produtividade é isolar a lógica de negócio do handler AWS. O handler faz apenas o parse do evento e chama código puro — o código puro pode ser testado sem AWS e potencialmente portado:

# Python — handler isolado do negócio
def lambda_handler(event, context):
    # Parsing específico do AWS event — lock-in aqui
    records = [parse_sqs_record(r) for r in event["Records"]]

    # Lógica de negócio — portável, testável sem AWS
    results = process_orders(records)

    return {"statusCode": 200, "body": json.dumps(results)}

Análise econômica — quando serverless compensa

Lambda cobra por número de invocações ($0,20 por 1M no us-east-1) e duração de execução ($0,0000166667 por GB-segundo). Para carga constante, containers geralmente ganham na comparação de custo:

Exemplo: API que processa 1.000 req/hora de forma constante, Lambda de 128MB usando 100ms por invocação:

• Lambda: 720.000 invocações/mês × $0,20/M + 720.000 × 0,1s × 0,128 GB × $0,0000166667/GB-s ≈ $0,29/mês
• Fargate (0,25 vCPU, 0,5 GB): ~$32/mês

Lambda vence por enorme margem em baixo volume. Mas com 100.000 req/hora:

• Lambda: $14 + $15 = $29/mês
• ECS com EC2 spot + autoscaling: $15-40/mês dependendo de instâncias

No alto volume, Lambda e containers ficam comparáveis — e containers ganham em previsibilidade de custo e ausência de cold start. A regra prática: Lambda vence economicamente para tráfego com picos extremos ou volume baixo-médio (<10M req/mês); containers vencem para carga constante e alta.

Event-driven patterns com Lambda

Os patterns mais comuns onde Lambda brilha:

Fan-out com SNS → Lambda: um evento publicado no SNS dispara múltiplas funções Lambda em paralelo. Processamento de um pedido: uma função atualiza o inventário, outra envia confirmação por email, outra notifica o sistema de logística.

Queue worker com SQS → Lambda: Lambda consome mensagens de uma fila SQS. Escalamento automático baseado no tamanho da fila. Ideal para processamento de imagens, envio de emails em batch, ou qualquer workload que pode ser processado de forma assíncrona.

# SAM template — Lambda consumindo SQS com falha parcial
ProcessorFunction:
  Type: AWS::Serverless::Function
  Properties:
    Handler: processor.handler
    Runtime: python3.12
    Events:
      SQSTrigger:
        Type: SQS
        Properties:
          Queue: !GetAtt MinhaFila.Arn
          BatchSize: 10           # processa até 10 mensagens por invocação
          FunctionResponseTypes:
            - ReportBatchItemFailures   # falha parcial — não reprocessa itens que já funcionaram

Scheduled jobs com EventBridge: substituição de cron jobs. Limpar banco de dados às 2h, gerar relatório diário, verificar certificados que vencem. Sem servidor dedicado para cron.

Orquestração com Step Functions: para workflows com múltiplos passos, lógica de retry, e ramificações condicionais, Step Functions orquestra Lambdas com estado persistido entre passos — elimina o problema de coordenação entre funções.

Decisões de engenharia

Perguntas de entrevista

def lambda_handler(event, context):
    failures = []
    for record in event["Records"]:
        try:
            process_message(record["body"])
        except Exception as e:
            failures.append({"itemIdentifier": record["messageId"]})
    return {"batchItemFailures": failures}

Exercícios práticos