Impressions from WASM I/O 2024: Paths to Commercialization

WebAssembly (Wasm) companies like Fermyon Technologies and Cosmonic seem to be focusing on a peculiar set of features to convey their proposed use cases for Wasm:

• Cross-Language: Wasm is a compilation target for many languages; most notably: Rust, C, Go, JavaScript and Python. Hence, many different or even unrelated teams can develop and deploy on a unified platform.
• Performance: Wasm workloads can be re-shuffled to aid workload density and bare-metal energy efficiency. Similar to Kubernetes bin-packing.
• Composability: When utilizing the Wasm component model, the interoperability of otherwise unrelated modules is taken to an extreme. You can reconfigure and replace in any way that meets your needs.
• Portability: No matter if on premises, cloud, micro-controllers or browser tabs; You can make Wasm run anywhere.
• Safety: Wasm is memory-safe by design and cannot access operating system APIs without explicit granting. The host decides how much power to give a particular Wasm component.

Those attributes make Wasm a great candidate for use in regulated sectors like finance, healthcare, defense and government and one wouldn’t be wrong to guess that Fermyon Technologies and Cosmonic are proposing value in exactly those sectors. In fact, wasmCloud - the open-source technology Cosmonic is built around - is rumored to have been born at the american bank Capital One, when Cosmonic’s CEO Liam Randall was a VP there.

While investing in Wasm as a potential standard for finance is a safe bet in my opinion, I am more interested in catalyzing developer experience (DX) for commercialization. This approach is convenient to build for because there is no reason to scale the product if it doesn’t work well on the creator’s machine first.

Developer Experience for Commercialization

In my eyes, DX-driven commercialization doesn’t care that much about:

• Cross-Language: “Just use Go”. Frameworks are annoying to learn, but once a team decides on one set of tools and development philosophies, productivity can increase considerably as long as they understand and comply with the limits and freedoms of their chosen strategy. The Ruby-on-Rails approach.
• Performance: For most, good enough performance is certainly achieved without meticulous bin-packing and asynchronous programming.

Your code is all in one place and you can make it run in that one place or in multiple places with minimal toil thanks to the portability and composability of Wasm. Components inside your code base can run together as one program or in a more distributed fashion with the click of a button. If that sounds magical to you, I invite you to learn more about the component model. Matt Butcher, CEO of Fermyon Technologies does a much better job at explaining the component model than I could in this blog article.

So what do the advantages of the component model mean more specifically? You can develop a Go program that implements the database, the application server and the client. On your dev machine you execute it all as the same program, which is very convenient and makes for great testability. For shipping your app to customers, you have multiple options right off the bat that you can approach simultaneously. You can:

• Deploy your application with multi-tenant capabilities to your infrastructure where the application server and database server run as a single program and the client is dynamically loaded onto a customer's browser tab.
• Deploy your application with single-tenant capabilities to the customer’s servers.
• Ship the whole application as a single Wasm binary to the customer who can run it on their laptop.
• If you're lucky and have many customers using your multi-tenant deployment, scale out the application indefinitely by having (1) The database implementation run on its own nodes (2) Some components that make up the application server run as independently scaled microservices (3) The router or controller layer run on the edge (4) The client run on the users OS or browser tab

A whole observability stack could scale in line with the application. Being present in the single-program version of the app as well as in the globally distributed multi-tenant version.

So companies providing Wasm-native tooling can build systems that developers can plug into once they want to deliver their product through multiple channels simultaneously. And it might not be a total mess because of Wasm’s inherent portability and composability.

Current State and Direction

The DX-driven world is slowly moving in this direction.

• Dagger does so by bringing CI-workloads from the cloud to the developer machine for better ease-of-use, performance and economy. I wouldn't be surprised to see Dagger use Wasm in the future for its portability.
• Microsofts’ C# Blazor makes it possible to write server-native C# code (e.g. alongside your already existing C# .NET app) that ultimately runs on the user's browser tab. Making it much easier to write capable web-clients for organizations that adopted C#.
• Googles’ Flutter is increasingly leveraging Wasm to deliver their cross-platform technology. To make a singular UI run on a multitude of client platforms.
• Fastly’s Compute utilizes Wasm the other way around. Similar to a Function-as-a-Service product, they take care of deploying your apps to a multitude of servers across their own edge.

There might come a time in which enterprises replace the Angular clients they wrote to accommodate their old Java 8 backends… with more Java 8 code (which compiled to Wasm, runs as a client in the browser tab). Thank you Wasm!? ??

In more epic terms: The pendulum might be swinging back towards a side that was last defined by the post-dot com crash era of big, capable, opinionated MVC monoliths à la Ruby-on-Rails, Python Django, Java Spring. Back then, you just had to accept that the application was running in one place: The web server. But in the future, you will be able to enjoy a Ruby-on-Rails-like developer experience paired with the fact that the app you're building can run almost anywhere. In my eyes, a true majestic monolith.

Dreaming of the Future

As you can tell, I am stumbling around trying to make out what an early Wasm-based Platform-as-a-Service (PaaS) for developers could look like. I think it would have to be designed with many limitations in place so we can actually focus the current potential Wasm gives us:

• Go is the only programming language that can be used. I choose Go because it is built for developer productivity, certainly production-prooven and can be fully compiled to Wasm.
• The programming paradigm native to the platform would be something like what Fermyon’s Spin employs. Simple, shallow architecture.
• By using a Go-SDK, the developer is free to tag certain interfaces that they want the PaaS to implement. E.g.: (1) In “simple mode”, the platform will choose to make many if not all inter-component communication function-calls. (2) In “client-server mode”, e.g. client-components that need to call server-components use the network-stack. Something like websockets when symmetric, something like http when asymmetric. The platform would also make sure server-components can serve multiple hosts.
• Popular but not Go-native or complex technologies like PostgreSQL, torch or Kafka can’t be supported. Simple alternatives like github.com/mattn/go-sqlite3 (if you want to use SQL) or github.com/boltdb/bolt (if you need a KV store) would have to be used as Go dependencies. If you really want to use PostgreSQL, you can of course always connect to a PostgreSQL server over the network but the platform won’t care for it.

I am pretty sure, that versions of that dream are already on the market and I am eager to delve deeper into these technologies to better grasp how their vision aligns with the one I have cultivated at WASM I/O. But before I’ve actually gone through that process I thought I’d share some of my impressions from the conference - a conference full of tinkerers, pioneers and visionaries that radiate a mood only captured by a German word: “Aufbruchstimmung” (the collective sentiment of anticipation, renewal, and the dawn of new beginnings).

I recommend anyone in IT to invest some time in learning more about WebAssembly, a technology with the potential to be as transformative to the sector as GenAI.