AWS Lambda Web Functions

原文 ↗ Hacker News 讨论 ↗

AWS 推出了 Lambda Web Functions，一种可直接在 Lambda 上运行传统 HTTP Web 应用的新方式，支持并发请求、扩展到零和基于 CPU 的计费，被定位为对 Cloudflare Workers、Vercel 和 Cloud Run 等平台的回应。评论者围绕冷启动、定价透明度、分布式架构复杂性以及当前仅支持 Node.js 等运行时限制，讨论了函数即服务与基于容器方案之间的取舍。许多人认为这是 AWS 朝着更“正常”的 Web 托管迈出的姗姗来迟的一步，同时也指出 Cloud Run 和 Azure Container Apps 之类的替代方案早已通过容器提供了类似能力。

冷启动、扩展与并发

  • Lambda Web Functions 仍然会扩展到零；空闲后的首次请求是冷启动。
  • 新的多并发模型允许每个环境最多约 128 个并发请求；突发流量会为后续请求摊薄冷启动成本。
  • 有些人认为这只是“绝对尾部”延迟，仅在空闲后出现；也有人警告，冷启动和扩展限制仍可能导致多秒延迟，尤其是在没有预置的情况下。

与其他平台的比较

  • 普遍被解读为对 Cloudflare Workers、Vercel、Cloud Run、Azure Container Apps、App Engine 的回应。
  • 相似之处：扩展到零、每实例并发、无需为标准 Web 应用提供适配器、按请求计费。
  • 不同之处：基于 Firecracker microVM，而 Cloudflare 使用的是 V8 isolates。有人认为 isolates 破坏性更大，但大型云厂商更难采用。
  • 几条评论强调 Cloud Run / Container Apps 作为先行方案：可部署任意容器，自动扩缩容，而且通常比传统 Lambda 的 DX 更简单。

运行时、语言支持与路线图

  • 目前仅支持 Node.js；评论者希望支持 Rust/Go/.NET/Java，以及通用容器或 WASM。
  • SnapStart 可以减少冷启动，但支持随运行时而异，并被认为较复杂。
  • 线程中链接的 AWS 路线图显示，Web Functions 的容器镜像支持“即将推出”，被视为潜在的杀手级功能。

定价与计费语义

  • 新的“active CPU”计费被比作 Cloudflare Workers 和 Vercel Fluid：仅在等待 I/O 时不收费。
  • 内存仍会在热环境存活期间计费；数据传输和按请求收费也很重要。
  • 有些人觉得 Cloudflare 更简单的定价仍然更容易理解。

架构争论：FaaS vs 容器/VM

  • 批评者：FaaS 让系统更难推理，鼓励过度碎片化的微服务，增加开发/调试/监控难度，并带来别扭的扩缩容语义。
  • 支持者：Lambda 与 IaC 结合非常容易使用，非常适合稀疏或高度突发的工作负载，而且对小型应用来说可能非常便宜，甚至近乎免费。
  • 几位评论者更支持单体 Lambda 或无服务器容器（Cloud Run/Container Apps/Fargate 风格），而不是许多小函数。

开发者体验

  • 许多人欢迎“没有适配器层的 Lambda”，尤其是与之前的模式相比（API Gateway + Express/Fastify 等适配器）。
  • 也有人指出，这些本来就可以通过 shim 实现，因此主要收益是一级支持和并发，而不是完全新的能力。