Why You Should Pay Attention to WebAssembly

There may come a day when the humble web browser – having already yielded enterprise grade server side technologies like Firecracker, Isolates and Node.js – has nothing of interest left for the industry to extract. But that day has certainly not arrived yet, as the increasing chatter around WebAssembly (WASM) proves.

The fact that people are talking about WASM is not new. Nor is the fact that it has people excited. WASM has been a topic of discussion for years as the industry pondered a larger role for a technology originally designed to run binary code within the context of the browser.

What has changed, however, is the volume of conversation about WASM. As WASM has taken the initial steps towards a potential role as a critical piece of enterprise infrastructure, discussion of the technology has spiked both in the community at large and within the conversations RedMonk has with its participants.

Before exploring the reasons for paying attention to WASM, however, it’s necessary to understand what the technology is. WASM is a W3C standard and the project is maintained by contributions from a wide range of vendors including all of the major browser vendors. The original design goal was simple: provide a portable mechanism to run executables on a web page, and to do so quickly and securely. While this had clear use cases within the context of the browser, it turns out that a fast, lightweight and secure way to run things had non-browser use cases. Lots of them. To the point that there are some, as in the tweet above, who argue that WASM will be an important platform moving forward, if not the important platform.

There’s a long road for WASM to travel before it gets anywhere near that ceiling, but the following are a few of the reasons WASM is worth keeping an eye on.

1. It’s Getting Faster
   Speed is a feature, and those behind the WASM specification have been hard at work. A little over three years ago we spoke to some of the core dev team, and their estimation was that WASM came with approximately a 20% performance hit versus native code. They speculated that within about two years that difference could be erased, or at least made negligible enough to not matter. Today, depending on platform and workload, that has proven to be the case; one provider even claimed recently to run faster within WASM than natively. The performance limitations, therefore, that have held WASM back in the past are largely subsiding, making it viable for more and more workloads.

   

2. It’s Quick
   If WASM has been compelled to work on its overall performance, there’s no such need with respect to its latency. Even from cold start situations, WASM’s latency is measured in milliseconds, not actual seconds as is typical with other application platforms from containers to function-as-a-service providers. This makes it highly suitable for workloads that are latency-sensitive, which is more and more workloads – and certainly the event-based workloads that are becoming more common within the enterprise.

3. It’s (Relatively) Secure
   Granting that no software is immune to vulnerabilities, WASM is nevertheless distinguished in this area. Designed from day one to be secure enough to run executables within the context of an individual’s browser, it is based on sandbox principles, with no access to or from the outside by definition. At a minimum, the historical priority placed on security has been higher than other platforms, a fact likely to be appreciated by security-sensitive enterprise buyers.

4. It’s Lightweight
   Relative to something like V8 isolates, WASM executables are sizable. But just as containers were much lighter weight than the virtual machines they supplanted, so too is WASM dramatically lighter weight than containers. This means that, properly orchestrated (a subject we’ll come back to), WASM deployments can be fantastically dense relative to their container based peers; one provider reports 20X-30X more WASM sandboxes than Kubernetes containers, for example, on a given piece of hardware. Similarly, Cloudflare has talked about their usage of Isolates to achieve the same goal.

   This density is, in part, why the popular assertion that a growth in WASM deployments will enable something of a renaissance of PaaS platforms seems correct. The unit economics of running platforms – potentially more safely – at dramatically higher densities than container-based alternatives make WASM-based PaaS platforms more viable not only technically but economically as well. Both in terms of their overall end user pricing, but also potentially making free or lower cost tiers possible that have previously been deemed cost prohibitive by vendors such as Heroku.

5. The Language Support is Improving
   For enterprises used to working with container-based platforms, or virtual machines before that, language limitations are non-existent. Whatever the language and runtime, a given application is wrapped in a container and then run on platforms like Kubernetes alongside hundreds or thousands of other workloads, covering a multitude of languages. But as Fermyon’s language support page indicates, WASM’s support for various programming languages varies, and widely. But this is unlikely to be a fatal flaw for WASM-based providers. First, because the support for new languages is improving, and at an accelerating pace as more attention is focused on the technology. Second, because the set of core languages supported already (C/C++. C#, Go, Kotlin, Rust, Swift etc) cover a large number of potential workloads. And lastly because abstract models like PaaS have always imposed such constraints, and if anything that’s likely to become more common rather than less as more and more abstract models emerge.

One of the questions being asked around WASM today is what impact will it have on the market broadly, and the container market specifically? Early indications are that it will be both complement and competitor, but if history is any guide, much as virtual machine vendors tried to get out in front of the container trend early, those in the container space are likely to be aggressively embracing WASM while they determine exactly where and how it fits – as Docker itself is, in fact.

The broadest market impact, however, would come from WASM PaaS-like abstractions capturing workloads at scale. While vendors like Cosmonic and Fermyon were built around WASM, however, and others like Cloudflare, Fastly and Vercel have spun up that capability – or in Fastly’s case, hired an entire team out of Mozilla – there are some obstacles between WASM and a role of outsized importance. The documentation could use some attention, and while it’s not strictly necessary, it would be useful to have standardized orchestration mechanisms for large-scale WASM deployments. Fermyon is using Nomad, and there are other projects targeting the problem, but it would be useful for a standard means of orchestration to emerge. More pressingly, however, is the need for a standardized component model. As described by Charlie Marsh:

There’s no standardized component model for WebAssembly right now, so in order to run on any sort of hosted WebAssembly platform, you have to implement module-side code (source). You see this with Fermyon, where you have to write your code using their Spin framework. You also see this with Fastly’s Compute@Edge, where you have to implement fastly_http_req and fastly_http_body to make your WebAssembly code compatible with their interface (source). Maybe this is fine, I just expected something more generic.

What enterprises will understand when they read that is that WASM code written for one platform will not run on another without modification. Now the truth of the matter is that dating all the way back to Java’s “write once, run anywhere” promise all the way up to today’s various Kubernetes distributions, this has always been the case – the marketing notwithstanding. But vendors historically have at least had to pay lip service to the idea that applications would be portable from platform to platform. Without at least the veneer of interoperability, enterprise uptake will be substantially throttled. That would appear to be a solvable problem, however, and it’s still early days for WASM.

Not too early, however, to pay attention.

Disclosure: Cloudflare, Docker, Fastly and Vercel are all RedMonk customers. Cosmonic and Fermyon are not currently customers.