Envoy Looks to WebAssembly to Extend Microservices Monitoring – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn Envoy Looks to WebAssembly to Extend Microservices Monitoring – InApps Technology in today’s post !

Read more about Envoy Looks to WebAssembly to Extend Microservices Monitoring – InApps Technology at Wikipedia

You can find content about Envoy Looks to WebAssembly to Extend Microservices Monitoring – InApps Technology from the Wikipedia website

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.

Read More:   The (Variable) Naming Is the Hardest Part – InApps 2022

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.

Read More:   RSS3 Brings Syndication Feeds (and FriendFeed) to Web3 – InApps 2022

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.

Source: InApps.net

Rate this post
As a Senior Tech Enthusiast, I bring a decade of experience to the realm of tech writing, blending deep industry knowledge with a passion for storytelling. With expertise in software development to emerging tech trends like AI and IoT—my articles not only inform but also inspire. My journey in tech writing has been marked by a commitment to accuracy, clarity, and engaging storytelling, making me a trusted voice in the tech community.

Let’s create the next big thing together!

Coming together is a beginning. Keeping together is progress. Working together is success.

Let’s talk

Get a custom Proposal

Please fill in your information and your need to get a suitable solution.

    You need to enter your email to download


      Success. Downloading...