本文翻译自 Can WebAssembly Solve Serverless’s Problems? 。
一位著名的 IT 分析师表示：“WebAssembly 有可能解决当今 Serverless 计算的一大缺陷：供应商锁定。”
serverless 计算在许多应用场景中的需求持续增长，对于那些希望在较少的基础架构管理下创建和运行应用程序的组织而言，这是一个好消息。对于那些希望提供软件应用程序、服务或两者都有，且不希望在本地服务器上进行重大投资或通过云供应商配置或管理自己的基础架构的创业公司来说，这是一个好消息。
Serverless 计算对一系列用例的需求持续增长，对于那些寻求创建和运行应用程序的组织来说，所涉及的基础设施管理量相对较少。这对于寻求提供软件应用程序、服务或两者的初创公司来说是个好消息，而无需对本地服务器进行大量投资，或者不必通过云供应商配置或管理自己的基础设施。
与在预建软件即服务（SaaS）平台上添加API或服务相比，Serverless 的替代方案允许组织以最小的开销和更少的维护管理任务开始提供自己的业务服务或应用程序。
根据分析公司 Omdia 的数据，这些优势有助于解释为什么 Serverless 市场的价值预计将从 2021 年的 100 亿美元翻两番到 2026 年的 400 亿美元以上。
Serverless 以多种方式帮助延续下一个 AirBnb 或 SaaS 提供商成功故事的神话。您可能会想象一个孤独的初创公司创始人，他使用笔记本电脑登录云服务，并在创建 serverless 帐户后开始建立自己的业务。 （如果这听起来好得令人难以置信，那是因为它在很多方面都是如此。）
无论如何，出于几个原因，serverless 应该比现在更好。除了与云供应商共享策略和数据以及网络保护相关的安全挑战外，serverless 的缺点包括但不限于延迟和许多组织的供应商锁定问题。
克服这些缺点是 WebAssembly 或 Wasm——至少在理论上——真正闪耀的地方。它的运行时结构旨在直接在 CPU 上运行，以便提供更直接的方式来运行分布在容器或不同设备和环境（想想边缘计算）上的相同应用程序和代码。
然而，问题在于 serverless 通常等同于供应商锁定。今天典型的第三方用例意味着 serverless 将需要第三方的支持，而第三方通常是云供应商。
对于许多人来说，serverless 架构可能等同于 Amazon Web Services 上的 Lambda 或来自其他云供应商（例如 Azure、Google Cloud、Oracle 或 IBM）的产品。
因此，在许多情况下，组织必须乐于将其多个基础架构委托给一个第三方云提供商，而不是多个供应商来管理其关键应用程序。仅出于这个原因，避免供应商锁定是 Wasm 的一个关键卖点。
“WebAssembly 有可能解决当今 serverless 计算的一大缺陷：供应商锁定，”Enterprise Management Associates (EMA) 的分析师 Torsten Volk 告诉 The New Stack。 “随着组织采用大量云，WebAssembly 可以提供一种交钥匙方式来运行和集成所有这些，同样好。那不是很好吗？
Wasm 并不是什么新鲜事物。在 2019 年万维网联盟 (W3C) 将其命名为网络标准之前，它成为与 HTML、CSS 和 JavaScript 并列的第四个网络标准。但 WebAssembly 背后的大部分兴趣和势头是它在浏览器之外的潜在用途。它不仅可以用于支持 Web 应用程序，还可以扩展到任何运行在 CPU 上的边缘环境和云原生平台，包括服务网格和边缘 Kubernetes 支持。
除了 JavaScript 之外，Wasm 可以运行的语言还包括 Rust、Go、.NET、C++、Java、PHP 和 Python。这些和其他尚未添加的语言的改进即将推出。一年前，Fermyon Spin 拥有仅适用于 Rust 和 Go 的 Wasm SDK。它现在增加了对 JavaScript/TypeScript Python 和 .NET 的支持。 Fermyon Technologies 的联合创始人兼首席执行官 Matt Butcher 表示：“语言支持正在迅速到来。”
“我们知道 Wasm 在浏览器中的传统，但我们也知道使 Wasm 在浏览器中出色运行的特性，使其在云端、边缘、设备上运行得同样好——事实上，在任何地方”Liam Randall 说，Cosmonic 的首席执行官兼联合创始人。
由于 Wasm 的运行时效率，组织可以全权委托在 Serverless 环境中创建、部署和管理应用程序，而无需管理基础设施。至少从理论上讲，与在云供应商管理的服务器上的 Serverless 环境中运行的应用程序相比，Wasm 应该提供卓越的运行时性能和更低的延迟。通过 API 依赖平台即服务 (PaaS) 解决方案，该过程变得更加容易。
“Wasm 绝对有潜力成为应用程序平台中的‘下一件大事’，因为它在近乎即时的启动时间、跨操作系统和云平台一致工作的超便携运行时以及严格的安全性方面具有巨大潜力，即完全基于零信任认证。这一切都非常令人兴奋。”EMA 的 Volk 说。
事实上，传统的 Serverless 方法需要 200 毫秒“或更长时间才能启动，”Butcher 说。 “在您的代码开始执行之前已经过了 200 毫秒。使用 Wasm，我们已经能够将启动时间缩短到一毫秒以下。再加上出色的开发人员体验，您就有了一个令人信服的理由来摆脱 Lambda。”
Butcher 说，Wasm 计算结构的设计方式使其“改变”了 Serverless 领域的潜力。他说，这是由于 WebAssemby 几乎即时的启动时间、较小的二进制文件大小以及平台和架构中立性，因为 Wasm 二进制文件可以使用运行当今 Serverless 基础设施所需资源的一小部分来执行。
“与重量级 [虚拟机] 和中量级容器相比，我喜欢将 Wasm 视为轻量级云计算平台，”他指出。 “开发人员只打包最基本的东西：一个 Wasm 二进制文件和一些支持文件。 Wasm 运行时负责其余的工作。”
依靠 Wasm 的 Serverless 运行时的直接好处是延迟更低，尤其是在将 Wasm 的范围不仅扩展到浏览器之外，而且扩展到云端之外时。这是因为它可以以相对较低的数据传输和计算开销直接分发到边缘设备或在边缘设备上分发。
“ Serverless 计算非常适合真正特定的用例。例如，最优先考虑的是云提供商为用户管理基础设施，”Randall 说。 “但实际上，如果我们专门为边缘或 [物联网] 用例设计应用程序，它们可以运行得更快、更高效。在离用户更近的地方运行应用程序可以减少延迟和通过网络传输的数据，从而为开发人员带来更好的用户体验和更低的成本。”
我们可以创建应用程序并在 serverless 基础架构中直接并同时以您选择的语言在许多不同的边缘设备上运行它的那一天——例如使用边缘和机器学习友好的 Python——应该很快就会到来，尽管我们还没有。目前在 Wasm 上运行的应用程序仍然主要限于 JavaScript 和 Rust，但还有很多工作要做。
“Wasm 是‘一次编写，随处运行’口号的新迭代。相同的二进制文件可以在 Windows、Linux 或 macOS 上运行。它可以在 Intel 或 Arm 架构上运行，甚至可以在更奇特的操作系统和硬件配置文件上运行，”Butcher 说。 “这是在边缘和云端取得成功的关键因素：可以将相同的应用程序移动到最适合用户需求的位置。”
Rust 和 JavaScript 代表着“伟大的婚姻”，Volk 说。 “Rust 带来了性能和安全性，而 JavaScript 带来了庞大的库生态系统，易于使用并拥有庞大的用户社区。这在数据科学、机器学习、图像处理等性能密集型领域开辟了一系列新的用例。”
在不久的将来，一些组织可能仍会选择经过试验和测试的 serverless 选项，尽管 WebAssembly 提供了计算性能优势和更低的延迟。这主要是由于我们仍处于 Wasm 的早期阶段，超出了其原始浏览器用例。
“使用 WebAssembly，您可能需要管理您的基础设施，包括服务器和网络，这可能会增加部署的复杂性和成本，假设 Kubernetes 和其他编排器中对 Wasm 的支持不能更快地采用 Wasm 友好的运行时，”Taylor Dolezal，云原生计算基金会 (CNCF) 的生态系统负责人在一封电子邮件回复中告诉 The New Stack。
“虽然许多工具和框架可用于 WebAssembly（得益于协作和充满活力的生态系统），但它们可能不像传统 serverless 平台那样成熟或健壮，这可能会影响开发速度和易用性。”
在 CNCF 最近发布的年度调查和报告中，该基金会表示“容器是新常态，Webassembly 是未来”。该报告还指出“随着容器现在成为主流，到 2022 年，serverless 架构的采用如何为 WebAssembly 奠定基础，这在本次调查中首次被问及。”
然而，虽然 Wasm 为应用程序创建了一个统一且安全的运行时，但它“仍然需要一个清晰的编排框架路径，”Dolezal 说。为此，runwasi 正在 containerd 项目中构建，以促进运行由 containerd 管理的 Wasm/WASI 工作负载，Dolezal 说。
然而，沃尔克敦促谨慎行事。 “Runwasi 是一个有前途且至关重要的项目，势头良好，但我们必须记住其 GitHub 存储库顶部显示的警告：‘Alpha 质量软件，请勿在生产中使用。’”他说。 “我们在 WAGI 存储库中也发现了一个非常相似的警告，而 Fermyon 非常令人兴奋但仍处于试验阶段的 Python SDK 仅在几天前才推出。
“一旦我们能够自信地在 Wasm 中运行 Python 应用程序并在 Kubernetes POD 中的容器上运行，我们将拥有一个真正独立于云的企业级 serverless 应用程序平台。”
归根结底，正如 CNCF 代表所指出的，“ serverless 功能和 Wasm 是我们这个云演化周期所需的组合。我们现在已经构建了一个包含 VM、容器和 Wasm 的免费套件，因此我们可能不需要新的‘Wasm 的 Kubernetes’，”Butcher 说。
“我们已经看到像 HashiCorp Nomad 这样的现有协调者已经做得非常出色。我对 Kubernetes 社区内 Wasm 的发展势头感到非常鼓舞（也感到惊喜），因此 Wasm 很可能成为我们现有云原生生态系统的补充。”