AWS Lambda Web Functions

Artigo original ↗ Discussão no Hacker News ↗

A AWS introduziu Lambda Web Functions, uma nova forma de executar apps web HTTP tradicionais diretamente no Lambda com suporte a requisições concorrentes, scale-to-zero e cobrança baseada em CPU, posicionando-o como resposta a plataformas como Cloudflare Workers, Vercel e Cloud Run. Comentadores debatem os trade-offs entre functions-as-a-service e abordagens baseadas em containers, com foco em arranques a frio, transparência de preços, complexidade de arquiteturas distribuídas e limitações de runtime, como o suporte atual apenas a Node.js. Muitos veem isso como um passo atrasado, mas bem-vindo, em direção a uma hospedagem web mais “normal” na AWS, embora observem que alternativas como Cloud Run e Azure Container Apps já oferecem capacidades semelhantes com containers.

Arranques a frio, escalabilidade e concorrência

  • Lambda Web Functions ainda escalam até zero; a primeira requisição após inatividade é um arranque a frio.
  • O novo modelo de multiconcorrência permite até ~128 requisições concorrentes por ambiente; picos amortizam os arranques a frio para as requisições subsequentes.
  • Alguns veem isso como latência de “cauda absoluta” apenas após inatividade; outros alertam que arranques a frio e limites de escalabilidade ainda podem causar atrasos de vários segundos, especialmente sem provisionamento.

Comparação com outras plataformas

  • Amplamente lido como uma resposta a Cloudflare Workers, Vercel, Cloud Run, Azure Container Apps, App Engine.
  • Semelhanças: scale-to-zero, concorrência por instância, sem adaptador para apps web padrão, cobrança baseada em requisições.
  • Diferenças: baseado em microVMs Firecracker vs os isolados V8 da Cloudflare. Alguns argumentam que isolados são mais disruptivos, mas mais difíceis de adotar por grandes clouds.
  • Vários comentários destacam Cloud Run / Container Apps como estado da arte anterior: implante qualquer container, obtenha autoscaling, muitas vezes com DX mais simples do que o Lambda clássico.

Runtime, suporte a linguagens e roadmap

  • Atualmente apenas Node.js; comentaristas querem Rust/Go/.NET/Java e containers genéricos ou WASM.
  • SnapStart pode reduzir arranques a frio, mas o suporte varia por runtime e é visto como complexo.
  • O roadmap da AWS (linkado no tópico) mostra suporte a imagens de container para Web Functions como “em breve”, visto como um possível recurso matador.

Preço e semântica de cobrança

  • A nova cobrança de “CPU ativa” é comparada ao Cloudflare Workers e ao Vercel Fluid: você não paga enquanto está apenas aguardando I/O.
  • A memória ainda é cobrada durante toda a vida do ambiente quente; transferência de dados e cobranças por requisição também importam.
  • Alguns acham que a precificação mais simples da Cloudflare continua mais fácil de entender.

Debate arquitetural: FaaS vs containers/VMs

  • Críticos: FaaS torna sistemas mais difíceis de raciocinar, incentiva microsserviços excessivamente fragmentados, complica desenvolvimento/debug/monitoramento e tem semântica de escalabilidade estranha.
  • Defensores: Lambdas são triviais de usar com IaC, ideais para cargas esparsas ou altamente explosivas em picos, e podem ser muito baratas ou efetivamente gratuitas para apps pequenos.
  • Vários defendem Lambdas monolíticas ou containers serverless (Cloud Run/Container Apps/Fargate-style) em vez de muitas funções pequenas.

Experiência do desenvolvedor

  • Muitos celebram “Lambda sem a camada de adaptador”, especialmente em comparação com padrões anteriores (API Gateway + adaptadores para Express/Fastify, etc.).
  • Outros observam que isso já era possível com shims, então o principal benefício é suporte de primeira classe e concorrência, não uma capacidade totalmente nova.