Envoy Looks to WebAssembly to Extend Microservices Monitoring – InApps Technology 2022

The whole agile move towards autonomous development is great to embrace the individual team and even engineer preference. However, there’s no doubt it makes it difficult for governance. It’s hard to monitor, observe and learn from disparate tooling.

Envoy is an open-source network proxy that runs alongside applications to provide them with common features in a platform-agnostic manner. Envoy contributor and Software Engineer at Tetrate.io, Yaroslav Skopets offered up at  KubeCon + CloudNativeCon Europe, virtual edition, a new Envoy extension as a single interpretation for these many languages.

He started by saying how: “One fundamental purpose of Envoy is its ability to see into every single request received or made by your application.”

Skopets says the next step is to extend Envoy as a way to learn from actual traffic in an efficient, flexible and simple manner. This usually involves natively developing Envoy in C++ and statically linking into the Envoy binary. He says this involves a lot of custom builds of Envoy which leads to “a lot of investment and commitment upfront.”

Skopets suggests instead using WebAssembly, which originated in browsers to enable applications to have what he calls “near-native performance on the web.” In WebAssembly’s low-level code format, he says it enables safe, efficient execution in a sandboxed environment.

What’s interesting in this world of coding language dispersion is that applications can still be developed using a regular programming language — like Rust, AssemblyScript, TinyGo, C, C++ — but then it is compiled into WebAssembly code, which can be deployed and rolled back dynamically.

Skopets offered the example of what he deems a common Envoy user — an organization that has a microservices-based architecture and contract-first or design-first API development that uses RESTful APIs and the OpenAPI specification.

Two common questions to want continual answers for are:

• Is the API specification complete and up to date?
• Do the implementations match the API specifications?

This Envoy extension allows you to validate requests against the API specification and flag up violations via metrics.

“It’s an ad-hoc, experimental, disposable extension,” Skopets said.

This extension uses AssemblyScript, which is a subset of the TypeScript syntax, which is statically typed, garbage collected — the memory is automatically managed — and compiled into WebAssembly code.

However Skopets clarified that “This is not a true JavaScript” because it cannot reuse JavaScript libraries, although it can reuse some TypeScript libraries.

Overall he says TypeScript and AssemblyScript were chosen because he said “We want the complexity of the solution to match the complexity of the problem,” which meant looking for a familiar syntax and NPM toolbox, and something that contributed to a more productive development cycle.

For the Envoy extension model, for every HTTP request handled by Envoy, a separate instance of the HTTP filter extension is created.

Finally, Skopets noted that many developers who share in his background in Java assume that “filter” must be stateless, but he says that’s what makes Envoy unique. He explained to InApps Technology following his presentation that, when Envoy is handling a single HTTP request, it makes multiple callbacks into the custom HTTP filter extension. This could be one call for request headers and, depending on its size, multiple calls for request body, plus calls for request headers.

Skopets said, “So, if the logic of your extension needs information from an earlier stage of request processing, it must persist its information somewhere [like] remember ‘request headers’ to be able to use them when processing ‘response headers.’”

So where do you store that information? Since the HTTP filter extension only corresponds to one request, he suggests all of this auxiliary information should be stored in an Envoy extension itself. For example:

Skopets ended his KubeCon talk with the call to action to contribute to the Envoy open source code by building idiomatic Envoy SDKs for various languages.

Fork the code for this instance on Github.

KubeCon + CloudNativeCon is a sponsor of InApps Technology.

Feature image by Arek Socha from Pixabay.