WebAssembly vs. Kubernetes: Understand the relationship

WebAssembly basics

Wasm is a form of low-level assembly language that can compile various common programming languages. For example, a program written in C, C++ or Rust can be compiled into a Wasm binary module. Wasm is intended to coexist with traditional web application languages like JavaScript, and both work together in the browser.

As with any assembly language, the actual resulting machine code is close to the native computing hardware. This results in fast and efficient program performance, which enables Wasm applications to be more complex and demanding of system resources than JavaScript applications. This gives developers options for more creative and sophisticated web application development than JavaScript alone.

Wasm programs run in supported browsers, which are most major web browsers today, and can run in other runtimes through a modular interface called WebAssembly System Interface (or WASI), which is noted for its security and portability across operating systems. There are also other WASI runtimes like Wasmtime and WasmEdge.

Wasm vs. Docker

At a high level, Wasm and Docker have a similar goal. Both aim to provide a portable module that can be loaded and executed in any hardware-compatible environment. Docker does this by establishing a snapshot of system files and dependencies, as well as arranging those elements into layers which can then load and run within a container engine/runtime such as Docker.

The challenge for Docker and its containers is compatibility. A Docker image file, with all its components and dependencies, must match the underlying system or hardware architecture for which it's intended (such as Intel, AMD or ARM). Otherwise, the container will run incorrectly, if it runs at all.

Wasm adopts a simpler approach than Docker. A program in C, C++, Rust, Go or another language is compiled to an executable binary which will run on a suitable Wasm runtime. Browsers contain a suitable native runtime and do not need another outside runtime. However, there are dozens of prospective Wasm runtimes that can be used to load and run Wasm modules for non-browser applications, such as server-side or back-end workloads.

The key is that Wasm binaries don't rely on host OS or processor architectures like Docker containers. Instead, all the resources the Wasm module needs (such as environment variables and system resources) are provisioned to the Wasm module by the runtime through the WASI standard. This means Wasm modules are not coupled to the OS or underlying computer. It's an ideal mechanism for highly portable web-based application development.

Kubernetes vs. Wasm vs. Docker

The emergence of container technology using platforms such as Docker created management problems for developers and operations staff. Containers are small, spawn quickly and exist for only very short periods of time, making it extremely difficult to manually deploy and manage complex applications composed with containers.

Kubernetes arose as a response to these challenges, providing a versatile and powerful platform to automate, orchestrate and manage container-based environments. Kubernetes has garnered a strong industry acceptance and has become the standard for enterprise container management. Its features include auto-scaling, lifecycle management, declarative system state management, resilience, self-healing, persistent storage for containers and load balancing.

Docker containers on Kubernetes

Kubernetes and Docker are not directly related. In fact, Docker has its own orchestration platform called Docker Swarm -- but Kubernetes' popularity makes it common to use in tandem with Docker. While Docker is the engine that operates containers, Kubernetes is the platform that helps organizations manage countless containers as they deploy, proliferate and then cease to exist.

A typical container deployment in Kubernetes uses containerd as a main management runtime to manage container tasks such as creating, starting, stopping and removing containers. However, runc is the actual low-level container runtime that performs the events managed by containerd. An additional shim process is usually added to interface the low-level runtime to containerd.

Wasm modules on Kubernetes

Wasm shares the same management problems posed by traditional containers. It's easy to load one or two Wasm modules into a browser, but handling hundreds or even thousands of back-end Wasm modules across enterprise servers can be another problem entirely. Therefore, larger numbers of modules need some broader form of orchestration and management. Although Wasm has no native orchestration platform, Kubernetes can serve the role in a Wasm environment.

To operate Wasm modules for containers, it's necessary to replace the low-level runtime along with the shim that interfaces the low-level runtime to the containerd management runtime in Kubernetes.

One of the most common shim replacements is called runwasi, which can be installed between containerd and low-level Wasm runtimes. There are also numerous low-level Wasm runtimes including wasmtime, WasmEdge and runtime-X.

At this point, Wasm modules can be loaded in place of containers. This replacement system works because the shims, low-level runtimes and actual workloads are entirely irrelevant to Kubernetes, which schedules tasks and does not distinguish between OCI-compliant containers and Wasm workloads.

The actual code needed to perform these replacements and configure Kubernetes to run Wasm workloads can routinely be found in WebAssembly and the documentation for Wasm runtimes.

Tradeoffs of Wasm on Kubernetes

While using Kubernetes as an orchestration platform for Wasm applications helps the adoption and growth of Wasm, Wasm is not intended to displace Docker containers. Kubernetes can readily support both containers and Wasm workloads simultaneously, allowing great versatility in future application design and deployment options.

Wasm and its presence on Kubernetes offers many benefits:

• Light, compact and highly portable code.
• High performance for complex applications.
• Easy integration of Wasm modules with Kubernetes.
• Rich ecosystem of Wasm runtimes.
• No changes to Kubernetes, which can continue to support traditional containers simultaneously.

However, running Wasm on Kubernetes can pose some potential drawbacks:

• Additional learning curve and more conceptual load for developers and operations staff.
• Large number of Wasm runtimes can vary in purpose, quality and vendor support.
• More tools needed to compile and test Wasm modules can further complicate CI/CD toolchains.
• Overall stability of Wasm in Kubernetes isn't guaranteed.

Running Wasm workloads on Kubernetes is currently an experimental initiative. The stability and performance of resulting operational configurations are not necessarily suitable for major production deployments at this time. However, the potential for running Wasm workloads along with Docker containers through Kubernetes provides developers with compelling opportunities for innovation. Experimentation and proof-of-concept projects can capitalize on these new and evolving development efforts.