WASM Is the Future

I'll be blunt about it: WASM is the future of modern computing.

Maybe not in its current form. Maybe (most probably) under a different name. But it definitely shows the way to how software applications of tomorrow are going to be built, delivered and integrated.

Write once, run anywhere!

Seriously, Java's promise was miraculous:

"Write once, run anywhere!".

Didn't fully deliver :(

Then we embraced Linux containers: "Finally - write once, run anywhere!"
Kinda.. if it's Linux, if you use stdlib, if you bring all your dependencies with you, if you understand the intricacies of container orchestration...

Don't get me wrong - containers are still fabulous. They are the perfect building blocks for creating and running efficient distributed systems.
But containers have their fair share of problems too:

Why Linux Containers Aren't Enough.

Containers are Bad at Sharing

Container architectures assume full autonomy and dependency encapsulation or - as they say - a "share nothing architecture". (It's true that the kernel is still shared between containers on the same host, but who looks that deep into the stack?)
Trouble is - the value in information systems comes from sharing information. And sharing loads of information over the network is inefficient, error-prone and cumbersome.

So we find ourselves falling back to dated OS-based data sharing mechanisms such as mounted volumes and side-car containers. Adding unnecessary complexity, layers of irrelevant abstractions and yes - security loopholes.

Containers are Bloated.

Most container images out there start by bringing a whole userspace just to package a couple of binaries.

As a result - the web is full of tutorials on how to make your images smaller. There are distroless containers. There's even smart (did anyone say AI?) software to analyze your containers and reduce their size.
It all looks a bit upside down. The tech is built on packaging a lot of redundant stuff and we now need more tech to clean up the mess. Why not build it right from the get go by only packaging what we need?

Containers are Stuck in the Cloud Native Paradigm

Containers were born in the cloud and as such they basically only make sense on servers. Yes, we've tried using them on the edge and in IoT with various levels of success but it always feels like an overkill. And of course there's no place for containers on mobile or in the browser (or on blockchain for that matter).

Clouds are definitely here to stay but their dominance is slowly dissolving into a fog of new platforms - more decentralized, more ephemeral, more resource-constrained. And the dominance of containers is dissolving with them.

The Promise of a Universal Binary

WebAssembly was invented to improve the performance of Javascript in the browser.
I won't go into why WebAssembly was needed or how it works. Quite a few great posts have been written on the topic. I'll link some in the end of this article.

I just want to focus on why WASM sounds so exciting.
The fact is that the idea of a universal compilation target has never lost its appeal. Yes, it looks like the industry was disillusioned for a while, but now we're getting our hopes back up. So smart folks were quick to realize that WASM's efficiency and performance could serve us well on a multitude of platforms (i.e not only in browsers). As of today - various efforts of talented engineers around the world are focused on making WASM modules usable:

• as serverless functions (https://github.com/deislabs/wagi)

• on the edge (be it CDN or edge devices) (https://blog.cloudflare.com/webassembly-on-cloudflare-workers/, https://wasmedge.org/)

• in automotive computing

• as smart contracts (https://www.parity.io/blog/wasm-smart-contract-development/)

• on the servers (inside WASM compatible runtimes) - https://wasmer.io/

• in network proxies (https://antweiss.com/blog/extending-envoy-with-wasm-and-rust/)

• scheduled by Kubernetes (https://krustlet.dev/)
  (proving that container orchestration is quickly becoming a too small and uncompelling niche - orchestration of the future will need to support much more diversity)

• in machine learning (https://github.com/WebAssembly/wasi-nn)

• more...

WASM modules hold the promise of becoming the universal binary format for a diverse set of platforms - with the necessary security and efficiency, but without the bloat and clumsy virtual network partitioning we have with containers.

The Promise of Universal Extensibility

Over the course of my career I've helped a number of tech companies in their community building effort. For community to bloom we need to lower barriers to entry by making software extensible. So one of the first stories that always gets discussed is the extensibility story.

Making your tool or platform - be it open or closed source, easily extensible is still a challenge. Should we tell our contributors to write Lua, Groovy or Python? Should they receive/return JSON or protobuf? Do we invent our own DSL? Should they package extensions as OCI images?

WASM brings with it the great potential of a unified extensibility story across platforms and languages.

• Need to expose some metrics to Prometheus? No more need to learn (or extend) the existing language-specific client libraries - use the universal WASM module instead.

• Need to have structured logging? - use an existing WASM module.

• Need to implement a new protocol in your language? - maybe someone already built a WASM module for that?

To Be Continued...

WASM is not there yet. Right now it's quite a hot mess of mutually incompatible runtimes, package formats and cryptic build processes. For starters - we're all waiting for WebAssembly Interface Types to take shape.

And of course - a lot of accompanying infrastructure will need to be built in order to distribute, secure and verify this future interoperability model.

But I know we'll get there in the end. This is the direction to look in. This is where software infrastructure opportunities and innovations are. This is why - with all the limited use cases we currently have for it - I continue investing in the research and knowledge sharing for this promising new tech.

That's how I see the future of WASM. But the beauty of the future is that everybody can have their own - so what's yours?

=======================

P.S As promised some links to great WebAssembly/WASM/WASI overview materials.

High-level goals on the official site

WASM in Mozilla Documentation

Rust and WASM

How to Think About WASM

Web Assembly System Interface by Linn Clark

Web Assembly and the Elusive Universal Binary by Alon Zakai