Extending the Envoy Proxy With WebAssembly
As the service mesh landscape continues to grow, its underlying technology stack is maturing as well. For example, service mesh advocates are introducing methods to extend Envoy, the open source proxy at the heart of many service meshes.
Pioneered by the teams behind Istio and Gloo, the introduction of WebAssembly into Envoy is enabling engineers to add custom filters, offering new controls and filtering abilities for incoming requests. Standardizing the WebAssembly module format could also retain vendor neutrality in a space with competing agendas.
Having bet big on microservices, API gateways and Envoy-based service mesh, Idit Levine now sees WebAssembly as the next big bet. I recently spoke with Levine, Solo.io founder and CEO, to explore ways to extend Envoy using WebAssembly modules and the growing importance of WebAssembly within this burgeoning field.
Understanding Envoy
To understand WebAssembly, you must first understand Envoy and how it fits into the service mesh framework. Service meshes are typically divided into two main components—a control plane for configuration and a data plane for routing incoming requests to underlying microservices. Envoy sits within the data plane.
In the Envoy-based service mesh architecture, whenever a request comes in, it always goes through Envoy. Envoy is like a filter chain: It takes incoming requests and barrels them through a series of security and operational tasks including authentication, rate limiting, transcoding and routing. This process happens with every request, no matter if it’s inter-mesh, ingress or egress traffic.
Open source with a growing tooling community, Envoy has become a staple for many service meshes including Istio, Consul Connect, Maesh and Kuma. “I don’t think anyone should buy any service mesh or gateway that is not Envoy-based,” says Levine.
Downside: Writing Custom Filters Is Difficult
Yet, Envoy is not perfect. “Envoy is very powerful, but it leaves a lot to wish for,” she notes. The Envoy filter chain is a compelling layer for organizations to add custom capabilities, but Envoy extensibility is not easy.
There are many reasons a team may want to add custom modules to their Envoy implementation. For example, organizations may wish to insert additional business logic, such as metrics, observability, transformation, data loss prevention, compliance validation or other capabilities.
However, writing and adding custom Envoy modules is a bit tedious. You must program in C++ and recompile in Envoy. Ideally, this process should be open to other programming languages. It should also be fast, safe, easy to use and without the need to recompile.
There have been a few efforts to remedy this issue. In Istio, engineers can extend Mixer with an Adapter using Go. Other service meshes have attempted their own custom filter creation.
These efforts move in the right direction, yet they are still “problematic,” Levine says. Solutions are still not language-agnostic and they present ease-of-use issues. “Can we do something better?” she asks. For this, Istio and Solo.io looked to WebAssembly.
Introducing WebAssembly (Wasm) to Envoy
WebAssembly (Wasm for short) is a “binary instruction format for a stack-based virtual machine.” The initiative is maintained by a W3C Community Group, representing a collaboration between all major browsers.
Running Wasm in Envoy involves using a placeholder that developers can insert their extensions into. “We wrote a Wasm custom filter and wrote a Wasm model for the Envoy memory,” Levine says. An Istio blog post details the proposed setup: The proxy extensions are delivered as WebAssembly modules through a level Application Binary Interface (ABI). The WebAssembly for Proxies specification describes the process in detail.
To the layman, that doesn’t sound too approachable. So, to improve developer experience, Solo.io built WebAssembly Hub, a center for sharing and finding Wasm extensions. Like Dockerhub, engineers can browse Wasm extension repositories and deploy them to their Envoy-based service mesh or API gateway.
At the time of writing, WebAssembly Hub hosts 367 repositories and counting, featuring contributions from many community members. Examples include transformation for incoming HTTP requests, appending a header, a Rust filter for additional authentication and many other packages.
To Levine, adding custom Envoy filter modules using Wasm and WebAssembly Hub brings numerous benefits:
- Usable: It only requires high-level code. “Very simple, a lot like Docker.”
- Language-agnostic: Using an Immediate Representative (IR), it doesn’t matter what language you use; it can be translated into any processes.
- Performant: Using low-level mechanics, WebAssembly is quick to execute and resembles a native experience.
- Platform-agnostic: Don’t let its name fool you—you can use Wasm in non-web environments as well. With the introduction of WASI, Wasm can run outside of the web browser in other platforms including iOS, Linux, Mac, Windows and Android.
Levine is also hoping for more industry cooperation through the WebAssembly module format. Enterprise tech has already weathered through vendor wars in the container, orchestration and service mesh areas. “I didn’t want that to happen again—it isn’t healthy for innovation,” she says.
Add Custom Filters With Caution ⚠️
Naturally, there are some possible downsides to extending your proxies with Wasm. One foreseeable issue is degradation, notes Levine. Theoretically, you could assemble an Envoy chain with thousands of custom filters. But, every new module added increases the overall processing time.
If overused, filters could significantly increase latency, which could be disruptive for time-sensitive applications, such as financial or medical industry scenarios. “You just need to be careful about that” and design accordingly, she says.
Wasm use should also depend on your environment. Some scenarios, such as container Wasm in Kubernetes, may not be super beneficial, she adds, reinstating Wasm should be extending proxy technology like Envoy. “That is where it is more useful.”
WebAssembly: The Next Big Bet
The introduction of WebAssembly and WebAssembly Hub presents a streamlined way to add more capabilities to a service mesh’s data plane. There is already big-name support for WebAssembly, including IBM, Google, CNCF and others.
Still, many players are pushing competing agendas in the API gateway and service mesh market ecosystems. Service mesh marketing permeates the cloud discussion, but “customers need technology to back it up,” Levine challenges.
One silver lining is the fact that Wasm isn’t proposing any detrimental change to a company’s existing stack; it’s simply extending functionality where Envoy lacks. Therefore, “it’s not a technology looking for a problem,” she says. “It’s a solution to a problem.”