A Serverless WebAssembly Runtime for Workflows – Part 1: Motivation

Posted on Sat, Dec 18, 2021

As the industry strives to enhance cloud infrastructure to increase resource efficiency and security, it starts to look beyond what can be done with traditional means of virtualization. Beyond the horizon, there is WebAssembly – a technology with widespread adoption in all major web browsers. WebAssembly is now becoming a hot topic in the Cloud Native ecosystem, too. The organizers of KubeCon + CloudNativeCon Europe 2022 have dedicated a full-day event just to WebAssembly.

This post will explain the motivation for using WebAssembly for running serverless workloads. I'll take a brief look at what WebAssembly is and which tools currently exist. Finally, I'll describe my proposal for an architecture for running WebAssembly-based serverless workloads.

Introduction to WebAssembly & its use cases

At its essence, WebAssembly (WASM) is an open standard for cross-platform executables. The spirit is comparable to Java bytecode, but the WebAssembly standard is a lot simpler in that it doesn't define system-level APIs or even complex data types. The WASM initiative was driven by browser vendors, making it the only executable format for web browsers since the advent of JavaScript in 1995. WASM is designed to provide near-native execution performance. This is combined with a very well thought-of isolation concept – its main use case is to run semi-trusted code on arbitrary web pages, after all.

The bare-bones nature of the WASM standard is a blessing and a curse. On the one hand it makes WASM as versatile as a standard as it is and is the reason why it is applicable for running code on web browsers and the cloud alike. The downside is the lack of common programming APIs: e.g., the WebAssembly standard does not specify how to open and read a file or open a network connection. The WebAssembly System Interface (WASI) project contributes this common denominator for the most important use cases to communicate with the outside world from a WASM module. Note that WASI is still evolving: as of writing this post, you can read and write a file, but not use sockets for network communication, for example.

⚙️ Modern Runtimes for Cloud Computing Workloads

  1. Hypervisor VM and microVMs (e.g., AWS Firecracker)
  2. Application Containers (e.g., Docker)
  3. High-level language VMs (e.g., JVM, Python, V8, WebAssembly)

This combination of performance with a high level of isolation drives the interest of WASM in the cloud-native community. The same way that Docker containers superseded Virtual Machines as the most popular means to separate tenants in shared computing environments, WASM could present the next step for using hardware resources even more economically. This not only applies to the cloud and edge. For constrained devices, such as those in the Internet of Things (IoT), WASM could be a breakthrough for application isolation, since even the comparably low overhead of Docker containers presents a challenge for such devices.

WASM browser support is good, but for which headless use cases has it been used so far? In my research, I came across a few:

Below is a list of useful learning resources on WebAssembly:

A Serverless WebAssembly Runtime for Cloud-Native Workflow Engines

For my master thesis in IT-Systems Engineering at the Hasso-Plattner-Institute in Potsdam, I want to bring the efficiency & security benefits of WebAssembly to the CNCF ecosystem in the form of a WASM runtime for serverless workloads on Kubernetes. The primary use case are workflow tasks in a distributed workflow orchestrator like Kubernetes and Argo Workflows.

The main pillars for this project are derived straight-forward from the working title:

I already explained the benefits of WebAssembly modules compared to Docker containers briefly. WASM modules can be instantiated in a matter of milliseconds and are a lot smaller than container images. Moreover, the runtime improves cluster resource efficiency because it removes both the container management and runtime overhead. It is also a promising approach to run untrusted code in a distributed setting as the WASM sandbox can enforce strong security guarantees.

📄 Find out more on the thesis topic in my topic proposal document:

Master Thesis WebAssembly - Topic Proposal.pdf316.3KB

Outlook: WebAssembly Modules in Argo Workflows

The graphic shown below is an example for a workflow with three steps. Assume this workflow is to be executed in a Kubernetes cluster. For each workflow step (1, 2a, 2b, and 3) there would normally be a Pod with one or more containers. One of the containers is implements the custom logic and is supplied by the workflow author. For this setting, I will replace containers with WASM modules. Both will be interoperable such that they can be combined seamlessly.

I will use Argo Workflows as a showcase for the serverless WASM runtime. The integration supports the same configuration for input and output parameters and artifacts. It is fault-tolerant and allows workflow steps to be debugged with the same tools in the Argo Workflows UI and Kubernetes resources. See the screenshot on the right to get a picture of how this will look like in Argo Workflows. Take a look at this snippet from an Argo Workflow definition. This is the existing implementation using a Docker container image:

- name: split_pages
  inputs:
    artifacts:
    - name: doc
      path: /tmp/doc
  script:
    image: ghcr.io/shark/letterflow-imagick
    command: ['/tmp/doc','/tmp/pages']
  outputs:
    artifacts:
    - name: pages
      path: /tmp/pages

Next, this is how a WASM module in a workflow step template can be used:

- name: split_pages
  inputs:
    artifacts:
    - name: doc
      path: /tmp/doc
  wasm: # <- the difference is here
    # references WASM module in an OCI registry
    image: ghcr.io/shark/letterflow-imagick-wasm
    command: ['/tmp/doc','/tmp/pages']
  outputs:
    artifacts:
    - name: pages
      path: /tmp/pages

The wasm: key is the only necessary change from an end-user perspective. The implementation point of view is more complex, of course. Part 2 will cover the system architecture for the serverless WASM runtime.