Learn more about WebAssembly's use within service mesh data planes inThe Enterprise Path to Service Mesh Archictures (2nd Edition) - free book and excellent resource for anyone looking to understand WASM filters, Lua scripts, and other options available for extending the data plane.

WebAssembly, or WASM, is an open standard that defines a binary format for executable programs. Through WebAssembly System Interface (WASI), it also defines interfaces for facilitating interaction with host environments. The initial focus of these host environments was browsers and large web applications with the intention of securely running programs to improve performance. As an open standard, WASM is maintained by the W3C, and has been adopted by all modern browsers. After HTML, CSS, and Javascript, WebAssembly is the fourth language to natively run in web browsers.

WASM support is coming to Envoy through the efforts of Google, and Envoy maintainers embedding Google's open source high-performance JavaScript and WebAssembly engine, V8, into Envoy. Through the WebAssembly System Interface, Envoy exposes an Application Binary Interface (ABI) to WASM modules, so that they can operate as Envoy filters. The way WASI works is straight-forward. You write your application in your favourite languages like Rust, C or C++. Then, build and compile them into a WebAssembly binary targeting the host environment. The generated binary requires the WebAssembly runtime to provide the necessary interfaces to system calls for the binary to execute. Conceptually, this is similar to JVM. If you have a JVM installed then you can run any Java-like languages on it. Similarly, with a runtime, you can run the WebAssembly binary.

Envoy Proxy WASM SDK

Envoy Proxy runs WASM filters inside a stack-based virtual machine, thus the filter’s memory is isolated from the host environment. All interactions between the embedding host (Envoy Proxy) and the WASM filter are realized through functions and callbacks provided by the Envoy Proxy WASM SDK. The Envoy Proxy WASM SDK has implementations in various programming languages like:

  • C++
  • Rust
  • AssemblyScript
  • Go

Let's examine how to write WASM filters for Envoy using the Rust Envoy Proxy WASM SDK. While we will not delve into all the details of the Application Binary Interface (ABI) for Envoy Proxy's WASM SDK, we will touch on a few of the things that are necessary to grasp the basics of writing WASM filters for Envoy.

Our filter implementation must be derived from the following two classes.

Envoy provides the ability to integrate additional filters by either:

  • Natively by incorporating your custom filter into Envoy’s C++ source code and compiling a new Envoy version. The drawback being that you need to maintain your own version of Envoy, while the benefit being that of your custom filter running at native speed.
  • Via WASM by incorporating your custom filter as a WebAssembly binary writing in C++, Rust, AssemblyScript or Go. The drawback being that WASM-based filters incur some overhead, while the benefit being that you can dynamically load and reload WASM-based filters in Envoy at runtime.

Envoy configuration is initialized via bootstrap on startup. Envoy’s xDS APIs allow configuration to be loaded and reloaded dynamically during runtime. Envoy configuration has different sections (e.g. LDS which is for configuring Listeners and CDS which is for configuring clusters). Each of the sections can configure WASM plugins (programs).

Related Resources

Layer5, the service mesh company

Representing the largest collection of service meshes and their maintainers in the world, Layer5 is the service mesh company. Creator and maintainer of service mesh standards. Maker of Meshery, the service mesh management plane.