Skip to main content

wasmCloud 1.0: Build and Run WebAssembly Apps in Production on Any Cloud, Any Edge

· 7 min read

wasmCloud 1.0 banner

We're thrilled to announce the 1.0 release of wasmCloud, the universal application platform hosted by the Cloud Native Computing Foundation (CNCF) that helps you build and run globally distributed WebAssembly applications on any cloud and any edge.

You can try it right now—download the wasmCloud Shell (wash) and dive in to our quickstart.

The 1.0 release is a grand culmination of effort from the 2024 Q1 roadmap which focused primarily on standardization of host control interface and RPC protocols, events, and WebAssembly component support.

When we set down our goals for wasmCloud 1.0, we identified five top features for the project—key promises that we want wasmCloud to fulfill:

  1. Declarative WebAssembly Orchestration
  2. Seamless Distributed Networking
  3. Vendorless Application Components
  4. Completely OTEL Observable
  5. Defense-In-Depth Security By Default

Now that we've reached 1.0, let's check in on each of those features.

Declarative WebAssembly orchestration​

Orchestrating WebAssembly components across distributed environments poses two big challenges:

  1. Orchestrators like Kubernetes aren't particularly well-suited to distributed, heterogenous environments.
  2. Container orchestrators expect everything to act like a container—but components are something fundmentally new.

To leverage the composability and flexibility of components and distribute them across, say, multi-region clusters and edge nodes, wasmCloud needed an orchestrator built from the ground up for the WebAssembly ecosystem and for distributed computing.

That's what we've done with the wasmCloud Application Deployment Manager (Wadm). Wadm delivers the declarative application management experience that cloud engineers expect and automatic, out-of-the-box load balancing, service discovery, and failover for distributed applications. All of this uses the community standard Open Application Model (OAM): if you know how to use a YAML manifest with Kubernetes, you're 99% of the way to using one with Wadm.

Better yet, wasmCloud and Kubernetes integrate seamlessly through the open source wasmCloud-operator, which uses a Kubernetes controller and custom resource definitions (CRDs) to run wasmCloud hosts on Kubernetes. The operator enables you to deploy wasmCloud applications from within your cluster using the Kubernetes tooling you're already using. This way, Kubernetes focuses on what it's good at—infrastructure management—while wasmCloud handles the orchestration of distributed components, throwing the WebAssembly toolbox wide open for developers.

Seamless distributed networking​

wasmCloud hosts can be clustered together with the CNCF project NATS to form a distributed mesh network called a lattice, allowing you to seamlessly distribute applications on any architecture, operating system, virtual or physical machine and communicate like it was running on a single computer.

Whether a component is a serverless function or a microservice, it communicates over common WebAssembly Interface Type (WIT) definitions. Components speak a common language, so combining (or "composing") them is easy. With the 1.0 release, wasmCloud implements a new RPC protocol called wRPC to take this flexibility a step further, delivering the composability of the Component Model—dynamically and at runtime—across the lattice. This will be especially powerful for use-cases like apps comprised of many different services, or apps requiring explicit control over data location.

Vendorless application components​

The WebAssembly ecosystem is bringing us to a world where we can write code once and run it anywhere. The WebAssembly System Interface (WASI) and the Component Model extend the power of Wasm with standard APIs and a spec for compiling WebAssembly code as portable, interoperable, composable components.

The 1.0 release of wasmCloud commits to and standardizes around the Component Model to make your application code truly vendor-neutral. Components built for wasmCloud 1.0 run anywhere that supports WASI 0.2, and any component you've built to target WASI 0.2 is ready to run across distributed environments with wasmCloud.

Since wasmCloud supports custom interfaces written with the community-standard interface description language (IDL) of WIT, your interfaces are vendorless, too: wasmCloud gives developers and platform engineers a stable, vendor-neutral environment to use the WebAssembly ecosystem to the fullest.

Completely OTEL observable​

If you want to use a distributed system like wasmCloud in production, robust observability is essential. The 1.0 release brings the trifecta of traces, logs, and metrics to wasmCloud hosts using the industry-standard OpenTelemetry (OTEL) specification.

Our approach to observability aims to be simple, flexible, and compatible with your existing cloud native tooling. With OTEL as a common standard, observing hosts is a simple matter of connecting to Grafana, Honeycomb, or another backend.

Defense-in-depth security by default​

WebAssembly provides excellent sandboxing by default, and wasmCloud has a strong track record with a successful October 2023 audit from OSTIF and Trail of Bits.

Using components helps us build on this foundation for best-in-class zero-trust security. Components can only use interfaces defined in their WIT, and in wasmCloud, they must be explicitly linked with another component or provider to communicate. Even then, communication is mediated by the wasmCloud RPC protocol.

Finally, wasmCloud 1.0 is committed to extensibility with a policy service API enabling complex policy evaluation using standard cloud native tools like Open Policy Agent.

Migration and compatibility​

For users, 1.0 represents a stable foundation to build on with confidence—and as usual with a major release that means some breaking changes from what came before.

Smithy-generated actors and providers were deprecated in v0.82, and support is officially removed in v1.0.0. If you need help migrating from Smithy interfaces, just reach out on the wasmCloud Slack or on GitHub. We've also dropped the term "actor" itself in favor of "component"—we're building WebAssembly components here, after all, and we want it to be absolutely clear that these are standard WebAssembly components you could pick up and run with any other system that runs components.

The v1.0.0 release of wasmCloud is not compatible over the lattice with previous versions of wasmCloud, wash, or Wadm, owing to the shift to components, WIT interfaces, and a new RPC protocol. For these reasons, it’s recommended to update all wasmCloud hosts that you run to v1.0.0 at the same time. Associated tooling like Wadm should update to at least version v0.11.0 as well in order to match the protocol versions.

Finally, the model for Wadm manifests has changed slightly—see the guide to Migrating from v0.82 for complete instructions.

Next steps​

We couldn't be more excited to see what you build with wasmCloud 1.0. If you want to show off your project, ask questions, or just chat about WebAssembly and wasmCloud, join us on the wasmCloud Slack!