Taking WebAssembly/WASM to the Enterprise and Beyond

WASM is maturing quickly but adds value now. WebAssembly originated as a universal virtual machine meant to solve the need to be able to do more than just publish HTML to browsers and mobile devices. While its early life saw sleepy adoption, the desire to build more complex and full-featured web applications pushed many companies to look at the technology as a way to deploy applications more universally with faster speed than what was available with frameworks such as React. After big software publishers like Adobe showed the use of near-native speed applications delivered across browsers and mobile devices, an opening for every enterprise to reimagine how it deploys software has emerged. The open source community has been active in building all the constructs to make WASM easily consumable in enterprise environments and easily deployable via tools such as Docker, Kubernetes, Nomad, and more. The universality of WASM has made it an easy environment to program for and has spurred both Fermyon’s Matt Butcher and Cosmetic’s Liam Randall to champion WASM adoption as targeting the developer experience.

Don’t worry, just WORA! The WebAssembly System Interface, or WASI, will help achieve the "write once, run anywhere" (WORA) promise that Java brought us in the 1990s. Currently, WebAssembly has near universal presence in web browsers, which has allowed companies like Adobe, Fastly, and Cloudflare to demonstrate near-native application performance with web apps. Bringing that universal presence to enterprise computing requires a full system interface for communicating with operating systems, interacting with hardware, exchanging data between applications, and persisting that data for long-term use. As Matt Butcher mentions in the video, WASI is taking its time to try to get things like the component model right and resist the urge to fracture the code base. One strength that WASM/WASI has going for it is that it is open source and will hopefully avoid some of the runtime fragmentation that has occurred with other systems in the past (I’m looking at you, Java). WASI is also a very cloud-native architecture, allowing you to compose different WASM modules together, using the component model to build novel applications and using code modules written in multiple languages across multiple contexts. TL;DR: Build is good; build + reuse + compose is better.

Prepare for a cross-platform, cross-environment platform. WASM+WASI is not enough, however. At the WASM Day kickoff, Kelsey Hightower compared the promise of WASM to the success of COBOL and mainframe environments. The analogy is a good one, because there is an opportunity to use a universal virtual machine that can be used as a compile target for any language (i.e., WASM), with the ability to run on almost all browsers, mobile environments, and server environments with a component model that avoids the serialize/deserialize time-suck that currently occurs when passing data between different application stacks (i.e., WASI) and the ability to deploy, manage, and govern at scale (i.e., wasmCloud), as Liam Randall and Bailey Hayes describe in their interview. Add WASM + WASI + wasmCloud together, and you get a formula for deploying the same application on everything from mainframe to far-edge environments.