Ambassador post by Taylor Thomas, CNCF Ambassador and Director of Engineering at Cosmonic
WebAssembly (Wasm) components are here and already unlocking new computing patterns. Meanwhile, CNCF’s wasmCloud offers Wasm-native orchestration for distributed components—in essence, a Kubernetes for WebAssembly.
That’s great for using components in large-scale production environments, but there’s one question: Why would you want to replace your entire infrastructure? If you’re invested in Kubernetes, you have robust infrastructure management solved, and you’d prefer not to make changes at the node level, much less switch up your orchestrator.
Fortunately, wasmCloud integrates seamlessly with your existing cloud native setup in a quick, non-invasive, Kubernetes-native way. There’s no fiddling with custom node pools or configuration: Kubernetes’ operator pattern gives us a way to treat WebAssembly as more than a runtime and take full advantage of components’ capabilities. With the flexibility of components, we can extend the frontiers of Kubernetes in traditional challenge areas like multi-region, multi-cluster, multi-cloud, and edge environments.
Kubernetes, meet components
WebAssembly components are Wasm binaries that snap together like building blocks, regardless of the language in which they were first written. One service might be written in Go, another in Rust, and another in JavaScript, but they can all communicate with one another over shared APIs. Like any Wasm binary, they can run on any operating system and any architecture.
Components are portable, small (ranging from kilobytes to single-digit megabytes), and packaged as OCI artifacts, so a certain analogy with containers is inevitable. But they’re also something brand new: reusable building blocks written against well-known APIs and interfaces with real multi-language interoperability.
In a world with components, software development becomes much more flexible and platform engineering becomes much less of an exercise in bug-whacking. Developers don’t have to worry about rewriting something for their language of choice and platform engineers have the flexibility to compose their platform in the way that best suits their requirements.
The pluggable nature of components was designed with a cloud native world in mind. In cases where you want to minimize communication over network boundaries, you can compose all those services together into a single binary. In cases where you want to scale (or maintain) those services independently, or services need to run close to distributed data sources, you can run your various components distributedly with wasmCloud, which serves as an orchestrator for WebAssembly components. (Of course, you can run build-time composed components on wasmCloud, too.)
If components are comparable to containers, then wasmCloud is analogous to Kubernetes, providing Wasm-native orchestration so teams can utilize components fully in distributed environments and at scale. The architecture bears some high-level similarities:
- The wasmCloud Application Deployment Manager (wadm) is the system’s orchestration layer and analogous to the Kubernetes scheduler, controller manager, and API server (for a subset of APIs) all in one.
- The control interface for wasmCloud routes messages across the connectivity layer (called the “lattice”), much as the API server acts as Kubernetes’ air-traffic control system.
- wasmCloud’s workloads are components rather than containers in pods, but they are similarly packaged as OCI artifacts (and can therefore be pulled down from the same registries).
- In wasmCloud, the WebAssembly runtime Wasmtime runs components in a given host environment, whereas the Kubelet mediates pod execution on a Kubernetes node.
As with components and containers, there are some important differences: for example, wasmCloud uses the CNCF’s NATS project as a connectivity layer for a “distributed-first” approach, and as a distributed key-value store for state. These characteristics make wasmCloud extremely well-suited to distributing workloads easily and securely across clouds, clusters, and regions‐and Kubernetes’ extensibility means that it’s simple to bring those features to existing cloud native infrastructure using CRDs and the operator pattern.
Multi-cloud, edge, and beyond
By integrating with Kubernetes via the open source wasmcloud-operator, wasmCloud complements and extends Kubernetes in areas that have historically posed challenges like multi-cluster, multi-cloud, and edge. The size and efficiency of both WebAssembly binaries and wasmCloud makes it much more practical to run distributed apps in resource-constrained environments. Meanwhile, the wasmCloud lattice provides a means to not only connect Kubernetes clusters across various clouds or regions, but move mission-critical workloads safely and at scale.
With these tools, it becomes fairly straightforward to architect a “supercluster” composed of smaller clusters, with workloads scheduled to one cluster or another based on region or other criteria. Architectural patterns that were previously highly challenging are first-class use cases with wasmCloud and Kubernetes working together, with no changes to your underlying infrastructure.
With wasmcloud-operator, you can run component workloads exactly the same way you would run anything else in Kubernetes. Moreover, you can deploy wasmCloud application manifests directly with kubectl apply and check the status of wasmCloud apps with kubectl get applications.
The operator is already in use on factory floors. With components, manufacturing analytics company MachineMetrics can process high-frequency data directly on edge devices and stream to the cloud in real-time—running in environments that are highly challenging for containers, and integrating with Kubernetes all the while. MachineMetrics’ Data Platform Team Engineer Jochen Rau notes: “The wasmCloud-operator makes this really simple to manage with our existing tools. We deploy our compute workloads on the lattice on wasmCloud. We’re crossing the boundaries between edge and cloud.”
Conclusion
Components are ushering in a new wave of computing in which new patterns of interoperability and reusability are possible. Kubernetes’ extensibility means that teams who want to start leveraging components right now can do so without changes to their infrastructure—and with integrations for existing cloud-native tooling in areas like policy, observability, and packaging.
You can try out wasmCloud on Kubernetes right now—check out the walkthrough in the wasmCloud documentation. If you’re just getting started with WebAssembly components, the wasmCloud quickstart is a great place to get started. If you’d like to learn more about running components on Kubernetes, or you have questions about the ecosystem, join the wasmCloud Slack.