Years ago when I heard WebAssembly (Wasm) for the first time, I was intrigued. The fact that I can write code in Rust or C++ and have it running in a browser blew my mind immediately. Porting an existing browser-side computation from JS code to Rust results in an increased performance. Needless to say, I have high expectations from this technology. Sadly, due to personal circumstances, I haven’t had much time and opportunity to explore this technology further.
That is, until last week.
I attended a Cloud Native Wasm Day keynote by my fellow Tetrand, Takaya Saeki’s, which was an astonishing talk about current applications of Wasm, especially in the service mesh space. (Tetrate was a diamond sponsor of Wasm Day, which was a Zero Day KubeCon EU 2021 event).
“Wait? What? Service Mesh? I thought Wasm was only for browser!”
Yes– that was how much I lagged behind the Wasm train. So, his talk was very inspiring, in the sense that it gave me a quick introduction to the current state of Wasm outside of the browser, specifically, as an enabler to create Envoy extension.
Now, what Wasm brings to the table is the ability to create portable code, meaning that code written in different languages can be run in various platforms, with Wasm providing the execution environment. And not only that, thanks to its characteristics, it offers the following attributes and benefits (among others outlined in its design goals) as it’s:
- Safe: safely run untrusted codes in a sandbox
- Open: interop programs with their environment in a universal manner
- Portable: architecture-independent
- Polyglot: thanks to the ability to be compiled from many language
These design features address shortcomings from previous efforts such as NaCI, Seccomp, Native Library Formats or languages such as Java or Lua. All, while keeping the previously mentioned speed factor as a target.
These benefits make Wasm an ideal candidate for compilation target for software running, even outside of the browser. This is realized through its Embedding Interface which subsequently gives birth to a variety of actual interfaces for Wasm. 2 cases that Takaya mentioned are WASI and the Proxy-Wasm Embedded Interface. Prior to his session, I attended Lin Clark’s talk which explains WASI in deeper detail. The takeaway that I took is that there’s a strong push from folks at Bytecode Alliance to get important primitives ready that would improve security and performance for applications running in a variety of cloud native systems. (Something that I’m pretty sure, would benefit the ecosystem).
On the other hand, the Proxy-Wasm project has provided the community with C++ and Rust SDKs that can be used to extend Envoy proxy capabilities with a popular use case that includes extending security capabilities of the proxy. This is done by using Envoy as a reference implementation, while Wasm provides the extensibility interface. By using the method, an SDK user can securely manipulate proxy traffic to add various capabilities– all while maintaining the safe, isolated environments and language independent and dynamic load of extensions that Wasm enables.
Looking at a higher level, this opens up a possibility to create a secure extension for an application running in an Istio- and Envoy-powered service mesh environment. By utilizing Proxy-Wasm, someone can start writing an Envoy extension– to create a custom AuthN or AuthZ process, for example, or a custom logger for a specific use case. This ability to create a secure extension will play a significant role in the future of service mesh adoption in many organizations.
I don’t know about you, but this has already whetted my appetite. I can’t wait to relearn Wasm and use it for Envoy-related experiments!
Read more on Wasm:
- How to get started with Envoy extensions: Wasm and GetEnvoy (article/video)
- A brief history of WebAssembly (video)
- Effortless Envoy and WASM with GetEnvoy
Technical resources: