Webinar Recap – Extending Envoy Proxy with WebAssembly

Following the recent announcements for Istio 1.5 and WebAssembly Hub, Idit Levine and Christian Posta hosted a webinar with guest speaker Louis Ryan, Principal Engineer at Google on Istio and Envoy projects.

What is WebAssembly? WebAssembly (Wasm) is a fast, efficient, portable binary instruction format, providing an embeddable and safe execution environment for platform extensions. Wasm extensions, which can be written in multiple languages and executed at a near-native speed, became a popular way to extend web based applications.

In this webinar, speakers from Solo.io and Google cover the community feedback and collaboration that led to support for WebAssembly in upstream Envoy Proxy, Istio service mesh, Gloo and the joint effort to iterate on WebAssembly Hub to ensure the best developer experience in on-boarding, developing, deploying, managing and sharing WebAssembly extensions. Understand how it works, the developer and operator experience, and get a live demo.

Watch the replay here:

Highlights from the Q&A 

What types of extensions will be possible or what is the limit to what WebAssembly can provide in terms of extending Envoy?

Louis Ryan: Given WebAssembly is pretty impressive performance envelope, there’s not a huge amount of limit but there are some probably pragmatic choices that we’ll be making in conjunction with the Envoy community. You know with Envoy being a proxy, probably 90% plus of the traffic that it sees is TCP or HTTP or one of the kind of common HTTP variance. So it probably doesn’t make sense for fundamental common low level protocol handling to move into a WebAssembly module.

But there are a lot of extensions that are already built into Envoy that are not ubiquitously used. If you go and look in the Envoy documentation at the filters that have been added, they’ve added filters for kind of bespoke gRPC protocols. There are a lot of other filters that are built into the main line of Envoy and in talking to the Envoy maintainers, they would like to get out of the business of shipping all these extensions built into their pre-built releases.

One, it makes their lives easier, right, they don’t have to review all of these things. They don’t have to be responsible for them. And it makes Envoy itself more secure because it’s less code, that has to be subject to the amount of scrutiny that Envoy itself is exposed to because of the important role that plays in the network. So I’d expect to see a lot of those kind of non-frequently used filters move out to WebAssembly modules. 

Will there be an SDK for Go made available?

Louis Ryan: We don’t have an immediate timeline for that but Go has pretty good support for WebAssembly already. There are a few limitations to using Go because it is a garbage collected language and you need good runtime support for garbage collection to make this efficient. This is why we focused on C++, Rust and AssemblyScript first because they don’t have that requirement. But there is a variant of Go called TinyGo which is not garbage collected and someone in Japan developed an SDK and got it working with the API so I expect we’ll probably see that come out quite soon. Once WebAssembly picks up garbage collection support (which is on their roadmap), then you’ll see first class support for Go. 

Can I use TinyGo to write filters that can be used in Gloo?

Support for WebAssembly in upstream Envoy means that solutions built with Envoy like Istio and Gloo are also able to take advantage of WebAssembly.

Idit Levine: Yes, whatever is in Envoy we are supporting in Gloo. And as Louis mentioned, there isn’t an SDK yet for TinyGo but once it is supported we will bring it to WebAssembly Hub and it will automatically support Istio, Envoy and Gloo. Today we support AssemblyScript, C++ and Rust is coming very, very soon.

Louis Ryan: So this speaks to the power of WebAssembly. If somebody out there built an SDK for Fortran let’s say, then as soon as that SDK was working in the compiler tool chain, then everything downstream of that would work from WebAssembly Hub all the way to the Envoy runtime and live deployment. So that’s the layering and separation that we talked about here. Check out all the languages supported by WebAssembly here.

If I understand correctly, the filters are set up on pod ingress and can they also be used on pod egress?

Louis Ryan: Yes the API that I showed and Christian kind of showed you in the example was just one piece of the API surface. There are API’s for callbacks effectively that occur that go into the module for the response side processing of HTTP or you know if you’re writing a module that needs to interact with TCP, then you would interact with data passing out on the response side. So both sides of the floor covered

Download the presentation:

[featured_boxes class=”featured-box”]

Learn More

• Try WebAssembly Hub
• Watch the video tutorials
• Get all the WebAssembly news
• Request a meeting with the Solo.io team
• Join the discussion in the community

[/featured_boxes]