Suppose you're developing an application as a WebAssembly component, and you need access to environment variables—but your app will run in an environment where this is impossible. What do you do? The WebAssembly ecosystem provides a powerful command-line tool for this and similar use-cases called WASI Virt, enabling you to encapsulate components within other components and abstract away requirements, or otherwise consolidate your application.

In this blog, we'll explore how component virtualization works, when you might want to use WASI Virt, and how to get started.

The advent of containers marked an inflection point for computing in the 21st century—a paradigm shift (per Thomas Kuhn) that gave rise to the entire cloud native landscape. In 2024, the arrival of WebAssembly components represents a new inflection point, and the next paradigm shift is already underway.

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.

It's a milestone day for Gophers and WebAssembly: the wasi-preview-2 feature branch of TinyGo has landed in TinyGo's dev branch, bringing WASI P2 support to TinyGo! Now developers can write idiomatic Go code and compile to the wasip2 target, creating Go-based WebAssembly components straight from the TinyGo CLI. From there, components can run anywhere that supports WASI P2, with all of the portability, interoperability, and composability that WebAssembly components bring to bear.

Our recent update to the Go Provider SDK brings the library up-to-date for wasmCloud 1.0, making it possible for Gophers to build custom wasmCloud capability providers that communicate with components over WebAssembly Interface Type (WIT) interfaces. In this post, we'll explore how you can get started writing wasmCloud 1.0 providers in Go.

Earlier this year we shared how a group of international CSPs (communication service providers) and their partners brought Wasm to telecoms. WebAssembly Canvas Phase I a TM Forum Catalyst Project, was an early PoC that evaluated whether wasmCloud, a CNCF sandbox project, could be a credible alternative to Kubernetes in managing TM Forum's estate of open APIs. Referred to as Open Digital Architecture (ODA) components, these open APIs are currently managed and maintained in ODA Canvas, an ODA repository built on Kubernetes.

We built wasmCloud 1.0 on a conviction that with the right tools and the right standards, WebAssembly components could help developers reuse code—regardless of the language it was written in—and build applications much more efficiently, then deploy and distribute those applications anywhere. But I have to admit that on the developer side, I've been surprised by just how much components and well-known interfaces can speed up development.

In wash v0.28, we introduced wash plugins: a simple system for extending the wasmCloud Shell (wash) CLI with WebAssembly components. Users can install plugins from OCI registries, local files, or over HTTP, then execute the plugin as a subcommand to wash. Plugin developers simply build a given piece of CLI functionality as a component.

In this post, we'll show you how to install your first plugin. In themselves, plugins represent powerful, versatile tools that will accelerate workflows and help developers tailor tooling to their needs. But wash plugins are also a great example of how modular CLIs can be implemented with WebAssembly—and how components can accelerate development across a team.

Hey wasmCloud Community!

We wanted to give you an update on our journey toward Incubating status with the Cloud Native Computing Foundation (CNCF). As long-time users might have noticed, the process is taking a little longer than we initially anticipated, but there's a good reason for the delay. The CNCF Technical Oversight Committee (TOC) has been hard at work streamlining the entire incubation process, and we're one of the first projects to go through the updated version. A smoother incubation process will be a huge win for the broader CNCF community, and we thought it would be worthwhile to highlight some of the benefits we've seen.

A couple weekends ago I found myself wanting to write a Discord bot: specifically, a simple bot that I could tag with a message to trigger some processing and a response message. As I started thinking about what this bot could do, I realized this was an excellent use-case for a provider: instead of writing a one-off bot, I could create a reusable provider that would make it trivial to build any Discord bot I wanted.

The Discord API is fully-featured and massive, but for such a simple use-case, it would be overkill to work from scratch every time you wanted to write a bot. With a custom provider, I could simply write a component in any language and then plug it in to my provider via a simple API.

In this post, I'll retrace my steps to implement the custom provider using the wasmcloud-messaging interface, and show you how you can use the provider to write Discord bots of your own.