Wasm Whiplash: WasmCloud's Wild Ride To Standards - Brooks Townsend, Cosmonic

Wasm Whiplash: WasmCloud's Wild Ride To Standards

Speakers: Brooks Townsend, Senior Software Engineer, Cosmonic

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=lrA6gOpLWMw

Overview

In this insightful KubeCon EU talk, "Wasm Whiplash: WasmCloud's Wild Ride To Standards," Brooks Townsend, a Senior Software Engineer at Cosmonic and a maintainer of the CNCF incubating project WASMCloud, recounts the project's five-year journey. The presentation serves as both an informative retrospective on the evolution of server-side WebAssembly (Wasm) and a candid "therapy session" detailing the challenges and lessons learned in building a Wasm-native application platform. Townsend explores WASMCloud's origins, its initial proprietary approaches to solving fundamental Wasm limitations, and its eventual embrace of emerging WebAssembly standards.

The core of the talk highlights WASMCloud's mission: to simplify microservice development by using WebAssembly as the unit of compute, abstracting away boilerplate and platform-specific concerns. Townsend meticulously details the project's early efforts to overcome Wasm's limitations, such as complex data type handling and networking, through custom protocols and IDLs. The narrative culminates in the critical decision to pivot towards community-driven WebAssembly standards like Interface Types and the Component Model, which ultimately enabled WASMCloud 1.0. This strategic shift allowed the project to shed the burden of maintaining "table stakes" infrastructure and instead focus its "innovation tokens" on its unique differentiators, fostering a more collaborative and interoperable Wasm ecosystem.

Background

▶ Watch: Introduction to WasmCloud: WASM native platform (0:00)

WASMCloud's journey began in 2019, originating from Capital One under the initial moniker "Waxo Suit." The project was not conceived merely to leverage WebAssembly as a new technology, but rather to address a pervasive pain point in large enterprise microservice development: the excessive boilerplate and copy-pasted code inherent in traditional container-based architectures. Developers were spending an inordinate amount of time on operational concerns, such as managing open-source dependencies, integrating enterprise-specific logging, and understanding intricate platform details like Kubernetes services, service accounts, and ingresses. This approach led to significant friction; for instance, a vulnerability in a "golden blessed template" would necessitate every application team rebuilding and redeploying their services, a time-consuming and unproductive endeavor.

The founding vision for WASMCloud was to fundamentally change this paradigm. The goal was to ensure that the application code itself—the unique business logic written by developers—was the only thing within the unit of compute. All other concerns, including dependency management, runtime operations, and platform capabilities (like HTTP handling or database connections), would be pushed into the platform layer, managed by platform engineers. This separation would free developers to focus solely on writing features, irrespective of the language, and empower platform teams to provide robust, centrally managed services. The choice of WebAssembly as the unit of compute was a strategic bet, predicated on the belief that Wasm's browser-side successes—its secure sandboxed execution, platform-agnostic tiny binaries, and near-native speed—could translate effectively to server-side microservices.

In 2019, WebAssembly presented a mix of compelling advantages and significant challenges for server-side use. On the positive side, it was an open W3C standard, supported in all major browsers since March 2019 (Wasm 1.0). Its inherent security sandbox, small binary size, and promise of language agnosticism (compiling from any language to the Wasm instruction set) made it an attractive candidate for cloud-native applications. However, the nascent state of server-side Wasm also brought considerable cons. Many existing Wasm libraries were browser-centric, often including JavaScript glue code that was unsuitable for server environments. Critically, the standard Wasm API only supported passing numbers (I32s, I64s, F32s, F64s) between the host (the runtime) and the guest (the Wasm module). This meant complex data types like strings, lists, or arrays could not be directly exchanged, posing a severe limitation for practical application development, especially for networking operations that involve byte streams. While the WebAssembly System Interface (WASI) was emerging to provide POSIX-like system calls for Wasm modules, it initially focused on command-line interface (CLI) applications and file descriptor operations, not the distributed microservice intercommunication that WASMCloud aimed to enable. This foundational limitation forced WASMCloud to initially forge its own path, developing proprietary solutions to bridge the gap between Wasm's raw capabilities and the demands of modern application platforms.

Key Findings

▶ Watch: WasmCloud's core: Isolate application code from platform (3:50)

The central "key finding" presented in this talk is the profound realization that investing in proprietary solutions for "table stakes" problems in a rapidly evolving ecosystem like WebAssembly ultimately hinders progress and fosters fragmentation. WASMCloud's journey, spanning from its inception in 2019 to the launch of WASMCloud 1.0 in 2024, vividly illustrates this point. Initially, the project developed its own binary protocol (YPC), custom Interface Definition Languages (IDLs) like "Whittle," and subsequently adopted other established IDLs like Smithy, all to enable complex data exchange and language-specific SDKs for WebAssembly. While these efforts were technically successful in making WASMCloud functional, they consumed significant "innovation tokens"—a concept introduced by Townsend to represent the finite capacity a project has for unique, non-standard approaches before alienating users or locking them into a platform.

