If WebAssembly is to make its way from edge computing to the core of enterprise data centers, its path will likely go through the Cloud Native Computing Foundation.
In the last year, the Cloud Native Computing Foundation (CNCF) accepted a series of WebAssembly (Wasm) sandbox projects that target server workloads, including wasmCloud, WasmEdge and Krustlet. Each takes its own path toward unifying management among far-flung distributed applications across clouds, edge computing locations, and IoT and mobile devices.
These projects could ultimately represent a new take on IT management that relieves the burden on enterprise IT pros of importing and individually maintaining common software libraries, with their attendant software supply chain security issues. However, while WebAssembly shows promise on the server side, industry analysts caution that it's still early in the evolution of this technology beyond specific edge computing use cases.
"That wider ecosystem that's asking, 'Can Wasm be used in conjunction with things like Kubernetes?' is really just emerging right now," said Fintan Ryan, an analyst at Gartner. "It does solve some inherent problems that exist in the container ecosystems, but there isn't mainstream adoption as of yet."
WebAssembly server tools surface for Istio, Kubernetes
Some early adopters of service mesh architectures have found WebAssembly useful to create and share customization modules.
WebAssembly server-side support began to appear upstream in the Envoy proxy project in October 2020, where it offered customization advantages over the previously used Lua scripting language. In contrast to Lua, which required developers to create and maintain their own Envoy extensions, WebAssembly can be used to compile customizations from more than 30 programming languages into a standardized and shareable set of modules.
As of Istio version 1.9, the service mesh can systematically apply Wasm filters to Envoy proxies via the Istio control plane. In August 2020, Istio vendor Solo.io put a set of these modules into a portal called WebAssembly Hub. Another open source project, Proxy-Wasm, created a specification other proxy projects can use to compile their own WebAssembly modules.
More recently, new CNCF projects have begun to take server-side WebAssembly a step further. Istio is often deployed alongside Kubernetes, but Krustlet, accepted as a CNCF sandbox project in July 2021, more directly links Wasm with the container orchestration platform. Krustlet is a version of the Kubernetes node agent, or kubelet, that can be used to run both WebAssembly workloads and Linux containers in the same cluster.
"While containers and WebAssembly modules can be used for some of the same workloads, we believe they are complementary technologies," Krustlet maintainers wrote a July 2021 blog post (italics in the original). "WebAssembly's true OS and architecture portability, compact format, and extremely fast startup, together with the flexibility of containers as a full operating system sandbox ... allow developers to choose the right tool for the job."
WasmEdge proposes situational container replacement
Meanwhile, WasmEdge, accepted as a CNCF sandbox project in June 2021, positions Wasm and the WebAssembly System Interface (WASI) as potential replacements for Linux containers that run faster and make more efficient use of resources.
Wasm will never totally replace Linux containers, Yuan said, but it could expand developers' choices for application deployment in certain industries, such as manufacturing shops and autonomous vehicles, where compute processing resources are and will likely continue to be constrained. Some data center applications such as databases could also benefit from easier ways to move computation closer to individual data sets, Yuan said.
"Databases have this concept of stored procedures that perform computations and user-defined functions inside the database, but it typically requires a domain-specific language," Yuan said. "With WebAssembly, you can use regular programming languages to define those functions."
WebAssembly also potentially offers a way to facilitate app portability between edge, mobile and IoT devices in addition to clouds and traditional data centers, according to some advocates.
"Like a lot of things before it -- Java, Silverlight and Flash -- WebAssembly promises 'write once, run everywhere,'" said Liam Randall, CEO of Cosmonic, which sells a commercial version of the wasmCloud project that was accepted into CNCF incubation in August 2021. "But WebAssembly is an internet standard that's already supported everywhere -- in your browser, on edge devices, on edge networks and even on servers that run in the cloud."
WasmCloud packages WebAssembly server-side for enterprises
Cosmonic and wasmCloud maintainers view WebAssembly as a fresh layer of computing abstraction that can do for applications and underlying software libraries what server virtualization did for operating systems and underlying server hardware, containers for applications and underlying operating systems, and Kubernetes for microservices and underlying cloud APIs.
Liam RandallCEO, Cosmonic
"With WebAssembly, what we're saying is, it's basically a virtual CPU that I can use for an individual process," Randall said. "If you pair that with a framework like wasmCloud, you get even more portability, because it virtualizes the libraries."
The wasmCloud framework lets IT operators mix and match developers' business logic, compiled into WebAssembly modules, with various software libraries specific to different operating systems, processor types, Kubernetes distros and cloud APIs. Decisions about where and how to deploy applications can then be made at runtime, without requiring developers to import software libraries and separately integrate their apps with each environment. WasmCloud then centrally maintains all the instances of these WebAssembly applications, regardless of where they are deployed.
Such a framework could ultimately take some of the burden of software supply chain security out of individual organizations' hands, since they wouldn't have to maintain their own implementations of common open source libraries within each of their applications, Randall said.
IT consultancy experiments with wasmCloud
This is still far from an everyday reality for most companies, but some big enterprises have begun to entertain the concept as part of proof-of-concept projects.
For example, one digital transformation consulting firm demonstrated multi-cloud failover last year using wasmCloud as a bridge between Google Cloud Platform and AWS for a large European banking client that needed to demonstrate such resiliency to satisfy regulators.
Cosmonic's wasmCloud product added a crucial component for the demo, which was built using a small database application that facilitated the movement of WebAssembly-based application logic between multiple clouds in separate countries. That component is a wasmCloud feature called the lattice mesh, which connects multiple cloud networks via the NATS open source distributed messaging framework.
"It's NATS that gives us the homogenous kind of surface that flattens the multi-cloud network," said Stuart Harris, founder of Red Badger, a London-based tech consultancy. "In the situation with the bank, we had to determine, how do those services talk to each other without getting network engineers involved to configure networks and firewalls, but in a secure way?"
In this instance, NATS was able to route network traffic between cloud data centers more efficiently than a series of VPN tunnels and TCP/IP connections, while supporting encrypted traffic and multi-tenancy for security purposes, Harris said.
However, Harris acknowledged, there's still a big difference between a demo application and something the bank -- which Harris was prevented from naming by an NDA -- may eventually use in production. And while Wasm/WASI, like service mesh, can relieve developers of having to deal with infrastructure complexity, that complexity doesn't just disappear, Harris acknowledged. As with service mesh, new layers of abstraction may shift the burden of that complexity instead to SREs and DevOps platform teams.
The alternative, however, is expecting the mythical "full-stack developer" to arrive out of thin air -- and in practical reality, expecting developers to handle every aspect of both applications and infrastructure is likely to create security and reliability risks, Harris said.
"Something has to give, and I think we don't want it to be the reliability and security of our services," he said. "We can't let those things pay the price."
Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.