Road to 1.0: wasmCloud Q3/Q4 Retrospective

As core contributors and maintainers of the popular CNCF project, wasmCloud, we’re excited to work towards the next major milestone in the evolution of this awesome community platform. In the next couple of posts, we’ll take a look back at how far we’ve come, and look ahead to what we can expect from wasmCloud 1.0; our standards-led, production-ready release due to be unveiled in early 2024.

Since its early days, wasmCloud has become a destination for cloud native developers. Interest has grown significantly over the last couple of years — the open source project has attracted over 2,300 organization stars and nearly a hundred contributors. Many of these projects are already running in production in industry.

In the last six months alone, innovation has hastened dramatically as the community has swelled and so a huge thank you to all our contributors. We can’t wait to welcome more of you to the community in 2024.

Looking Back at Q3/Q4

It’s important to note, wasmCloud seeks to evolve alongside the WebAssembly ecosystem, adopting standards and best practices as they become available. We strongly believe this is the best way to accomplish our goals as a project. This was the theme of the wasmCloud Roadmap that we published this summer. Let’s take a look at our goals and how we fared:

1. Leverage as many WebAssembly standards as possible (WASI, Wasm components, wasi-cloud). Since we published our roadmap in summer, much of our effort has focused around engineering wasmCloud to leverage WASI Preview 2 and the Component Model. This lets us deprioritize our wasmbus Stable ABI in favor of a common standard, and lets developers get rid of wasmCloud specific dependencies in our projects. As shown in the 29 Nov 2023 community meeting, you can create a component with Bytecode Alliance tooling and run it right in wasmCloud. Goal accomplished.
2. Provide a seamless developer experience for building, testing, and deploying WebAssembly components. wasmCloud has come a long way in terms of developer usability and this will continue to be a focus in the coming months. There are always areas we can improve, but what’s really exciting is how streamlined and rewarding the experience becomes as we adopt a components- and WIT-centric approach. With WIT, the component model inherently strips away much of the complexity of building Wasm components and applications, breaking down language barriers to create true interoperability. We also allow developers to bring their own Wasm components to wasmCloud — a major step forward.
3. Develop the wasmCloud runtime in Rust. Having recently been accepted as ADR-0013, writing a new host runtime in Rust has been instrumental in enabling us to achieve our first goal, to adopt the latest Wasm standards. Essentially, it has permitted us to to compile to many elements we had experimental support for. As a result, we now have support for Wasm components, and core WASI APIs wasi-http-proxy and wasi-cli. We’re also introducing support for custom interfaces defined by WIT, a hard requirement for developers to be able to extend the provided interfaces.
4. Be the best, and most joyful way to build vendor-less components for WebAssembly applications. wasmCloud really is the best way to build a completely vendor-less components for Wasm applications. We absolutely know that the developer experience can be improved and so this continues to be in focus for us ongoing. Having said that, once you’ve built a Wasm application, running it in wasmCloud really is a joyful experience. As a developer, you don’t need to worry about what vendor or SDK will supply the implementation for a capability when you’re building an application. You can also take your application components and distribute them across any infrastructure; all components can communicate as if they are on the same machine. Platform engineers love the ability to run developer applications and manage the underlying requirements, deployment, and implementation at runtime. This is a continual goal, and I’m glad we captured it in our roadmap for the end of this year.

We’ve also continued our dedication to being a cloud native technology with our recent OTEL metrics RFC. By wasmCloud 1.0, we’ll have OTEL metrics, logs, and traces support, in addition to our use of specs like OCI, CloudEvents, and OAM for critical components of our system. We plan to continue to slot right into a cloud native deployment stack, and focus on being a better way to develop applications.

There’s still work to do but the progress made in the last few months alone has made wasmCloud a stable, standards-based and (most importantly) enjoyable way to build and run Wasm applications. In our next post, we’ll look ahead to wasmCloud 1.0 and take a look at our refreshed wasmCloud roadmap. In the meantime, if you’re curious to learn more, join us every Wednesday at 1pm ET for our weekly community meeting. You can check out past recordings and notes here, and join the call on Twitter (X), LinkedIn and YouTube.