WebAssembly components offer a new way to deploy microservices and other applications in cloud native environments. This naturally raises the question: is the upstart component out to replace containers? Or is this one of those situations where the apparent rivals need to learn to work together?
For a proper answer, we need to examine the similarities and differences between the two technologies, and then consider how we should understand their respective use-cases—both taken independently or working in tandem.
Then we’ll explore how WebAssembly (Wasm) can extend the frontiers of container orchestration across multiple clouds, edges, and devices.
But first: what is a WebAssembly component, and how does it differ from a container?
What is a WebAssembly component?
WebAssembly is a highly efficient bytecode format that targets a virtual instruction set architecture. When you compile code from the language of your choice to a Wasm binary, you can run that slim binary anywhere you can install a WebAssembly runtime (essentially a tiny virtual machine).
WebAssembly components add a standardized layer of specification over the core Wasm format that makes the binaries…
- Interoperable: Components can import and export functions from other components over language-agnostic interfaces—meaning that a component written in Rust can invoke a function in a component written in Go.
- Composable: Two or more components can be combined into a single component at build-time.
- Introspectable: When a component imports (that is, depends on) functions from another component, that dependency is defined in the binary itself and can be introspected by a system or operator.
💡
The WebAssembly Component Model was introduced with WebAssembly System Interface (WASI) 0.2. Check out this blog for a deeper dive, and Luke Wagner’s WasmCon talk remains a perfect introduction to the concept.
Set alongside containers, a few major distinctions emerge right away:
- Portability: A single component can run anywhere you have a WebAssembly runtime (like Wasmtime) that supports the component specification. You don’t need to build one component per OS per architecture. A single artifact runs everywhere.
- Size: WebAssembly binaries are small—typically ranging from kilobytes to megabytes—so it’s possible to bin pack more workloads on a given piece of hardware.
- Communication: In an orchestrated deployment, containers communicate over network boundaries, and those network communications are often a major source of expense at scale. In any Wasm system that supports components, closely coupled components can be composed together—and in wasmCloud, distributed components can communicate via dynamic runtime links.
Containers versus components by the numbers
At a high level, perhaps the most important distinction is that components abstract the application logic alone.
Even the slimmest distro-less base image includes a bare minimum of libraries that sit between the application and the kernel, and often container images contain much, much more in the way of libraries and utilities. This is great when you want to, say, spin up a standard developer environment in a devcontainer. That’s a use-case that is perfect for containers and doesn’t make sense for components today. Containers are perfect for portable, isolated, reproducible environments.
Components, by contrast, are the right level of abstraction for applications.
Epochs of abstraction
You can think of the timeline of software deployment as epochs of progressive abstraction.
Epochs of abstraction
We started with tightly coupled, monolithic systems. Virtual machines decoupled operating systems from specific hardware, reducing reliance on data centers. Containers emerged as the next level of abstraction, and container orchestrators helped run applications more flexibly and efficiently.
The next layer of abstraction, WebAssembly components, sees applications as collections of interchangeable components, linked at runtime. When built with components, applications are tiny, portable, and polyglot.
Compared to virtual machines, containers introduced an improvement in efficiency, but there are some significant limitations when it comes to orchestrating containers at-scale and on the edge.
Orchestrating efficiency
Kubernetes made the great lift-and-shift to the cloud possible, and is essential for abstracting infrastructure, but isn’t great for running applications without a bunch of additional work. The traditional approach to running containerized applications on Kubernetes faces some significant limitations:
- Edge deployments: Running containers at the edge with Kubernetes is challenging, even with lightweight distributions. The tiniest container is a few MBs, so available resources are occupied simply getting Kubernetes to work.
- Resource efficiency and the price of the cold start problem: Over 80% of container spend is on idle infrastructure (DataDog 2024 State of Cloud). Containerized applications need containers to run persistently to address spikes in traffic, and to meet standard latency expectations. As the statistics show, keeping ‘just in case’ instances running is expensive.
Since components are able to start in milliseconds, they face no such challenges. The first—and likely most common—reason people want to run components is that they dramatically improve resource efficiency wherever there is a reliance on Kubernetes. With components, teams can write code in the language of their choice and run it anywhere, including in places where even containers are impractical.
If an organization is already using Kubernetes, it’s easy to run components on existing clusters with wasmCloud, a WebAssembly orchestrator that runs distributed Wasm applications at scale, either standalone or on Kubernetes itself.
In fact, wasmCloud can help extend Kubernetes to tackle traditional challenge areas like multi-cloud and edges.
WebAssembly + Kubernetes: Cloud native’s new tag team
In an early wasmCloud use case, Adobe capitalized on wasmCloud to prove it could make its Kubernetes estate more efficient. The company has continued to expand its use of Wasm: Engineers from Adobe and Akamai work with wasmCloud to run WebAssembly across cloud services, Kubernetes clusters, and edges.
In industry, MachineMetrics uses wasmCloud to move platform capabilities across edges and clouds with dynamic fault-tolerance. In telecoms, the WebAssembly Canvas TM Forum Catalyst Project has proved the value of replacing Kubernetes with wasmCloud in managing its estate of open APIs, and is now reviewing how wasmCloud can work together with Kubernetes to drive efficiencies.
wasmCloud hosts can run on a Kubernetes cluster or external to it: bare metal, VMs, IoT devices, or pretty much anywhere you want. Regardless of where hosts are running, they can be connected. Kubernetes handles infrastructure management by orchestrating wasmCloud hosts, while wasmCloud handles application-level operations with full support for component capabilities.
💡
Want to try running WebAssembly components on a local kind cluster? See wasmCloud’s Kubernetes guide for simple instructions that should take about 5 minutes.
Come for the efficiency, stay for the flexibility
This separation of concerns—containers and Kubernetes for infrastructure, components and wasmCloud for applications—means that WebAssembly runtime operations are unconstrained by container-centric frameworks and abstractions; wasmCloud can extend Kubernetes to provide new hybrid compute options and expand the frontiers of computing.
This is where Wasm’s paradigm-shifting superpowers come into play. There are serious cost savings to be had by using Wasm for applications, but by adopting wasmCloud, we avoid lock-in to proprietary systems, engineers can use their existing cloud native infrastructure, and we can build with the most powerful and singular features of the WebAssembly component model—composability and standards-based interoperability. When all is said and done, containers and components aren’t rivals at all, but are instead a powerful, flexible team for combating infrastructure inefficiency.
To learn more about running WebAssembly components, wasmCloud, and running Wasm on Kubernetes, check out the wasmCloud Slack or join a weekly wasmCloud community meeting. Hope to see you there!