The pivotal insight was that these custom solutions, despite their ingenuity, were solving problems that were better addressed by community-driven standards. The emergence of WASI 2.0, particularly its foundational proposals like Interface Types and the Component Model, provided a standardized, interoperable, and secure way to handle complex data types, generate idiomatic language SDKs, and ensure memory isolation between Wasm components. This represented a critical turning point. WASMCloud's adoption of WASI 0.2 in its 1.0 release allowed the project to deprecate its custom protocols and IDLs, shifting its focus from building foundational plumbing to enhancing its unique differentiators, such as its distributed network capabilities using NATS, loosely coupled contracts, and embedded host runtime. The ultimate finding is a powerful argument for proactive engagement with standards bodies and open-source communities, emphasizing that collaboration on shared infrastructure accelerates innovation for all participants and prevents the ecosystem from being fragmented by competing, proprietary implementations of fundamental functionalities.

Technical Deep Dive

▶ Watch: Benefits of WebAssembly for cloud-native in 2019 (4:20)

WASMCloud's initial technical architecture was a direct response to the limitations of WebAssembly in 2019, particularly the restriction to passing only numbers (I32s, I64s, F32s, F64s) between the Wasm guest and the host runtime. To overcome this, the WASMCloud team devised a custom Foreign Function Interface (FFI) protocol named YPC (likely an acronym or internal name, not explicitly defined in the talk). YPC enabled the host to invoke functions on a Wasm component, passing complex types by serializing them into bytes. The Wasm module would then receive a pointer and a length to read these bytes from shared memory, performing deserialization. Conversely, the Wasm module could respond by writing bytes to memory and passing back a pointer and length for the host to read. This intricate process, while effective, necessitated the development of language-specific SDKs for every target language (Rust, Go, TypeScript, Zig, Swift) to implement this binary protocol and manage memory models consistently.

The challenge of serialization formats quickly arose. Initially, assumptions were made about using JSON or MessagePack, but this meant all components had to adhere to the same format, limiting flexibility. To address this, WASMCloud ventured into Interface Definition Languages (IDLs) and code generation. Their first attempt was a proprietary IDL called "Whittle," which allowed developers to define complex types (e.g., a "hello world" structure) and generate boilerplate code for serialization and deserialization in various language SDKs. However, maintaining a custom IDL, especially for features like recursive types, proved to be a significant burden, requiring constant updates to both the IDL specification and the associated code generators. Recognizing this, the project then transitioned to an established IDL: Smithy. Smithy, used internally by Amazon for defining AWS services, offered a more robust and widely adopted solution, and existing Rust support made it an attractive choice. Despite this, integrating Smithy still required developing and maintaining custom code generation for WASMCloud's specific needs, continuing the cycle of effort on foundational plumbing rather than core innovation.

Beyond these proprietary solutions, WASMCloud built several differentiating features. It established a distributed network of computing using NATS, a CNCF project, to enable seamless communication between Wasm binaries running across various clouds and edge environments, providing automatic failover and location transparency. The platform also introduced loosely coupled contracts, allowing developers to define abstract capabilities (e.g., a key-value store) that could be dynamically swapped at deployment time (e.g., using Redis locally and DynamoDB in production). WASMCloud's host runtime could operate as a standalone binary or be embedded within other systems, supporting flexible deployment models. Other features included a signing mechanism for Wasm components, robust networking capabilities, and a standardized distribution mechanism for Wasm components via OCI registries, aligning with CNCF working group recommendations.

The paradigm shift occurred with the advent of WASI 2.0 and its core proposals: Interface Types and the Component Model.

• Interface Types provide a standard, Wasm-native way to represent and pass complex data types (strings, lists, records, etc.) between a Wasm module and its host. This includes a canonical IDL that inherently understands Wasm's memory model, and it enables language-specific code generation to produce idiomatic types (e.g., a Go slice instead of a raw pointer/length pair). Crucially, Interface Types allow for the creation of standard or custom interfaces (e.g., for CLI execution or HTTP proxying) without altering the core WebAssembly specification.
• The Component Model builds upon Interface Types. It essentially wraps a core WebAssembly module with metadata describing the complex types and functions (imports and exports) that form its API. This model ensures language interoperability and strictly defined interfaces. A key technical advantage of the Component Model is its ability to enable segmented memory, meaning each Wasm component can own its stack and memory space, preventing memory sharing between untrusted pieces of compute and thus upholding the Wasm sandbox's security guarantees.

WASMCloud 1.0, launched in 2024, fully embraced these standards by adopting WASI 0.2 as its supported WebAssembly target. This transition allowed the project to deprecate its custom YPC protocol, Whittle IDL, and Smithy-based code generation, effectively offloading the burden of these "table stakes" problems to the Wasm community. By aligning with standards, WASMCloud could leverage existing tooling and community efforts, freeing its engineering resources to focus on its unique value propositions. The project also integrated other established cloud-native standards, including OpenTelemetry for observability, the Open Application Model (OAM) for declarative application specification, and CloudEvents for informational events, further enhancing its interoperability and adherence to modern best practices. This strategic pivot underscored the importance of community collaboration and standards adoption for long-term project sustainability and ecosystem health.

