The Four Domains of Wasm
Matt Butcher
serverless
browser
iot
cloud
plugins
While Wasm began in the browser, it has reached well beyond. But as we barrel headlong into 2023, Wasm is showing particular promise in four domains. In this post, we’ll take a look at those four domains, and then focus on the one we at Fermyon find to be the most compelling.
Some technologies are developed for a specific purpose, and remain always attached to that purpose. Git, for example, has never found success outside of the software version control domain. R has remained a language for statistics. And Apple’s watchOS hasn’t yet appeared on a fridge.
Other technologies, though, seem to grow beyond their special purpose, becoming generally useful. Java may have been originally imagined as a language for embedded usage, but it has grown well beyond those roots. And no case stands out more than the Web itself, which began as a way to trade physics papers between research institutions.
Wasm belongs in this same category as Java and the Web. It is a technology that has found uses beyond its original design.
The Four Domains
Wasm has a few standout virtues that elevate it from a domain-specific technology to a general purpose one. These virtues are:
- A strong security model where the host runtime does not trust the guest code
- An OS and architecture-neutral binary format that can run on anything from small single-purpose processors up to multi-core powerhouse processors that one finds in high end workstations and servers
- An open specification overseen by a well-regarded standards body, the W3C
Because of these virtues, developers have found a variety of interesting use cases for WebAssembly. Four major domains, though, are particularly well suited for WebAssembly.
Browsers
Wasm was designed to augment JavaScript. For most of the life of the web browser, JavaScript has not only been the default option, but the only real option for scripting web pages. Over the years, various technologies have challenged JavaScript. Applets, ActiveX, Silverlight, VBScript… each had its brief day in the sun, but none displaced JavaScript.
The idea behind WebAssembly is an iteration on these earlier attempts: Instead of introducing a new language or plugin architecture for the browser, why not define a general purpose Virtual Machine (VM) that other languages could compile to? Interoperability with JavaScript would make it possible to export functions out of this VM (to be called by JavaScript at will) and import functions from JavaScript (to be called by the guest code).
A little more than seven years ago, a group of engineers from Mozilla, Apple, and Microsoft worked to standardize such a runtime. Wasm is the result of that work. And it is supported in all major browsers with a startling degree of uniformity and conformance to the W3C’s WebAssembly Core Specification.
While Wasm is indeed extending beyond the browser, there are still many clear use cases. For example, Figma and Adobe each use WebAssembly to speed up some of the more intensive graphical calculations their web applications do. Blazor, a web framework from Microsoft, brought the power of .NET to the browser. And early in 2022, the entire Libre Office productivity suite was ported to Wasm to run in the browser.
There is no reason to believe that Wasm’s adoption elsewhere will in any way slow or hinder the browser use case.
IoT and Far Edge
The Wasm specification took great care to keep resource utilization modest. A spec-compliant Wasm runtime should not require a desktop-grade browser to execute. Instead, it should be executable on tiny embedded devices even smaller than the Raspberry Pi.
WebAssembly can be executed in interpreted mode (that is, without a JIT compiling step) with as little as 1M of memory available to it. And Wasm runtimes such as WAMR and wasm3 each fulfill this promise.
Combined with the security and cross-OS/architecture stories, WebAssembly is an enticing language for embedded engineers who want to write a single codebase of software that works equally well on a variety of devices. Disney+, Amazon, and BBC all use WebAssembly for their streaming apps. And with the vast number of streaming-capable hardware devices, it’s no wonder why streaming services would choose Wasm.
Wasm on Internet of Things (IoT) and far edge (e.g. small devices at the boundaries of a network) is all but a foregone conclusion at this point. And we expect to see a variety of applications emerge in this space.
Plugins and Extensions
A friend once remarked that, “Wasm is the last plugin technology we’ll ever need.” What he meant by this is that the system flexes in all the right places to make it a good fit for plugin architectures, and was generic enough (with broad enough language support) that the days of writing custom language-specific plugin systems may well be over.
It is important to understand what a plugin (or extension) is. Without a definition, bold but inaccurate claims are made, such as “everything is a plugin!” Plugin architecture is very specific, but intention is perhaps more important than architecture.
A plugin system is one in which a specific application’s feature set can be extended via a user-supplied piece of code. For our purposes, extensions (e.g. browser extensions) have the same intent, and are thus the same.
Plugins, then, allow developers to build new features of office suites, for proxies, for CRM systems, and for chat platforms. Each plugin adds a specific new feature or features to the underlying platform, enabling the user to achieve something new or something more in the same application.
Contrast this with something like an application server. Yes, an application server may execute a developer-supplied piece of code. But the intent is not to change the way the application server operates. It is not adding a new feature to the app server. Rather, the app server is providing base functionality for the developer-supplied code. In other words, the intention is different.
What makes Wasm a good plugin system is that it is easy for the main application—the host—to provide an API and all the right callbacks for the plugin—guest code—to be able to do its augmentation thing. Few people know that Wasm is behind MS Flight Simulator’s plugin architecture. It is also used in Envoy Proxy. Here at Fermyon, we’re hearing rumblings about some other plugin use cases. Wasm I/O will be a great place to hear the latest.
Cloud and Edge
This one is my favorite. Wasm is the perfect technology for cloud computing.
Cloud computing describes the area of cloud principally concerned with running your code on someone else’s hardware. In the past, there have been two major types of cloud computing engine: VMs and containers.
VMs comprise the kernel and drivers, the filesystem, all the libraries, and the application or applications to be run. They are big and burley. Indeed, they are the heavyweight class of cloud computing. This is why it takes a VM a few minutes to start up. There’s a lot going on there!
Containers are the middle weight class of computing. They contain just a single application, the filesystem, and any libraries or utilities needed by that application They share the kernel and low level drivers with all other containers on the system. Instead of taking several minutes to start, they take seconds.
Wasm is the ideal candidate for a third wave of cloud computing. It is the lightweight class, bundling only the application. While VMs take minutes to start, and containers seconds, Wasm takes mere milliseconds, making it the fastest of the three by a long shot. And just like VMs and containers, Wasm has a strong security model that can safely run applications from multiple customers side-by-side without a security risk.
Does this mean that Wasm will “defeat” or “replace” containers or VMs? That’s highly unlikely. Wasm is filling a niche that has sat vacant, and perhaps some things that were once done with VMs or containers might be done with Wasm. But that doesn’t mean containers or VMs are going to go away. When Docker first came on the scene, pundits suggested that VMs were a thing of the past. But here, several years later, both technologies are growing rapidly and enjoy wide adoption. This pattern will hold with Wasm as well.
Why Cloud is the Important One (to Us)
When new higher level technologies like lambda functions and hosted apps came on the scene, these were backed by either containers or VMs. One can think of this architecture as “Serverless v1.” While doing serverless in this way caught on, it never quite lived up to the expectations. Functions are slow to start and are expensive to operate in part because the technology they use under the hood is itself hefty.
Wasm gives us an opportunity to re-architect the base compute platform upon which serverless solutions are built. Instead of taking hundreds of milliseconds to start a function, Wasm reduces this to below one millisecond, making it possible to run high-performance web apps, microservices, and data transformation pipelines as serverless functions. This, in turn, means that fewer applications need to be deployed and managed by Kubernetes and similar heavyweight services. Speed and cloud savings. That’s a great combination.
Here at Fermyon, we feel deeply that this new Serverless v2 model is the future. With open source tools like Spin and our own hosted serverless platform, we believe we can demonstrate the possibilities opened by this new third wave of cloud computing.
Conclusion
There is no doubt that Wasm has grown beyond its initial purpose. And with good reason. Wasm’s security model, runtime profile, and cross-platform functionality make it a great candidate for a variety of problems. Here, we talked about four big domains where Wasm shines: Web applications, IoT, plugins, and cloud. Over the next year, we will see Wasm blossom in all four of these areas. But to us at Fermyon, it is the cloud case that is most attractive. We believe Wasm will be the foundation for Serverless v2, a faster and less expensive way to run applications in a highly scalable environment.