Why WebAssembly Is Becoming the Next Cloud-Native Runtime

It only takes a few seconds for a container to boot, which is fine if you expect your app to be up and running for hours, days, or months. But what if your workload is going to appear, do its job, vanish, and then repeat that a thousand times a day?

That is one reason why WebAssembly, or Wasm, is getting attention outside of the browser. It was originally designed to let apps run safely within web pages, but it has now become a portable execution format that can run anywhere from the server to the edge to the cloud. Its small size, fast startup time, and sandboxed nature are appealing in scenarios where the container may be more machinery than the workload requires.

An important point to note is that Wasm isn’t replacing containers in any way. What it does do is give cloud-native platform developers another runtime to choose from, allowing them to select the most appropriate one for their workloads.

The container isn’t always the right unit

Now, while containers did make applications easier to package, and Kubernetes enabled us to run them at scale, containers ship with the entire OS userspace bundled inside. This gives them flexibility, but it also adds a memory footprint and startup cost that may be unnecessary for lightweight, short-lived workloads.

Wasm works differently. As opposed to bundling up an app with a complete userspace, Wasm runs modules inside a runtime, which provides a constrained execution environment. It features a binary instruction format that’s designed to run on a stack-based VM. This results in a much smaller footprint, with a much quicker startup time, making it ideal for use cases such as serverless functions, edge computing, and apps that need to scale quickly.

WebAssembly has left the browser

One of the biggest changes in the Wasm ecosystem is that developers don’t need a browser anymore to use it.

WASI is adding new capabilities to WebAssembly that go beyond the browser, adding standardized interfaces for modules to interact with outside resources. At the same time, the WebAssembly Component Model offers a mechanism for individual components built independently to talk to each other using well-defined interfaces.

The runtime is the abstraction here.

This is especially useful when dealing with multi-cloud, data center, and edge environments. Rather than maintaining separate binaries and execution environments for all of the targets, developers can just build out the app in Wasm and use any compatible runtime to handle the execution environment.

The ecosystem is still maturing, but the trajectory is clear: Wasm is transitioning from being something used to run browser code to being a method of running software in a portable way.

Kubernetes doesn’t have to go anywhere

Again, Wasm’s emergence doesn’t mean that Kubernetes is going away. If anything, Kubernetes is one of the places that Wasm can become interesting.

They exist on different layers. Kubernetes takes care of scheduling and management of the workload, along with the rest of the infrastructure. A Wasm runtime decides how a specific app or piece of software runs. The CNCF has already looked at these two technologies together in production, stating they are compatible and not competing. This means you can have a mix, where certain parts of your application run as containers, and others run as Wasm modules.

The sandbox is part of the appeal

Performance isn’t the only thing that makes Wasm exciting. Security is also very relevant here. Wasm is run within a sandbox, so it doesn’t have full access to the underlying machine. What it gets access to depends on what the runtime lets it see. This is extremely helpful if you want to run code that you don’t trust or that isn’t yours, such as customer code or plugins from third parties. Shopify uses WebAssembly to run code in situations where isolation and portability are important, which shows that there are valid uses beyond proof-of-concept testing.

Sandboxing doesn’t, however, mean everything is automatically secure. You still have to configure the Wasm runtime properly, ensure you use secure coding practices, and handle identity and access management. The advantage is that the runtime offers an extra layer of isolation around the code that’s running. For multi-tenanted applications, plugin frameworks, and edge compute platforms, that extra layer of isolation can be particularly helpful.

Where Wasm actually makes sense

Most compelling uses for Wasm share one common trait: they rely on small, portable, isolated, and/or short-lived workloads. Serverless functions are an obvious use case, as are edge applications that need to run near the user without requiring a huge footprint. API gateways and proxies might use Wasm to be extensible. Authorization systems might want to deploy their policies into multiple places.

Kubernetes-based serverless deployments are another emerging use case, especially if you care about quick startup times and using resources efficiently. 

The choice of a runtime

In conclusion, Wasm is most interesting when you want to run a lot of small bits of code, securely, over and over again. So while cloud native, containers, and Kubernetes have made our infrastructure portable and standardized, WebAssembly could take it a step further by making the runtime less tied to the infrastructure.

Of course, that doesn’t mean every app needs to be rewritten in Wasm; a lot of workloads will continue to be better off running in containers, especially those that rely on OS-level features or existing container tooling.

That being said. cloud native has never been about forcing all your workloads into the same shape. Instead, its whole purpose has always been to give you an abstraction that lets you choose how software runs. And Wasm really does fit in very nicely with that philosophy.