What’s Holding up WebAssembly’s Adoption?
The promise for WebAssembly is this: Putting applications in WebAssembly (Wasm) modules can improve their runtime performance and lower latency speeds, while improving compatibility across the board.
WebAssembly requires only a CPU instruction set. This means that a single deployment of an application in a WebAssembly module theoretically should be able to run and be updated on a multitude of different disparate devices whether that might be for servers, edge devices, multiclouds, serverless environments, etc.
In this way, WebAssembly is already being widely deployed to improve application performance when running on the browser or on the backend. However, the full realization of WebAssembly’s potential has yet to be achieved.
While the WebAssembly core specification has become the standard, server-side Wasm remains a work in progress. The server-side Wasm layer helps to ensure endpoint compatibility among the different devices and servers on which Wasm applications are deployed. Without a standardization mechanism for server-side WebAssembly, exports and imports will be required to be built for each language so that each runtime will understand exports/imports differently, and so on.
As of today, “Wasm components” is the component model but there are other verities being worked upon; “Wasi” is an approach that configures WASM for specific hardware. “wasi-libc” is the “posixlike kernel” group or “world”; “wasi-cloud-core” is a proposal for a serverless “world.” As such, the day when developers can create applications in the language of their choice for distribution across any environment simultaneously, whether it’s on Kubernetes clusters, servers, edge devices, etc. has yet to come.
Indeed, telling the WebAssembly story beyond the browser has taken a considerable amount of fundamental work,” Matt Butcher, co-founder and CEO of Fermyon Technologies, told The New Stack. “Some of this is just pure engineering: We’ve had to build the tooling. Some of it, though, has been good old-fashioned product management,” Butcher said. “That means identifying the things that frustrate the user, and then solving them,” We are on the very cusp of seeing these two threads converge, as the practical output of product management intersects with the engineering work behind the component model.”
Wasm’s value proposition can be summed up by “supersonic” performance, reduced cost of operations and platform neutrality, but the component model remains the sticking point, Butcher said. “Performance was the easy one, and I think we can already check it off the list. At Fermyon, we’re seeing total cost of ownership plummet before our eyes as thousands of users sign up for our cloud,” Butcher said. “But platform neutrality — at the level we care about — requires the component model. On that front, tomorrow can’t come soon enough.”
WebAssembly is designed to run applications written in a number of languages it can host in a module. It now accommodates Python, JavaScript, C++, Rust and others. Different applications written with different programming languages should be able to function within a single module, although again, this capability largely remains under development.
“Making programming languages truly interchangeable at the system level might be the final frontier on the way toward achieving the code-once, deploy-anywhere paradigm. But for this to work out, we need a common standard to integrate different languages with their specific feature sets and design paradigms,” Torsten Volk, an analyst for Enterprise Management Associates (EMA), said.
“This is a classic collective action problem where individual for-profit organizations have to collaborate for all of them to collectively achieve the ultimate goal of language interoperability. Additionally, they need to agree on pragmatic compromises when it comes to standardizing and fleshing out feature sets across languages.”
Have a Huddle
Meanwhile, engineers from numerous companies and universities are working on the component model, Wasi proposals and language toolchains under the auspices of a binary instruction format, with the goal of putting the specifications into the World Wide Web Consortium (W3C), Ralph Squillace, a principal program manager for Microsoft, Azure Core Upstream, said.
The engineers are actively contributing to the common pool of knowledge by contributing or maintaining open source projects, taking part in efforts such as the ByteCode Alliance or sharing their knowledge and experiences at conferences, such as during the KubeCon + CloudNativeCon Europe’s co-located event Cloud Native Wasm Day.
“As always when it comes to standards, all major parties involved need to be able to tell their stakeholders why it makes sense to spend valuable developer hours on this endeavor. This becomes especially tricky when different parties follow different incentive structures, e.g. cloud service providers are interested in customers spending as much money as possible on their services without getting sufficiently frustrated to move to another cloud,” Volk said. “This means that some level of lock-in is desired, while enterprise software vendors need to focus on a high degree of customizability and portability to open up their products to the largest possible audience. All this combined shows the high level of difficulty involved in bringing interoperability for Wasm over the finish line. I hope that we will because the payoff should definitely be worth it.”
A number of tools members offering PaaS offerings to distribute applications with Wasm continue to proliferate in wait for Wasm’s expected coming heyday. Entrants include Fermyon and Cosmonic. The newer player Dylibso is developing tailored solutions for observability; these solutions include Modsurfer, used to analyze the complexity and potential risks associated with running specific code in your environment.
Meanwhile, most large software companies are actively contributing to Wasm without necessarily creating a formal department to support Wasm-related open source projects, development, integrations with infrastructure and network topologies or to develop applications for Wasm, tech leaders are almost invariably working with Wasm in production or as sandbox projects.
To facilitate the incorporation of WebAssembly (Wasm) and bridge any existing gaps, VMware‘s Wasm Labs launched the Wasm Language Runtimes project. The primary goal is to be ready to run language runtimes, libraries and components, for developers interested in embracing WebAssembly, according to Daniel Lopez Ridruejo, a senior director at VMware and CEO of Bitnami/.
These language runtimes can be utilized in conjunction with various other initiatives, including mod_wasm (for running conventional web applications like WordPress) and Wasm Workers Server (for executing edge/serverless apps). Ridruejo also mentioned the compatibility of the Language Runtime project with open-source endeavors such as Fermyon’s Spin.
Others, such as Chronosphere and Microsoft, have already begun to use WebAssembly to support their operations mostly, while continuing to actively contribute to the development of Wasm for the community. In Microsoft’s case, its work with WebAssembly dates back years. Microsoft Flight Simulator for some years now has used WebAssembly for mod protection, for example, when it was shown to improve both security and portability for add-ons distributed as WebAssembly modules. Excel online uses WebAssembly for calculating Lambda functions.
Most of Microsoft’s work now consists of investing in the upcoming component model, Microsoft’s Squillace said. For example, Microsoft is expanding the Azure Kubernetes Service WASI NodePool preview and giving its services additional hypervisor protection per request on top of the Wasm sandbox with the Hyperlight project, Squillace said. “This serves very small bare-metal micro-vms very fast for use with wasm functions,” Squillace said.
Outside of the edge browser, Microsoft is investing mainly in server-based Wasm, the system interface (wasi) and the Wasm component ecosystem surrounding the Bytecode Alliance Foundation, as well as in infrastructure and language tooling to enable productive use, Squillace said. “That means open source investments like the CNCF’s Containerd runwasi shim for Kubernetes integration, but also TinyGo-compatible Wasm component tooling, VSCode extensions and serverless proposals like wasi-cloud-core,” Squillace said. “It also means Azure investments in security like hyperlight and Azure services like AKS WASI NodePool Preview and AKS Edge Essentials, among others.”
Big Hype
WebAssembly trajectory reflects similar cycles that happen with technologies, such as Java, containers, etc., Ridruejo said. “Each one of them have seen an ecosystem grow around it with new ways of doing monitoring, security etc. It is too early to know yet what that looks like,” Ridruejo said. “The question is whether that change will be incremental and existing vendors like, say, Datadog for monitoring will add Wasm support as a new feature or it will be distributive and new companies will take Datadog’s place (again just an example) and become the ‘Datadog of Wasm.’”
The million-dollar question is what needs to happen before tool providers and large enterprises can begin using WebAssembly to make money. To that, Squillace said:
“Customers already tell us they need a comprehensible (if not great) developer experience and a deployment and management experience that is solid. They also need networking support (coming in Preview 2); no networking means no service hosts in IoT without runtime support, for example. And finally, they need coherent interactive debugging. That last one is going to be hard across all languages and runtimes.”
