Solo.io Promises Docker-Like Experience with a WebAssembly Hub for Envoy Extensions
Solo.io, the company behind API gateway Gloo, has introduced WebAssembly Hub, with the aim to simplify the process of building, deploying, sharing, and discovering WebAssembly (WASM) extensions for the Envoy proxy. The launch follows last month’s introduction of Autopilot, an open-source operator framework for building workflows on top of a service mesh, which focuses on the control plane. With WebAssembly Hub, the company provides a way to more easily extend the data plane by simplifying the building and maintaining of Envoy proxy filters.
Solo.io CEO and founder Idit Levine explained in an interview that the service mesh is just a tool and that by providing a way to more easily extend the Envoy proxy, which sits at the core of many service meshes, it becomes easier to use that tool in numerous ways.
“Service mesh is just a platform, right? It doesn’t matter what pain it’s solving. Today, it’s solving routing, observability, and security, but that’s just the use case,” said Levine. “There’s way more that we can do with it. It’s like an iPhone or Android — who said that you can only talk on the phone? You can actually do way more on the phone, and you do this by extending it with apps.”
In a blog post introducing WebAssembly Hub, Levine writes that “The next step in the evolution of Envoy involves simplifying the process of developing extensions and loading them to the proxy at runtime. This is why we’re excited about WebAssembly.”
The Envoy proxy sits at the heart of a number of popular service meshes, including Istio, AWS App Mesh, and Consul Connect, and extending Envoy is entirely possible without WebAssembly Hub, Levine explained, but made complex by two simple factors. First, you need to write the extension in C++, which can be complex in its own right, but then you also need to recompile Envoy along with your new extension. This means that you will be running a non-standard version of Envoy and that if your extension crashes, it will take Envoy with it.
By instead using WebAssembly to extend Envoy, developers can write new filters in the language of their choice, including Rust, Go, C/C++, and other non-garbage collecting languages, and WebAssembly provides the security of a sandboxed environment, as well as near-native speeds. Since the filter is not built as part of the core Envoy proxy, it can be added to a running instance without interruption, and the sandboxed environment now prevents it from taking Envoy with it if it crashes.
WebAssembly Hub, meanwhile, promises to help developers build WebAssembly Envoy extensions with a single command, publish them to a single location for discovery, and provide needed configuration updates for adding extensions to Envoy, Istio, Gloo and any other Envoy-based products that support WASM. Levine says that she took inspiration from Docker and what it did for containers, making them easy to build and deploy, and that she sees a similar future for WebAssembly Hub.
“I’m very excited about the future of service mesh, as well as web assembly,” said Levine. “I think it’s as transformational as what Docker did back in the day with containers.”
At launch, WebAssembly Hub comes with just a few extensions, such as a metrics extension, but some potential use cases for Envoy extensions include enhancing security with a Web Application Firewall or, coming soon, a filter for authenticating with Amazon Web Services to call Lambda serverless functions.
Amazon Web Services is a sponsor of The New Stack.
Feature image by Peter H from Pixabay.