WebAssembly Components Are Here At Last

The WebAssembly Systems Interface (WASI) standard has reached Preview-2, and WebAssembly platform vendor Cosmonic is among the first to support the standard. At WasmCon this week in Bellevue, WA, Cosmonic announced that developers can use its vendor-neutral, language interoperable, secure and standards-based environment to build distributed applications using the WebAssembly component model today.

“Components are the new containers,” says Liam Randall, founder and CEO of Cosmonic. “Developers are creating language tooling which creates these WebAssembly components that now can be seamlessly adopted and run on any WebAssembly runtime.”

WebAssembly Interface Types (WIT) are what enable components written in different languages to work with each other. It’s a language-agnostic way to define the types of input and output components will accept, providing a common meeting place for every language that supports WIT. It means when a component written in Python outputs a list of integers, a component written in Rust can take that list of integers and understand it in its own native Rust-like way. It’s what gives the component model its power.

“It starts to break down the silos that we have between the various languages. Silos that we might have in Python, or Javascript, or Rust, where we have proprietary SDKs, frameworks, and other things that we want to be able to use together,” said Liam Randall, founder and CEO of Cosmonic.

The component model is also dynamic. Provided the interface is the same, components can be swapped out, on the fly, without interrupting service to the applications that use them. It means an application could switch from a key-value store component written in Rust to one written in Python without changing the code. It becomes a small configuration change in the infrastructure layer. What this enables is incredibly powerful.

Switching from one language to another for a component, while possible, is unlikely to happen often. What will happen often is upgrades to components. Security patching is a prime example. Production applications can be live-migrated to use a new, more secure version of a component without interruption. We can ensure that applications will always connect to the latest, most secure components when they run. We won’t have to rely on developers correctly downloading and linking to a secure version when they build a container or compile a binary.

It also means developers can work with a local version of a component—one that connects to a Redis key-value store on their laptop, say—while they’re developing code. When their application moves through the deployment lifecycle, it can connect to a different datastore for testing, before finally moving into production, without changing the application itself. The environment around the application changes, and the application connects to an environment-appropriate version of the components that it needs, dynamically. The potential productivity, resilience, and security gains here are enormous.

Cosmonic is an early adopter of the new standards, and its Cosmonic PaaS is one of the first platforms to implement the WebAssembly Component Model. I was shown a demonstration of an application moving between environments, and switching backend key-value stores, dynamically in real time. While it’s probably not the right choice for a lot of enterprise applications today, for those with workloads suited to this dynamic and flexible approach, it’s well worth looking at.

I’ve written about the value of the component model before, and it’s excellent to see the promise start to be fulfilled. As I noted then, highly dynamic workloads like AI/ML are a prime use-case for WebAssembly, and the component model is poised for an explosion in adoption. With each additional piece that falls into place, the case for using WebAssembly becomes more and more compelling, and for more than just AI/ML or Functions-as-a-Service. Features like Cosmonic Connect provide a bridge from the old world to the new.

Work continues to stabilize important features in the component model and the WebAssembly Systems Interface, such as threading support, garbage collection, and native asynchronous programming primitives. The Bytecode Alliance has published a roadmap outlining the sequence of events leading to a 1.0 release of the WASI standard.