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