AWS Lambda Web Functions

Artículo original ↗ Discusión en Hacker News ↗

AWS ha introducido Lambda Web Functions, una nueva forma de ejecutar aplicaciones web HTTP tradicionales directamente en Lambda con soporte para solicitudes concurrentes, escalado a cero y facturación basada en CPU, posicionándolo como respuesta a plataformas como Cloudflare Workers, Vercel y Cloud Run. Los comentaristas debaten los pros y contras entre funciones como servicio y enfoques basados en contenedores, centrándose en los arranques en frío, la transparencia de precios, la complejidad de las arquitecturas distribuidas y limitaciones de runtime como el soporte actual solo para Node.js. Muchos lo ven como un paso largamente esperado hacia un hosting web más “normal” en AWS, aunque señalan que alternativas como Cloud Run y Azure Container Apps ya ofrecen capacidades similares con contenedores.

Arranques en frío, escalado y concurrencia

  • Lambda Web Functions sigue escalando a cero; la primera solicitud después de estar inactivo es un arranque en frío.
  • El nuevo modelo de multiconcurrencia permite hasta ~128 solicitudes concurrentes por entorno; las ráfagas amortizan los arranques en frío para las solicitudes posteriores.
  • Algunos ven esto como latencia de “cola absoluta” solo después de estar inactivo; otros advierten que los arranques en frío y los límites de escalado aún pueden causar retrasos de varios segundos, especialmente sin aprovisionamiento.

Comparación con otras plataformas

  • Ampliamente leído como una respuesta a Cloudflare Workers, Vercel, Cloud Run, Azure Container Apps y App Engine.
  • Similitudes: escala a cero, concurrencia por instancia, sin adaptador para aplicaciones web estándar, facturación basada en solicitudes.
  • Diferencias: construido sobre microVMs Firecracker frente a los aislamientos V8 de Cloudflare. Algunos argumentan que los aislamientos son más disruptivos pero más difíciles de adoptar por las grandes nubes.
  • Varios comentarios destacan Cloud Run / Container Apps como arte previo: despliegas cualquier contenedor, obtienes autoescalado, a menudo con una DX más simple que la Lambda clásica.

Runtime, soporte de lenguajes y hoja de ruta

  • Actualmente solo Node.js; los comentaristas quieren Rust/Go/.NET/Java y contenedores genéricos o WASM.
  • SnapStart puede reducir los arranques en frío, pero el soporte varía según el runtime y se considera complejo.
  • La hoja de ruta de AWS (enlazada en el hilo) muestra soporte para imágenes de contenedor para Web Functions como “próximamente”, visto como una posible killer feature.

Precio y semántica de facturación

  • La nueva facturación de “CPU activa” se compara con Cloudflare Workers y Vercel Fluid: no pagas mientras solo esperas I/O.
  • La memoria sigue facturándose durante la vida del entorno en caliente; la transferencia de datos y los cargos por solicitud también importan.
  • Algunos sienten que la fijación de precios más simple de Cloudflare sigue siendo más comprensible.

Debate arquitectónico: FaaS vs contenedores/VMs

  • Críticos: FaaS hace que los sistemas sean más difíciles de razonar, fomenta microservicios excesivamente fragmentados, complica el desarrollo, la depuración y la monitorización, y tiene una semántica de escalado incómoda.
  • Partidarios: las Lambdas son triviales de usar con IaC, ideales para cargas de trabajo escasas o muy explosivas, y pueden ser muy baratas o efectivamente gratuitas para aplicaciones pequeñas.
  • Varios abogan por Lambdas monolíticas o contenedores sin servidor (Cloud Run/Container Apps/Fargate-style) en lugar de muchas funciones pequeñas.

Experiencia de desarrollador

  • Muchos celebran “Lambda sin la capa de adaptador”, especialmente en comparación con patrones anteriores (API Gateway + adaptadores para Express/Fastify, etc.).
  • Otros señalan que eso ya era posible con shims, así que el beneficio principal es el soporte de primera clase y la concurrencia, no una capacidad completamente nueva.