Posted on September 6, 2023 by Chris Aniszczyk, Vivian Hu. and Michael Yuan

CNCF projects highlighted in this post

containerd logo CRI-O logo Dapr logo Envoy logo Harbor logo Istio logo Knative logo ko logo Kuasar logo KubeEdge logo Kubernetes logo Kubewarden logo OpenFunction logo OpenYurt logo SuperEdge logo

By Chris Aniszczyk, Vivian Hu and Michael Yuan

“Containers are the new normal, and WebAssembly is the future.”  

— CNCF Annual Survey 2022 key findings.

Originally created as a secure sandbox to run compiled C/C++ code in web browsers, WebAssembly (Wasm) has been gaining traction and momentum on the server-side. In the cloud, Wasm provides a lightweight, fast, secure, language-agnostic, and cross-platform application runtime for diverse user-submit workloads. It is quickly becoming a key part of the cloud-native technology stack.

As Wasm is adopted across cloud-native projects, products, and services, the CNCF worked together with the Wasm community to create a Wasm landscape to help better understand the scope of the Wasm ecosystem. As the original Cloud Native Landscape helped chart the massive ecosystem around cloud native technologies, we believe the same is needed for Wasm as the ecosystem evolves and grows.

The initial Wasm landscape, published in time for the WasmCon conference, includes 11 categories and 120 projects or products, representing $59.4B in total economic value. The Wasm landscape is divided into two large areas: Dev (application development) and Ops (application deployment). 

CNCF wasm landscape

Application development

Wasm application development requires its own ecosystem of programming languages and related tooling, such as compilers, frameworks, libraries, tools, and runtimes. 

Programming languages

When developers create an application, they start with the selection of a programming language! One of the features of Wasm is that it is able to run applications written in a variety of different programming languages. However, that does not mean all programming languages are created equal.

In fact, there are 4 classes of programming languages in the Wasm landscape. 

Compiled languages

The first class citizens are the languages that can be directly compiled to Wasm bytecode, and run in Wasm runtimes without any dependency. C, C++, Zig and Rust are in this group. They produce the fastest and smallest Wasm applications. 

Let’s take Rust as an example. After installing the Rust languages, all you need to is add the wasm32-wasi target.

Managed languages

Managed languages are still compiled languages. But the compiler output requires a “managed runtime” to run properly. The most common task for the managed runtime is garbage collection (or GC).

For languages like Kotlin and Dart, the Wasm GC feature is sufficient. Leading Wasm runtimes such as WasmEdge, Wasmtime and v8 have recently added Wasm GC support. 

For Go, the compiler embeds the necessary runtime binary into the compiled Wasm bytecode. That increases the Wasm application’s size but still delivers a good developer experience. 

