True Portability Is the Killer Use Case for WebAssembly

As the latest web technology to catch fire, many see WebAssembly or Wasm as a “can’t miss” proposition. Proponents rave about the performance, which is lighting fast, and the security model, which is “least-privilege” from the ground up. Near-instant startup times of Wasm processes are a big benefit as well. Often missing from the list of major benefits is true portability.

Why? Because robust portability is the ultimate killer app. Untold tens of billions are wasted each year on the unpleasant act of “porting.” Every DevOps team knows what porting hell is — trying to have a highly customized app run on multiple clouds or trying to run the same process and code in multiple serverless environments.

Portability is why the dominant SaaS model emerging today is a distributed cloud where a technology company abstracts away the multicloud complexities to allow customers to just write once and run everywhere. With portability comes resilience, agency and bargaining power on price.

For developers, DevOps and platform teams, true portability has long been a Holy Grail, often promised but never fully delivered. We heard it with Java, then with containers and then with serverless. Write once, run anywhere. Pure bliss. For various reasons across time and these examples, unfettered portability never truly emerged.

Now comes WebAssembly. It is the ultimate tabla rasa, a chance to reinvent almost everything we do in compute and infrastructure and create a “write once, run anywhere” paradigm that actually works as promised.

We can only do this if we avoid bogging down Wasm with elements that might make it more usable and familiar in the short term but at great cost later on. If we collectively manage the development of Wasm to keep the core runtime and standards for Wasm interfaces and APIs free of proprietary elements and unnecessary cruft, Wasm might be our best chance for true portability, not only of compute but also of networking and data connectivity.

Why Portability is So Important for Wasm

Portability rhymes with agility and flexibility. It is the flip side of polyglot architectures and applications that enable developers to write in the language of their choice. This minimizes toil, maximizes code reuse, improves security and radically up levels the developer experience. Because the entire idea of Wasm started with flexibility and polyglot capabilities, portability is inextricably linked to the expectations baked into the Wasm ethos. Portability was a big promise of containers and serverless but neither fully delivered on the promise.

Containers offer more portability than application stacks tied to specific compute or hardware platforms. But operating system-level virtualization means containers bundle the entire stack, including networking and OS layers. This is hard to move without considerable tuning. Containers also share a host kernel, which requires additional security configurations that are highly dependent on platform and underlying infrastructure.

While containers make cross-cloud portability easier, they still require underlying containerization software. Chip architectures can also throw sand in the gears. Moving from cloud to cloud may require rebuilding from x86 to Arm64. This is slow and expensive when you then need to use cross-platform build emulators in your pipelines.

Serverless abstracts OS and networking stack, but serverless functions are generally tied to specific cloud providers with underlying proprietary functionality and code. Moving pure functions from one cloud to another is no picnic. Serverless also lacks a robust plug-in interface needed for granular environment control.

Wasm comes without any of this baggage. The Wasm standard at present is designed to run all code the same, regardless of the underlying platform or hardware, in any environment. It’s a runtime first and foremost — bits in, compute and then bits out — with all other functionality applied outside the sandbox via plugins.This simplicity and the open standard approach of Wasm makes it easier to attain massive scale.

How to Safeguard Future-Proof Wasm Portability: Keep it Pure Plug and Play

Wasm today lacks some of the key tooling that developers need to do their jobs. Early Wasm companies recognize this and are creating more developer-friendly Wasm experiences. That sounds good but could confound portability if those environments contain proprietary constraints that force developers to repackage Wasm apps to run elsewhere. Another risk is if core Wasm elements adopt conventions or interfaces to ease the transition from the old compute paradigms, but those measures paradoxically limit portability.

Fortunately, Wasm is actually strongly biased toward the best solution — the plug-in. Wasm plug-ins are already widely used and deployed to add functionality such as reverse proxies, data handling and IDE integration. Just as VSCode has built the biggest and most successful IDE ecosystem on the back of robust plug-in support, Wasm would find the same benefit with plug-in directories, plug-in registries and more.

This sounds simplistic and obvious. But it will work best if we keep the Wasm standard, compilers and all other core Wasm elements exclusively focused on runtime execution and free of additional code and cruft. Specific benefits would include simpler testing, relatively painless dev-to-prod mobility, least-privilege-and-capability security, even more polyglot capabilities, and — of course, total portability.

The balancing act is subtle. Wasm must evolve over time. But the evolution must bias toward external functionality and away from larding the core. Wasm is here, and it’s going to be huge, following in the footsteps of containers. If we stay strong to our principles of simple, contained, lightweight and secure, then Wasm will eclipse containers and possibly everything else, becoming the runtime that runs everywhere on anything. And developers will love it.