What is WebAssembly (Wasm) and what is the relationship between Wasm and Docker?
Due to the length of the article, we will divide it into two articles, the first one will focus on explaining concepts such as what Wasm is and how Wasm is related to Docker. The next article will be more practical and will use PHP as an example to lead you to practice Docker + Wasm.
Recently, Docker announced support for WebAssembly [4] in partnership with WasmEdge [3].
This article will explain what WebAssembly (Wasm) is, why it is relevant to the Docker ecosystem, and provide some hands-on examples for you to try out. We assume that you are already familiar with Docker tools. We will use the work we did on PHP’s WebAssembly port [5] to demonstrate how to build a PHP interpreter, package it as part of an OCI image, and run it using Docker.
Please note that this article focuses on hands-on experience rather than discussing technical details.
What is WebAssembly? Why choose it?
This section is a basic introduction to WebAssembly. For those of you already familiar with Wasm, you can quickly revisit it, and the next article will cover more practices.
What is WebAssembly?
WebAssembly is an open standard that defines a binary instruction format that supports the creation of portable binary executables from different source languages. These binaries can be run in a variety of environments. It has its origins in the Web and is supported by all major browsers.
How does Wasm work in the browser?
The browser engine integrates a Wasm virtual machine, often called the Wasm runtime, that can run Wasm binary instructions. A compiler toolchain (such as Emscripten) can compile the source code into a Wasm target. This allows existing applications to be ported to the browser and communicate directly with JS code running in the client web application.
These technologies enable traditional desktop applications to run in a browser. Now they can run on any device with a browser installed. Some famous examples include Google Earth [6] and the Open CV [7] library for computer vision.
How does Wasm run on a server?
In addition to browsers, there are Wasm runtimes that can run outside the browser, including legacy operating systems such as Linux, Windows, and macOS. Because they cannot rely on available JavaScript engines, they use a different interface to communicate with the outside world, such as WASI (WebAssembly System Interface [8]). These runtimes allow Wasm applications to interact with their host systems in a manner similar (but not identical) to POSIX. projects such as the WASI SDK and wasi-libc help people compile existing POSIX-compatible applications into WebAssembly.
You only have to compile the application into a Wasm module once, and then this same binary can be run anywhere.
What’s so great about Wasm?
The following features make Wasm shine in the browser and make it advantageous for server-side development.
Openness – It is a widely adopted standard in the industry. In contrast to the browser battles of the past, companies are actively working together to standardize on WASI and WebAssembly applications.
Fast – It can provide native-like speed with most runtime JIT/AOT capabilities. Unlike starting a VM or launching a container, there is no cold start.
Secure – By default, the Wasm runtime is sandboxed, allowing secure access to memory. The capability-based model ensures that Wasm applications can only access content that is explicitly allowed. The software supply chain is more secure.
Portable – Several major Wasm runtimes support most CPUs (x86, ARM, RISC-V) and most operating systems, including Linux, Windows, macOS, Android, ESXi, and even non-Posix operating systems.
Efficient – minimal memory footprint and lowest CPU threshold to run Wasm applications.
Multi-language support – more than 40 programming languages can be compiled into Wasm, with a modern, constantly improving tool chain.
What’s next in server platform development?
Perhaps you have already read this quote by Solomon Hykes (one of the founders of Docker) [9].
Wasm is that important. Server-side WebAssembly is the future of computing.
In fact, WASM + WASI does seem to be the next step in server-side software infrastructure development.
In the earliest days, we had physical hardware to work with. We would carefully install operating systems and applications for each server in the server room, and maintain them one by one.
Then with the adoption of VM, pioneered by VMware, everything became easier. People could copy, clone and move VMs across hardware machines. But this still required installing the operating system and applications in the VM.
Then came containers, promoted by Docker, which made it easier to run application configurations in a minimally packaged context without affecting any other applications on the host OS. However, applications still need to be distributed bundled with their runtime and necessary libraries. The security boundary is provided by the Linux kernel.
Now with WebAssembly, its technical features and portability make it possible to distribute applications without ship OS-level dependencies and to operate under strict security constraints.
Given all this, developers often see WebAssembly as a “successor” to containers and a natural next step for infrastructure deployment.
However, another way to look at WebAssembly is as an alternative “back-end” option to Docker tools. This can be done using the same command line tools and workflows, replacing the Linux container, using a WebAssembly-based container, and other equivalent things. The rest of this article explores this concept, which is what the title refers to as “Docker without containers”.
How does Wasm work with Docker?
Docker Desktop now includes support for WebAssembly. This is done through the containerd shim, which can run Wasm applications using the Wasm runtime called WasmEdge[10]. This means that it is now possible to run Wasm applications in the WasmEdge runtime (emulating a container) instead of running a separate process of binaries in a container image with a typical Windows or Linux container.
As a result, the container image does not need to contain the operating system or runtime context of the running application – a single Wasm binary is sufficient.
This is explained in detail in Docker’s Wasm Technical Preview article [11].
What is WasmEdge?
WasmEdge[12] is a high-performance WebAssembly runtime.
It is open source and belongs to the CNCF [13].
Supports all major CPU architectures (x86, ARM, RISC-V).
Supports all major operating systems (Linux, Windows, macOS) as well as other operating systems, such as seL4 RTOS, Android.
Optimized for cloud-native and edge applications.
Scalable and supports standard and emerging technologies
AI inference using Tensorflow, OpenVINO, PyTorch
Asynchronous networks for Tokio. Support for microservices, database clients, message queues, and more
Seamless integration with the container ecosystem, Docker, and Kubernetes (as shown in this article!)
What about interpreted languages?
So far, we’ve only mentioned compiled languages like C and Rust that can compile to WebAssembly. for interpreted languages like Python, Ruby, and PHP, the approach is different: their interpreters are written in C and can compile to WebAssembly. this interpreter then compiles to a Wasm that can be used to execute source code files usually ending in .py, .rb, .php, etc. Once compiled to Wasm, any platform with a Wasm runtime will be able to run these interpreted languages, even if the actual interpreter has never been compiled natively for that platform.
Tomorrow we will cover how to compile Wasm with the PHP interpreter, package it into an OCI image, and run the OCI image using Docker Desktop with WasmEdge built in, and we will also cover the differences between traditional containers and Wasm containers.
