Engineering @ Cosmonic

Cross-posted from the wasmCloud blog.

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.

Cross-posted from the wasmCloud blog.

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.

Cross-posted from the wasmCloud blog.

SEATTLE, (Open Source Summit), April 16, 2024. In response to growing demand among engineers for more open and community-led ways to bring the benefits of WebAssembly (Wasm) to Kubernetes, Cosmonic has contributed its Kubernetes operator to the CNCF wasmCloud ecosystem. The wasmCloud-operator (formerly known as Cosmonic Connect Kubernetes), allows Kubernetes practitioners free and unfettered access to wasmCloud in their own Kubernetes clusters, deployed and managed with the tools they know and trust.

• Brings WASI 0.2 and components to production environments
• Meet wRPC: a protocol for composing components over distributed networks
• wash build components in Python, JavaScript, .NET, C++, and more

WASI Preview 2 officially launched! After a vote in the WASI Subgroup of the W3C WebAssembly Community Group, the standard set of interfaces included in the launch of Preview 2, aka WASI 0.2.0, is ready for use by library implementers. We've been closely tracking the different release candidates of WASI 0.2.0 over the last 6 months, and wasmCloud will update its runtime WIT definitions to the pinned versions in just a few days.

As core contributors of CNCF Sandbox Project wasmCloud, it's always exciting to see specific industries prove that Wasm can bring real-world benefits and efficiencies. In particular, we love seeing how Wasm can compliment existing technologies—our work with Adobe is a great example of how wasmCloud can enhance Kubernetes infrastructures. On the reverse side of the same coin, a new use case, developed within the operations and services (OSS/BSS) side of the telecoms industry, has revealed the potential of Wasm as a replacement for Kubernetes.

• Seamlessly operate WebAssembly across any K8s distribution via GitOps pipeline
• Orchestrate CNCF wasmCloud across K8s with Kubernetes Custom Resource Definition (CRD)
• Wadm supercharges Cosmonic Connect Kubernetes to create new Kubernetes controller

If you’ve been following anything in the Cloud Native space right now, chances are that you’ve heard of WebAssembly (Wasm). As someone who works at a Wasm company, it should come as no surprise that I think Wasm is the future of software development. But, let’s be honest, you probably aren’t going to just dismiss Kubernetes and go all-in on the first Wasm-related project you find.

At Cosmonic, we’ve always believed it important that Wasm and wasmCloud (the soon-to-be incubating CNCF project we contribute to and help maintain) are compatible with, but not dependent on any pre-existing technology. Guided by that principle, we have long provided integrations with Kubernetes, as most people operating in the cloud native ecosystem are running in or integrated with it. What has been interesting to see is how people are choosing to integrate with it. This post outlines a couple of ways to integrate Wasm with Kubernetes, and it gives a clue as to why we’ve designed our platform to integrate with Kubernetes the way it does. With that in mind, let’s dive in!

WIT, or Wasm Interface Types, allows WebAssembly modules to communicate with each other using complex data types. WIT is a language agnostic interface definition language (IDL) that enables composing WebAssembly components, regardless of source language, using language-specific bindings. If you're using a WIT-generated set of language bindings it will feel just like using a regular language SDK. If you're writing your own WIT, then this guide is for you!

Making sure that the team has a holistic view of the event flows throughout an application while still being able to synchronize code, schemas, and documentation is probably harder than actually writing the code.