Any time someone banks, shops, or messages online today, chances are there's a web application doing the work. With increasing demand for web applications, WebAssembly paired with Kubernetes shows promise for making versatile and manageable web apps.
Web applications today benefit from cross-platform convenience; they can run across a myriad of operating systems and devices -- all that matters is the browser. This eases development and deployment cycles because there is no need to install or configure anything outside the local browser.
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.