Demo / Proof of Concept

▶ Watch: Key challenges of WebAssembly for server-side (2019) (5:40)

The speaker explicitly stated at the beginning of the talk, "I actually have no demos for you today. It's my first time ever doing that." Therefore, no demo or proof of concept was presented during this session.

Defensive Implications

▶ Watch: High-level explanation: WebAssembly as guest in VM (6:20)

The narrative of WASMCloud's evolution, particularly its pivot from proprietary solutions to WebAssembly standards, carries significant defensive implications for modern application development.

Firstly, the foundational premise of WASMCloud addresses a critical security vulnerability inherent in traditional microservice architectures: the "golden blessed templates" problem. By bundling all dependencies, operational concerns, and platform knowledge directly into container images, a single vulnerability in a base image or shared library can necessitate widespread rebuilds and redeployments across potentially hundreds of application teams. WASMCloud's approach, which isolates the application's unique business logic (the Wasm module) from its runtime dependencies and platform capabilities, significantly mitigates this risk. Platform teams can manage and update the underlying capabilities (e.g., HTTP servers, database drivers) independently, without requiring application developers to recompile or redeploy their Wasm modules, thereby reducing the blast radius and operational overhead of security patches.

Secondly, WebAssembly itself offers strong defensive characteristics. Its secure sandbox execution ensures that Wasm modules operate in an isolated environment, preventing them from directly accessing the host system's resources or other modules' memory without explicit permissions. This inherent security model is a significant upgrade over traditional binaries, which can pose greater risks if compromised. The platform-agnostic binary nature of Wasm also contributes to defense-in-depth by abstracting away underlying system details, making it harder for attackers to craft platform-specific exploits.

The adoption of Interface Types and, more importantly, the Component Model further enhances security. The Component Model's guarantee of segmented memory is a crucial defensive feature. Unlike earlier Wasm approaches that might rely on shared memory for complex data exchange, the Component Model ensures that each Wasm component operates with its own distinct memory space. This prevents untrusted components from directly manipulating the memory of other components or the host, thereby strengthening the Wasm sandbox and significantly reducing the risk of memory-based attacks, such as buffer overflows or data leakage between components.

Finally, the move away from proprietary protocols and IDLs (like YPC and Whittle) to community-driven standards (WASI, Interface Types, Component Model) has indirect but important defensive benefits. Proprietary protocols can introduce custom attack surfaces that are less scrutinized by the broader security community. By aligning with open standards, WASMCloud benefits from the collective expertise and security review of a wider community, leading to more robust and thoroughly tested interfaces. This reduces the likelihood of undiscovered vulnerabilities in the fundamental communication layers and promotes interoperability, which can simplify security tooling and analysis across the ecosystem. In essence, WASMCloud's evolution demonstrates that embracing standards not only drives innovation but also builds a more secure and resilient application platform.

Key Takeaways

• Prioritize Innovation Tokens: Projects should critically assess where they spend their "innovation tokens," focusing on unique differentiators rather than reinventing "table stakes" infrastructure that can be provided by open standards.
• Embrace Open Standards for Foundational Problems: Building proprietary solutions for common challenges (like complex data exchange or language SDKs) leads to significant maintenance overhead, platform lock-in, and fragmentation within the ecosystem. Adopting standards like WASI, Interface Types, and the Component Model streamlines development and fosters interoperability.
• WebAssembly's Server-Side Potential: WebAssembly offers compelling advantages for cloud-native microservices, including secure sandboxed execution, platform-agnostic tiny binaries, and near-native performance, making it an attractive alternative to containers for specific use cases.
• The Component Model is Transformative: The WebAssembly Component Model, built on Interface Types, is a critical advancement, enabling robust language interoperability, strictly defined interfaces, and enhanced security through segmented memory, fundamentally improving server-side Wasm development.
• Community Engagement is Crucial: Proactive involvement in standards bodies and community groups allows projects to influence the direction of standards, ensure their needs are met, and avoid the costly process of building and later abandoning custom solutions.
• Iterate and Adapt: It's acceptable and often beneficial for projects to "rewrite the whole thing" or pivot their core architecture when new, superior standards emerge. This adaptability allows projects to move further and more efficiently in the long run.

About the Speaker(s)

Brooks Townsend is a Senior Software Engineer at Cosmonic and a dedicated maintainer of WASMCloud, a CNCF incubating project. He has been involved with the WASMCloud project since its inception in 2019, when it originated from Capital One. Townsend is a self-described "huge rust station" (Rust enthusiast) and a proponent of WebAssembly, passionate about its potential to revolutionize microservice development. His experience spans several years of navigating the complexities of server-side WebAssembly, leading him to advocate for the adoption of open standards to build more productive and enjoyable developer experiences.