 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Although WebAssembly was created for bringing advanced programming to the browser, Solo.io’s founder/CEO Idit Levine has been a vocal proponent of using the portable’s fast open source runtime to extend service meshes — citing Solo.io’s own work in offering tools and services to support commercial service mesh operations. In fact, WASM, as its also known, could be used to bring extensibility across a wide variety of cloud native projects, she argues.
For this week’s episode of The New Stack Context podcast, we ask Levine about the excitement around WebAssembly, its use in the Envoy proxy, and Solo.io’s new proposal for packaging WASM modules in the Open Container Initiative format. TNS editorial and marketing director Libby Clark hosts this episode, with the help of TNS senior editor Richard MacManus, and TNS managing editor Joab Jackson.
Episode 135 : WebAssembly Could Be The Key For Cloud Native Extensibility
Pretty early on, the developers behind the Envoy service proxy found out almost every service mesh user needs to customize the control plane somehow. So they added extensibility through the addition of a filter chain. The idea was a good one, though initially adding a customized filter into Envoy was an arduous task, involving C++ and recompiling Envoy itself.
Google had been championing the idea of making WebAssembly a common runtime for Envoy, as a way to help its own Istio service mesh, of which Envoy is a major component. WASM is faster than JavaScript and, because it runs in a sandbox (a virtual machine), it is secure and portable. Perhaps best of all, because it is very difficult to write assembly-like WASM code, many parties created translators for other languages — allowing developers to use their favored languages such as C and C++, Python, Go, Rust, Java, and PHP.
Google and the Envoy community also rallied around building a WebAssembly System Interface (WASI), which serves as the translation layer between the WASM and the Envoy filter chain.
Still, the experience of building Envoy modules wasn’t packaged for developers, Levine thought at the time. There was still a lot of plumbing to add, settings for Istio and the like. ““Google is really good at making infrastructure tooling. But I’d argue they’re not the best at making their user experience,” Levine said. And much like Docker customized the Linux LXC — pioneered in large part by Google — to open container technology to more developers, so too could the same be done with WASM/WASI for Envoy, Levine argues.
The first step was to build out a registry: In December Solo.io launched WebAssembly Hub, a place where developers can share and reuse WebAssembly modules. The modules would be packaged with the appropriate metadata so that it can be easily and consistently downloaded, distributed and loaded into Envoy.
Instead of starting from scratch, the Solo.io team used an existing specification to package the module, one in which each layer could be defined. So it used the OCI format, originally created for packaging container images. Wanting to share its learnings from running the hub, Solo.io released the WebAssembly (WASM) Open Container Initiative (OCI) image specification, on that says will “define how to bundle WASM modules as OCI images to make it easy to build, pull, publish, and execute.”
“The WASM Image specification defines an image that consists of a WASM binary file and a configuration file, with the configuration file consisting of a JSON object specifying the intended runtime for the module, the module’s runtime ABI compatibility, and opaque runtime-specific configuration,” wrote Mike Melanson in a recent post.
The model of creating extensions through an intermediate WASM layer, so they can be consumed across platforms and generally automated into operations just like Docker containers, would not be limited to just service mesh technology, Levine argues in the podcast. The folks behind the Cloud Native Computing Foundation’s Open Policy Agent, as well as those behind CNCF’s NATS messaging software, are also mulling the use of WASM.
“I think that that will be the future of cloud computing,” Levine said. “I feel that that will be the way to extend everything basically, in the future.”
Other stories discussed in this week’s podcast:
