Member post by Liam Randall, Cosmonic CEO and CNCF Ambassador and Bailey Hayes, Cosmonic CTO, Bytecode Alliance TSC director, and WASI SG co-chair
The advent of containers marked an inflection point for computing in the 21st century—a paradigm shift (per Thomas Kuhn) that gave rise to the entire cloud native landscape. In 2024, the arrival of WebAssembly components represents a new inflection point, and the next paradigm shift is already underway.
Why components are made for the cloud
WebAssembly (Wasm) has been around for about a decade now—much as Linux kernel namespaces were in use for over a decade before the debut of Docker (and 15 years before Kubernetes reached the mainstream). Like the Linux namespace, the core WebAssembly standard has provided a firm foundation to build on.
In the case of Wasm, that means we have a bytecode format and virtual instruction set architecture (ISA) that enable us to compile code from any language to a common standard, without needing to build for a particular kernel or architecture. Over the last decade, Wasm’s flexibility has proven itself not only in the browser, but…pretty much everywhere else as well. Today, Wasm is used every where from Amazon Prime Video to Google Earth to Adobe to telecoms like Orange.
Core Wasm is particularly well-suited to the cloud. In addition to their flexibility, Wasm binaries are tiny, sandboxed, and efficient, allowing for much greater density and speed of download or startup in cloud environments.
WebAssembly components take all of this one step further. (Or many big leaps further, as we’ll see.) Components are WebAssembly binaries conforming to an additional specification called the Component Model. Components bring all the same benefits of ordinary Wasm modules (as the Component Model is built on top of the Core WebAssembly specification), but they are also interoperable and composable with other components:
- Interoperability means that components can communicate over strictly-defined interfaces. There is a common set of standardized interfaces called the WASI, consisting of high-level APIs (at various stages of proposal and standardization) for functionality like HTTP, CLI, blob storage, key-value storage, and much more. Developers can use their favorite libraries in their favorite languages, and once they compile the code to a Wasm component, other components can make use of the functions they expose—regardless of the language and libraries used to write those components.
- Composability means that multiple components can be combined into a single component. Functions exposed (or “exported”) by one component on a given interface can be used (or “imported”) by another component, and those two components can be compiled together into a single binary. For a microservice—or any two pieces talking, really—composition is much more efficient than sending data over a network boundary where calls within a composed component happen with the same process in nanoseconds vs a network request in milliseconds. If you need to link components dynamically, you can achieve a compositional effect with distributed components using an open source transport protocol like wRPC (WIT over RPC).
In short, if core WebAssembly binaries are flat-surfaced, fundamental building blocks, components are studded construction bricks—designed for building sophisticated, interconnected applications in new ways.
If a WASI API doesn’t exist for your use case, no problem—you can write your own interface in the open WebAssembly Interface Type (WIT) interface description language. Open standards make the ecosystem infinitely extensible.
WebAssembly enthusiasts (like us) often share this quote from Docker founder Solomon Hykes:
If WASM+WASI existed in 2008, we wouldn't have needed to create Docker.We love that quote! But if we use it without explaining how components work, we run the risk of obscuring what is so transformative about them. It’s a mistake to think of components as a more efficient alternative to containers. Yes, they are efficient, portable delivery mechanisms for cloud native workloads—but components are also an entirely new paradigm that unlocks entirely new models of computing.
The next wave is already here
The last couple of years have built to a convergence moment in which key pieces have fallen into place (or rather, been wrestled into place by many, many people working across the ecosystem). The most important of these is the release of WASI 0.2 and the Component Model in January 2024. With a common model and common APIs in place, the community has wasted no time building and updating a wide array of open source tools and native support in standard language libraries. For just a handful of examples:
- Wasmtime: Standalone runtime for WebAssembly components
wasm-tools: A multi-functional tool for interacting with components (read WIT interfaces, compose, and more)- wasmCloud: Build and run components anywhere, including edge and distributed environments
wit-deps: Manage WIT dependencies for a component project- WASI Virt: Use composition to virtualize a component within another encapsulating component
Better yet, components increasingly integrate with common cloud native tools and standards:
- OCI has emerged as the standard for packaging components in registries.
- Platforms like wasmCloud integrate with Kubernetes, OpenTelemetry, and Open Policy Agent.
Teams don’t have to start from square one to run components in production, but can use their existing cloud native tooling. For those brand new to components, the community is developing more and more resources like The Component Model Book and WASI.dev.
All the while, the component development experience is growing more and more polished across more and more languages. In the JavaScript ecosystem, jco enables JavaScript developers to write idiomatic code and compile to WebAssembly, while Rustaceans can compile directly to the wasm32-wasip2 target.
Around the world, teams are already unlocking new possibilities with components. In resource-constrained environments like edge devices on factory floors, manufacturing analytics company MachineMetrics is using components to process high-frequency data directly on factory-floor devices and stream it to the cloud in real-time—running in places that containers typically don’t reach, all the while integrating with Kubernetes. Only a handful of months after the release of WASI 0.2, components are already changing what is possible.
Accelerating innovation
Developers—and ecosystems as a whole—don’t necessarily adopt new technologies because they are theoretically more efficient or secure. New ways of working emerge when a technology enables us to be more effective, more productive, more innovative. WebAssembly components are doing just that—breaking down language silos and revealing new opportunities.
Today, we’re about a decade out from the first days of Wasm. In the timeline of containers, this is where we reached an inflection point; the Component Model and WASI 0.2 are ushering in the same sort of paradigm shift. The tooling is there for developers to not just build with WebAssembly, but to be more productive, more effective, and more innovative. The common interfaces of WASI make component development cycles incredibly rapid, and components themselves incredibly flexible. Teams will take components to places that we can’t predict, and from here, the next wave of cloud native computing will only become more transformative.