For complex managed languages, such as Java and .Net (e.g., C#), we need to compile and run their managed runtimes (eg the JVM) together with the bytecode application in Wasm. That is often a heavyweight approach. 

Scripting languages

Scripting languages like JavaScript, Ruby, PHP, and Python can run in Wasm. The approach here is to compile the scripting language interpreter, which is typically written in C, into Wasm. Then the Wasm-based interpreter program can execute the scripts.

For example, the WebAssembly Laungage runtimes project by VMware Labs has ported the Python and PHP interpreters to Wasm. 

The WasmEdge QuickJS project provides a JavaScript interpreter together with a Wasm library that supports the node.js API in JavaScript.

Diagram flow showing WebAssembly runtime

Source: WasmEdge QuickJS docs

“Compile to Wasm” languages

The last, but not the least, are a new generation of compiled languages that are optimized for the Wasm target. They are still in very early stages. But if done right, they have the potential to become the true first class citizens in the Wasm landscape. 

Moonbit and Grain are the two leading examples in this category. They are designed with modern language features found in Go and Rust, and optimized for efficient Wasm compilation and execution.

Moonbit, while still early, comes with a whole suite of tooling from dynamic code completion to online IDEs. 

Runtimes

Once the source code is compiled into Wasm bytecode, you will need a Wasm runtime to execute them. Wasm runtimes provide all the features and benefits we typically associate with Wasm, such as sandbox safety, security, speed, and cross-platform portability. They are at the center of the landscape.

In this cloud-native Wasm landscape, we will focus on Wasm runtimes that are popular on the server side. We have WasmEdge (CNCF sandbox), Wasmtime/lucet, Wamr, WAVM, Wasmer, wasm3, Lunatic, wazero, Wasmer, and V8.

Application frameworks

A Wasm runtime is analogous to an operating system. Libraries and frameworks provide high level and easy to use components needed for application developers.

The WasmEdge runtime is unique in its support for advanced POSIX APIs beyond the Wasm standard, which allows many popular Rust and JS application frameworks such as tokio, hyper, reqwest, warp, node.js, as well as MySQL / Postgres / Redis / Kafka / ElasticSearch client libraries, to run in WasmEdge. However, for all other Wasm runtimes, application frameworks are required to provide essential features, such as HTTP / HTTPS networking and database access. 

In this part of the landscape, we cover Spin, WasmCloud (CNCF sandbox), SpiderLightning, WasmEdge plug-ins, Dapr SDK for WasmEdge, Homestar, Ambient, WASIX, Extism, Timecraft, vscode-wasm, and WasmEx.

Edge/Bare metal

A key feature of Wasm is cross-platform portability, which means the ability to execute the same bytecode application across different operating systems and CPU architectures. In the era of the JVM, the OSes are limited to Unix-like systems (eg Linux), Windows and MacOS. Wasm, however, can run on non-traditional systems commonly used in edge and IoT computing. 

Docker and Linux containers are never cross platform. The container image must match the host CPU, for instance. 

AI inference

As AI workloads gain traction in cloud data centers, Wasm is increasingly used as an alternative to the heavyweight, complex, and slow Python stack. The WASI NN spec defines how a Wasm runtime should interact with a native AI/ML library, such as PyTorch and TensorFlow, to do AI inference in high-performance languages like Rust.

Wasmtime, WasmEdge, and WAMR are among the Wasm runtimes that support WASI NN. 

For instance, the WasmEdge Runtime supports OpenVINO, Pytorch, Tensorflow, TensorFlow Lite, and MMGL/Llama2 as inference backends, as well as OpenCV, ffmpeg as pre- or post-processors. It supports diverse models such as mediapipe, document AI, and llama2. 

Embedded function

Wasm can safely execute user-defined or community-contributed code as embedded functions (or, plug-ins) in software products.

In this part of the Wasm landscape, we showcase software products that have chosen and integrated Wasm as the plugin mechanism. The longest category is databases and data streaming applications, where Wasm is used to execute user-defined functions (UDFs). 

Databases like Libsql, OpenGauss, and Singlestore, and messaging queues like Open Policy Agent, InfinyOn, YoMo, eKuiper, and Redpanda, are using Wasm to execute UDFs. Traffic proxies such as Envoy, Istio, APISIX, KubeWarden, and NGINX are using Wasm to execute custom logic in the data plane. FaaS platforms like OpenFunction and Knative allows Wasm functions to be embedded in Kubernetes pods.

Tooling

Finally, developers rely on tools to piece together languages, frameworks, libraries and runtimes into working applications. The maturity of tooling is a great proxy measure of the maturity of the entire developer ecosystem. In the Wasm landscape, we cover important tools used to build Wasm apps. 

Application deployment

After you have created a Wasm app, the next step is to deploy and scale it in production. There is an abundance of tools, frameworks and services in the cloud native landscape to manage application deployment. Many of them have integrated Wasm support. 

Orchestration & management

Wasm containers can be seamlessly managed by existing containers tools like Docker, containerd and Kubernetes. There are two approaches to manage Wasm apps as “containers”. Both approaches enable you to build Kubernetes clusters that run Linux containers and Wasm containers side by side.

Approach #1 is to use an OCI runtime, such as crun and youki,, at the base of the container management stack. crun detects whether an OCI image is wasm or Linux based on image’s target OS/CPU platform. If the image targets wasi/wasm, crun would bypass the Linux container setup process and just use WasmEdge to run it. Based on crun or we can get the entire Kubernetes stack, including CRI-O (CNCF project), containerd (CNCF project), Podman, kind, K8s (CNCF project), OpenYurt (CNCF project), SuperEdge (CNCF project), KubeEdge (CNCF Project), to work with Wasm images. 

Approach #2 is to use a containerd-shim, such as runwasi, to run Wasm applications in containerd. When containerd receives an image, it checks the image’s target platform, it routes to runwasi for execution if the image is wasi/wasm, and routes to runc if the image is for x86 or arm.

Building on Kubernetes, we also cover several emerging tools to help manage production Wasm workloads. 

Kuasar is another container runtime that supports multiple types of sandboxes, including microVMs, Linux containers, app kernels, and WebAssembly runtimes.

Kwasm is a Kubernetes Operator, which adds WebAssembly support to your Kubernetes Nodes. It works with local and managed cloud K8s distributions based on Ubuntu/Debian with Containerd,

container2wasm is a container-to-wasm image converter that enables to run the container on WASM.

Hosted platform

If you don’t want the trouble of running your own servers and Kubernetes clusters, a hosted platform is a great choice for deploying and scaling Wasm applications as services. 

Decentralized platforms

Blockchain-based smart contract platforms are decentralized cloud computing networks. Instead of a central operator running all workloads, your cloud applications (ie smart contracts) are executed by nodes in the network. Since smart contracts are untrusted and must be executed very frequently (hundreds of times per second on every computer), Wasm is an ideal execution engine for this use case. Indeed, almost all leading smart contract blockchain networks have adopted Wasm.

Debugging and observability

Debugging and observability are important production features that allow the ops team to continuously monitor the applications and provide useful feedback to the dev team. It is an area that is currently lacking in the Wasm landscape. We anticipate it to grow as Wasm are increasingly deployed in production. 

Artifacts

Artifact repositories are important elements in the landscape. They provide centralized and always-available locations to store, discover, verify, download, track Wasm packages across multiple published versions. They are not only convenience tools but also crucial for software supply chain security. 

Help Us Build The Wasm Landscape

The Wasm landscape was a community effort and as Wasm adoption takes off, the Wasm landscape is also fast evolving. We intend to keep it updated with the latest developments. However, we can only do this with the help of the entire Wasm community.


If you see anything you would like to add or update, please submit a PR! You can refer to this PR to add your project name, logo, website, GitHub repo link, and crunchbase.

+++

WebAssembly 如何构筑云原生的新未来？CNCF 发布 Wasm 生态全景图

本文为译文，译者：Miley Fu, Vivian Hu

原文作者：Chris Aniszczyk、Vivian Hu 、Michael Yuan

原文链接：https://www.cncf.io/blog/2023/09/06/introducing-the-wasm-landscape/

“容器已成为新常态，WebAssembly 是未来。”

—— CNCF 2022 年年度调查主要发现。

WebAssembly(Wasm) 最初是为了在网页浏览器中运行编译的 C/C++ 代码而创建的一个安全沙箱，但它正在服务器端获得越来越多的关注和发展势头。在云端，Wasm 提供了一个轻量、快速、安全、跨语言、跨平台的应用程序运行时，可用于各种由用户提交的工作负载。它正在快速成为云原生技术栈的一个关键部分。

随着 Wasm 在云原生项目、产品和服务中的采用，CNCF 与 Wasm 社区合作创建了一个Wasm 生态全景图，以更好地理解 Wasm 生态的范围。正如最初的云原生全景图帮助勾画了围绕云原生技术的大量生态，我们相信随着生态的发展和增长，Wasm 也需要同样的全景图。

Wasm 全景图 第一版在 WasmCon 会议上发布，包括 11 个类别和 120 个项目或产品，代表总经济价值 594亿美元。 Wasm 全景图分为两大领域：Dev（应用程序开发）和 Ops（应用程序部署）。

应用程序开发

Wasm 应用程序开发需要自己的编程语言和相关工具生态，例如编译器、框架、库、工具和运行时。

编程语言

当开发者创建应用程序时，他们从选择一种编程语言开始！ Wasm 的特点之一是它能够运行用各种不同编程语言编写的应用程序。然而，这并不意味着所有编程语言都是平等的。

事实上，Wasm 全景图中有 4 类编程语言。

编译语言

一等公民是可以直接编译为 Wasm 字节码并在 Wasm 运行时运行而无需任何依赖的语言。 C 、 C++ 、 Zig 和 Rust 都属于这一组。他们生产最快和最小的 Wasm 应用程序。

让我们以 Rust 为例。安装 Rust 语言后，你所需要做的就是添加 wasm32-wasi 目标。

托管(Managed)语言

托管语言仍然是编译语言。但编译器输出需要“托管运行时”才能正常运行。托管运行时最常见的任务是垃圾收集（或 GC）。

对于 Kotlin 和 Dart 这样的语言，Wasm GC 功能就足够了。 WasmEdge、Wasmtime 和 v8 等领先的 Wasm 运行时最近添加了 Wasm GC 支持。

对于 Go 来说，编译器将必要的运行时二进制文件嵌入到编译后的 Wasm 字节码中。这增加了 Wasm 应用程序的大小，但仍然提供了良好的开发者体验。

对于复杂的托管语言，例如 Java 和 .Net （例如C#），我们需要将它们的托管运行时（例如 JVM）与 Wasm 中的字节码应用程序一起编译和运行。这通常是一种不轻量的方法。

脚本语言

JavaScript、Ruby、PHP 和 Python 等脚本语言也可以在 Wasm 中运行。这里的方法是将脚本语言解释器（通常用 C 编写）编译为 Wasm。然后基于 Wasm 的解释器程序就可以执行脚本了。

例如， VMware Labs 的 **WebAssembly Laungage Runtimes 项目**已将 Python 和 PHP 解释器移植到 Wasm。

WasmEdge QuickJS 项目提供了一个 JavaScript 解释器以及一个支持 JavaScript 中的 node.js API 的 Wasm 库。

来源： WasmEdge QuickJS 文档

“编译为 Wasm”的语言

最后但并非最不重要的是针对 Wasm 目标进行优化的新一代编译语言。他们仍处于非常早期的阶段。但如果做得好，他们有潜力成为 Wasm 全景图中真正的一等公民。

Moonbit 和 Grain 是该类别中的两个领先示例。它们采用 Go 和 Rust 中的现代语言功能进行设计，并针对高效的 Wasm 编译和执行进行了优化。

Moonbit 虽然还处于早期阶段，但它配备了从动态代码补全到在线 IDE 的一整套工具。

运行时

一旦源代码被编译成 Wasm 字节码，你将需要 Wasm 运行时来执行它们。 Wasm 运行时提供了通常与 Wasm 相关的所有功能和优点，例如沙箱安全性、速度和跨平台可移植性。它们位于全景图的中心。

在这个云原生 Wasm 全景图中，我们将重点关注服务器端流行的 Wasm 运行时。我们有**WasmEdge **（CNCF 沙箱）、 **Wasmtime/lucet **、 **Wamr、** **WAVM **、**Wasmer、** **wasm3 **、 **Lunatic **、 **wazero **、 **Wasmer**和**V8 **。

应用框架

Wasm 运行时类似于操作系统。库和框架为应用程序开发者提供了所需的高级且易于使用的组件。

WasmEdge 运行时的独特之处在于它支持超出 Wasm 标准的高级 POSIX API，它允许许多流行的 Rust 和 JS 应用程序框架，例如 tokio、hyper、reqwest、warp、node.js，以及 MySQL / Postgres / Redis / Kafka /ElasticSearch 客户端库，在 WasmEdge 中运行。然而，对于所有其他 Wasm 运行时，应用程序框架需要提供基本功能，例如 HTTP / HTTPS 网络和数据库访问。

在全景图的这部分中，我们涵盖了 Spin、WasmCloud （CNCF 沙箱）、SpiderLightning、 WasmEdge plug-ins、Dapr SDK for WasmEdge、Homestar、Ambient、WASIX、Extism、Timecraft、vscode-wasm 和 WasmEx 。

边缘/裸金属

Wasm 的一个关键特性是跨平台可移植性，这意味着能够跨不同操作系统和 CPU 架构执行相同的字节码应用程序。在 JVM 时代，操作系统仅限于类 Unix 系统（例如Linux）、Windows 和 MacOS。然而，Wasm 可以在边缘和物联网计算中常用的非传统系统上运行。

Docker 和 Linux 容器从来都不是跨平台的。例如，容器镜像必须与主机 CPU 匹配。

AI 推理

随着人工智能工作负载在云数据中心越来越受欢迎，Wasm 越来越多地用作重量级、复杂且缓慢的 Python 堆栈的替代方案。 WASI NN 规范定义了 Wasm 运行时应如何与本机 AI/ML 库（例如 PyTorch 和 TensorFlow）交互，以使用 Rust 等高性能语言进行 AI 推理。

Wasmtime、WasmEdge 和 WAMR 是支持 WASI NN 的 Wasm 运行时。

例如，WasmEdge 运行时支持 OpenVINO 、 Pytorch 、 Tensorflow 、 TensorFlow Lite 和 MMGL/Llama2 作为推理后端，以及 OpenCV 、 ffmpeg 作为预处理器或后处理器。同时也支持 mediapipe、document AI、llama2等多种模型。

嵌入式函数

Wasm 可以安全地执行用户定义或社区贡献的代码作为软件产品中的嵌入式函数（或插件）。

在 Wasm 全景图的这一部分中，我们展示了选择并集成 Wasm 作为插件机制的软件产品。最长的类别是数据库和数据流应用程序，其中的 Wasm 用于执行用户定义函数（UDF）。

Libsql、OpenGauss 和 Singlestore 等数据库以及 Open Policy Agent、InfinyOn、YoMo、eKuiper 和 Redpanda 等消息队列正在使用 Wasm 来执行 UDF。 Envoy、Istio、APISIX、KubeWarden 和 NGINX 等流量代理正在使用 Wasm 在数据平面中执行自定义逻辑。 OpenFunction 和 Knative 等 FaaS 平台允许将 Wasm 函数嵌入到 Kubernetes Pod 中。

工具链

最后，开发者依靠工具将语言、框架、库和运行时拼凑成工作应用程序。工具链的成熟度是衡量整个开发者生态成熟度的重要指标。在 Wasm 全景图，我们介绍了用于构建 Wasm 应用程序的重要工具。

应用程序部署

创建 Wasm 应用程序后，下一步是在生产中部署和扩展它。云原生全景图中有大量的工具、框架和服务来管理应用程序部署。其中许多都集成了 Wasm 支持。

编排与管理

Wasm 容器可以通过 Docker、containerd 和 Kubernetes 等现有容器工具进行无缝管理。有两种方法可以将 Wasm 应用程序作为“容器”进行管理。这两种方法都可以让你构建并行运行 Linux 容器和 Wasm 容器的 Kubernetes 集群。

方法#1是在容器管理堆栈的基础上使用 OCI 运行时，例如 crun 和 youki 。 crun 根据镜像的目标操作系统和 CPU 平台检测 OCI 镜像是 wasm 还是 Linux。如果镜像的目标是 wasi/wasm，crun 将绕过 Linux 容器设置过程，只使用 WasmEdge 来运行它。基于crun，我们可以获得整个 Kubernetes 堆栈来运行 Wasm 镜像，包括 CRI-O （CNCF项目）、 containerd（CNCF项目） 、Podman、kind、K8s （CNCF项目）、 OpenYurt （CNCF项目）、 SuperEdge （CNCF项目）、 KubeEdge （CNCF 项目）。

方法#2是使用 containerd-shim（例如 runwasi ）在 containerd 中运行 Wasm 应用程序。当 containerd 接收到镜像时，它会检查镜像的目标平台，如果镜像是 wasi/wasm，它会路由到 runwasi 执行，如果镜像是 x86 或 arm，它会路由到 runc。

在 Kubernetes 的基础上，我们还介绍了一些新兴工具来帮助管理生产 Wasm 工作负载。

Kuasar 是另一个支持多种类型沙箱的容器运行时，包括 microVM、Linux 容器、应用程序内核和 WebAssembly 运行时。

Kwasm 是一个 Kubernetes Operator，它为你的 Kubernetes 节点添加了 WebAssembly 支持。它可与基于 Ubuntu/Debian 和 Containerd 的本地和托管云 K8s 发行版配合使用，

container2wasm 是一个容器到 wasm 镜像转换器，可以在 WASM 上运行容器。

托管（Hosted）平台

如果你不想麻烦地运行自己的服务器和 Kubernetes 集群，那么托管平台是将 Wasm 应用程序部署和扩展为服务的绝佳选择。

去中心化平台

基于区块链的智能合约平台是去中心化的云计算网络。你的云应用程序（即智能合约）不是由中心 Operator 运行所有工作负载，而是由网络中的节点执行。由于智能合约不受信任并且必须非常频繁地执行（每台计算机每秒数百次），因此 Wasm 是该应用场景的理想执行引擎。事实上，几乎所有领先的智能合约区块链网络都采用了 Wasm。

调试和可观测性

调试和可观测性是重要的生产功能，使运维团队能够持续监控应用程序并向开发团队提供有用的反馈。这是 Wasm 全景图中目前有所缺乏的部分。我们预计这个领域会随着 Wasm 越来越多地部署在生产中而生长壮大。

Artifacts

Artifacts repo 是全景图中的重要元素。它们提供集中且始终可用的位置来存储、发现、验证、下载、跟踪多个已发布版本的 Wasm 包。它们不仅是便利的工具，而且对于软件供应链安全也至关重要。

帮助我们构建 Wasm 全景图

Wasm 全景图是社区的努力，随着 Wasm 采用的兴起，Wasm 全景图也在快速发展。我们打算随时更新最新进展。然而，我们只有在整个 Wasm 社区的帮助下才能做到这一点。
如果有任何想要添加或更新的内容，请提交 PR！可以参考此 PR添加你的项目名称、logo、网站、GitHub repo 链接和 crunchbase。