Wasm is what’s up. In terms of the hot technologies discussed at any of the major enterprise IT shows being staged this year, WebAssembly (often written as Wasm and typically pronounced ‘wass-em’ in Europe and ‘wazzum’ in North America) has been bubbling up since it was conceived in 2015 before progressing to become and World Wide Web (W3) Consortium recommendation in 2019. But what is it and why does it matter?
As a fundamentally cloud-native technology, WebAssembly (Wasm) came about because developers face obstacles in modern application development, particularly when building distributed applications. This portable binary code format technology exists to help software engineers build high-performance web-based applications with its open standards.
From web to cloud
But this technology has been on a journey, it has moved from web to cloud – if we can reasonably suggest that these two interrelated domains are indeed separate – and, like the cloud, the growth pattern has been all about scale, speed and superlative services.
One man that has tracked this technology’s ascendancy is Matt Butcher, co-founder and CEO of Fermyon, a company known for its cloud technology that provides a route to run serverless functions and apps with WebAssembly. Fermyon is also lauded for having built Cloud Native Computing Foundation (CNCF) projects like Helm, the package manager for Kubernetes and Brigade, the tool for scriptable tasks.
“In the early days of the web, Java Applets complemented a ‘toy’ browser language called JavaScript,” reminisces Butcher. “Applets promised to give us all the power of a desktop application inside of the web browser. But Java was slow… and that little toy JavaScript language started gaining features. So then, as Java Applet enthusiasm waned, more developers took a serious interest in using JavaScript to liven up the browser.”
We can stop here and note that other in-browser rich (and essentially proprietary) application runtime environments’ came and went e.g. ActiveX, Flash, Silverlight etc. But just as Java ultimately faltered and was then removed, these other technologies also fell by the wayside. Meanwhile, JavaScript matured.
“Then a funny thing happened on the way to the keyboard,” explains Buther. “JavaScript outgrew the browser. Node, Electron, Deno and a litany of projects empowered developers to build servers, desktop apps and utilities in JavaScript – outside the browser. We saw that npm [the JavaScript package manager technology] made it easy to package up JavaScript libraries for use anywhere. Almost suddenly, JavaScript was a mainstream general purpose language.”
Any chip, any OS
As JavaScript worked its way outward, the core engineers on Mozilla Firefox, Google Chrome, Microsoft Internet Explorer (before Edge, if you can cast your mind back) and Apple Safari began an initiative to move all sorts of other languages into the browser. The thinking was, if JavaScript could bring its virtues to all aspects of computing, why not make it possible for other languages to interact with JavaScript inside the browser? WebAssembly is the keystone of this whole vision says Butcher. He explains that WebAssembly defined (and still defines) a standard binary format that can run on any operating system, any chip architecture and on all major browsers.
“By tooling language compilers for the WebAssembly format, language developers can make it easy for their users to compile programs for the web. The C programming language and the (at the time) brand new Rust language provided early proof points that WebAssembly was up to the job,” said Fermyon’s Butcher.
For him, perhaps the best thing about WebAssembly’s design is that it does not require the developer to learn something new. Done right, WebAssembly isn’t a technology that the average developer needs to know or understand. They merely need to know when to set the Wasm32 format, as it is known, as the compiler’s target format.
Four core attributes
WebAssembly has four critical attributes:
• Security: The binary must execute in a secure sandbox that cannot access browser or system resources unless explicitly given permission to do so.
• Binary Portability: The same executable must run on all the major operating systems and system architectures, and should be easily implementable on even the most exotic hardware and operating systems.
• Performance: Nobody wants to wait for a Web page. WebAssembly code must start nearly instantly and run at least as fast as JavaScript.
• Size: If the binary is going to be shipped as part of a Web page or Web app, it must be small.
Clearly, these four properties — security, portability, performance and size — have value well beyond the web browser. While the first few years of WebAssembly’s life were browser-focused, it soon gained attention beyond the browser.
“This story of outgrowing the original purpose is not at all unique to WebAssembly,” said Butcher. “Java was originally designed for embedded computing, though it ultimately made the most impact as an enterprise language. Ruby was designed to be a scripting language for UNIX systems until (ten years after Ruby was created) Rails turned it into the web developer’s language of choice for a while. Even the Internet itself was designed for one purpose (a defence network) only to find itself applied on a vastly broader scale.”
WebAssembly has followed a similar trajectory. Internet-of-Things (IoT) developers find its size and portability enticing. WebAssembly’s security model and performance make it a great fit for plugin architectures. It is even finding its way into databases, where stored procedures and PL/SQL can be replaced by user-defined functions (UDFs) compiled to WebAssembly.
Cloud, a natural homeland
“There is no place more promising for WebAssembly, though, than the cloud. The four properties that make WebAssembly good for the browser make it an excellent fit as a cloud computing engine. The easiest way to understand the affinity between the cloud and WebAssembly is to look at serverless computing,” rounded out Butcher, again ultimately very positive about this technology’s purpose given his firm’s vested interests in this space.
But we need to take this whole discussion into consideration by mentioning the promise of serverless application development. As we know, developers love the promise of serverless applications. Writing a typical server requires thousands of lines of code, often bundled up in libraries, frameworks, and packages that we (as developers) must maintain and debug. In short, when writing a server, developers write a lot of boilerplate code and take responsibility for gobs of code written by (and maintained by) others.
Serverless applications start on better footing. Instead of dealing with process handling, network sockets and TLS configuration, the serverless developer starts coding at the point they care about – writing the business logic – which they can do in the knowledge that server provisioning happens on-demand in as as-a-Service model at the point when and where it is needed.
Most serverless platforms run each function on a virtual machine. Virtual machines are designed to execute entire operating systems. Using a virtual machine to execute a single function feels a bit like using a forklift to retrieve that one-pound package from your porch. The problem, in other words, is that the form of cloud computing used beneath the hood became a critical limitation for the developer. The solution is clear: Find a better compute engine to undergird serverless applications.
WebAssembly is Serverless v2
“This is where WebAssembly comes in,” said Butcher. “WebAssembly’s speed, binary portability and small binary size blow past virtual machines and containers. Applications start nearly instantly and the developer doesn’t have to know anything at all about the underlying operating system and architecture. As a standardised binary format backed by a trove of open source tooling, WebAssembly resists vendor lock-in. That has implications for debugging and troubleshooting as well. Applications can be built and tested locally and then deployed to environments that instrument for visibility.”
Most importantly, all of this can be achieved without sacrificing security. The WebAssembly sandbox isolates serverless apps from each other at a security level that surpasses today’s container technology and is approaching the modern virtual machine.
Serverless computing is getting a reboot and, argues Butcher, WebAssembly may just be at the heart of this change. Instead of a half-second startup delay, serverless functions in WebAssembly start in single-digit milliseconds. As programming languages add support for WebAssembly, developers gain access to a growing list of options.
The Fermyon CEO concludes that WebAssembly will always have a space in the web browser, but that there are plenty of other areas where WebAssembly will shine, such as IoT, databases and plugin systems. We might reasonably argue (given all of the above) that cloud computing has the most to gain from WebAssembly. Developers love the simplicity of serverless applications and WebAssembly delivers the computing engine needed to take a programming paradigm and make it practical.
7 hours ago
