Engineering @ Cosmonic

An examination of how wasifills—a component adapter pattern like polyfills, but for components—can help bridge the gap between today's rapidly changing standards landscape and the future of interoperable components facilitated with wit and wit worlds. It's an amazing time to be on the bleeding edge of the WebAssembly adoption curve, but it's not without risk.

At the Pasadena leg of Kubernetes Community Days (co-located with SCaLE 20x), I had the chance to talk to 100 or so Kubernetes enthusiasts, to give my perspective on WebAssembly, through the lens of a Kubernetes veteran.

There are several new standardization efforts happening within the WebAssembly (Wasm) space, including what we believe to be a new way to write software applications. By way of describing this new model, I would like to dive into some of the history of Wasm as a way to describe where we are heading.

An engineer begins her Monday, sitting down at her desk with a cup of coffee. She's feeling productive, inspired, and ready to write some good code. She opens her GitHub inbox to find 42 notifications on her projects, like this one:

⚠️ CRITICAL VULNERABILITY: Upgrade garbodep from 1.1.12 to 1.1.13

"What's garbodep? I don't even directly depend on that, why am I getting notified for this?" And so, her day begins.

My list of projects and technologies to get into the lab for learning and experimentation is never-ending. However, this holiday gave me just enough time to take another look at Microsoft Orleans, a technological kindred spirit with wasmCloud.

With the recent release of the .NET Framework 7, I thought it might be a good excuse to check back in on the .NET WebAssembly ecosystem and see where things stand and what improvements have been made.

From the beginning of our days developing wasmCloud, we took a stance to be compatible with today's technology without being dependent on it. So, wasmCloud needed to be able to:

• Run inside or outside of a container
• Run inside of Kubernetes or another orchestrator and run without it
• Run on Linux, but also support Mac and Windows (and not just WSL)
• Etc

There is a special kind of pride that comes from the exhaustion at the end of a hard day's work. Whether we spend our days laying bricks, pouring concrete, mowing lawns, cooking hamburgers, or smashing rocks; our exhaustion is proof that we've done work. The well-earned rest after all that work feels good.

What if our goal wasn't just to smash rocks, but instead to find some tiny nugget of value inside just a small fraction of the rocks? With that goal in mind, does it still make sense to spend our days smashing every rock we see with a hammer, or is there a better, more focused approach?

One of the things we've run into as we've worked with customers and developed our own examples at Cosmonic is the need to serve UIs that are consuming services you are running inside of wasmCloud. Our own examples required you to either run the UI using npm or to run a docker image. This felt less than ideal and didn't fit with our vision of WebAssembly being the future of distributed computing.

We just released a new version of the petclinic example that demonstrates how you can bundle up a UI for your application into a single actor. Now when you start the full petclinic example, the API and UI are served from the same place