WASM your way to the cloud

At its core, WebAssembly (WASM) provides a lightweight, portable, and secure binary application format. WASM, which is best known for its use within browsers, runs across platforms and is an evolution in the way developers create and deploy applications. Computing has evolved from bare-metal to virtual machines and more recently into the popularized containerized format that runs on bare-metal or virtual machines. Containers are key to enabling cloud native architectures that use Kubernetes and like containers, WASM aims to provide better portability, performance, and security for the way organizations build and run applications today.

Rather than supplying a deep dive into WASM, the purpose of this article is to illustrate the legitimacy of WASM as a cloud-native technology for developers and how organizations should consider it as another tool alongside containers and Kubernetes. (if you find that you need a bit more on WASM, I suggest checking out the official webassembly page or the webassembly guide.)

WebAssembly (WASM) which was originally designed around 2015 and officially released in 2017, did not start becoming more mainstream until 2019. If you don’t recognize these years as being significant in the cloud-native timeline, consider that Kubernetes version 1.0 was released in July 2015. Kubernetes quickly gained popularity, dominating what application architects and infrastructure experts would consider the next generation of how organizations develop, build, and deploy applications. With Kubernetes and containerization taking center stage from 2015 on, WASM may have found itself in the shadows as a cloud native application format. Recently, cloud native conversations around WASM have increased along with its associated potential and current use cases. The same way we think of VMs to bare-metal and containers to VMs, we should now consider cloud native WASM as a potential “third wave” of computing (as Nigel Poulton portrays it). 

What is WASM? 

WASM is best known for its role in the web browser rather than the server side and here is why. There are a number of ways we could define WASM, however the best way I have heard it described was as a compiler target. Languages such as C++ or Java need to run through a compiler to spit out a program for a specific compute target, however, WASM is a platform independent target, so the same ".wasm” binary application can run across platforms (Web Browsers, MacOS, ARM, Window). This is one of the reasons WASM is so attractive along with the fact that WASM applications are often small and portable. For the browser, this also allows front-end developers to write browser applications using more languages beyond JavaScript.  As of 2019, all major browsers started to support the WASM runtime, and this meant front-end developers could start to optimize their front-end code and expand the flexibility of how they write applications. This original design use case took off and is the reason we usually hear about WASM in the browser context. However, the use of WASM on the server (instead of the browser) is gaining traction. 

The benefits of WASM

Like containers, WASM applications support a polyglot of languages, are fast and lightweight, provide a secure sandboxed environment and are portable running across different platforms and architectures. These benefits sound almost identical to those we ascribe to containers and microservices. Anecdotally, this industry loves more flexibility for how applications are built and deployed. Portability and speed are often key indicators (along with security) of technology that organizations latch onto. WASM is lightweight and fast because it is compiled and delivered as a small binary format and compared to its human readable, interpreted predecessor JavaScript, this can be a significant difference. 

WASM benefits such as portability, security and performance for the browser are also benefits to WASMs use on the server, but what use cases specifically? We know from how containers enable portability that portability enables application mobility which allows applications to easily ship and run from one provider or platform to another. Lightweight properties also make it ideal for architectures such as Serverless, microservices, edge and IoT since compute resources such as CPU and memory are often limited in these environments. Yes, it is true that containers also play a role in serverless and edge, however we can think of WASM as another tool or potential enhancement to how things have already been done.

WASM for cloud 

In the cloud-native context, we are often working at the infrastructure layer and focused on how applications are built and deployed onto a server somewhere. With containers, this often surfaces as a conversation about how applications use build tools to create a container image and then the container image is uploaded into an image registry and a container orchestration tools like Kubernetes pulls the image and runs the application at scale. Containers are OS-based, meaning they can share operating system libraries and kernel but still have a root filesystem with specific packages for the application. By avoiding the VM’s need to use a separate kernel and operating system, containers gained a leg up. However, container images still need specific operating systems and architectures, e.g., an application image built for Linux must still be deployed on Linux. There are exceptions to this rule, such as using Windows Subsystems of Linux (WSL) however its less commonly used outside of a development environment.

WASM can help free the tether to the specific architectures and allow applications to run on Windows or Linux regardless of where it was built. The result is a more portable application that is often smaller and lightweight for use in serverless, IoT and others mentioned in the cloud native context. 

WASM on the Server

There are various efforts and integrations today that allow WASM applications to run on the server. They include Runwasi, WebAssembly Systems Interface, wasmtime runtime for the server, and in the case of the edge there is wasmedge. Double clicking on runwasi, the project allows containerd (“container-dee") to manage the lifecycle of WASM applications via the Kubelet on a Kubernetes worker node much like it does for containers via runc. In short, runwasi enabled Kubernetes to run WASM applications on worker nodes and will help fast track those who are already familiar with cloud-native container workflows. While there have been other efforts such as krustlet, runwasi seems to have momentum within the cloud-native community and is expanding support and use cases. Take for example how Microsoft Azure Kubernetes Service (AKS) is offering WASM node pools using continerd shims via runwasi on the wasmtime runtime. There is also a desktop use case where Docker Desktop uses the runwasi WasmEdge shim. In these scenarios a WASM applications are often built and published using a container image. This might seem like an unneeded extra step, however, the ability for developers to use tooling they are already familiar with should increase adoption for this use case.

Conclusion 

WASM is gaining traction beyond browsers, however, to truly succeed, WASM must evolve to fully support how enterprises develop, build, and run applications. It’s important to remember that in WASM’s current state that it is not a container replacement, nor does it aim to run what's in your container images. WASM is also not designed to run larger workloads such as enterprise databases with attached volumes. Current adoption of WASM on the server is aimed at environments that have the most to gain using the benefits of WASM applications size and performance such as Edge, Serverless, Functions as a Service and Internet of Things. While it may be early days for cloud native WASM, I hope I have convinced you that this technology deserves a closer look and be evaluated as a potential addition to our cloud native toolbox.