wasmCloud uses GitHub actions to publish all of its example WebAssembly modules and first-party capability providers to AzureCR. Neither of these are actual containers, nevertheless they conform to the OCI image specification and can be distributed well with the existing OCI tooling in the cloud native ecosystem.
The first thing people need to learn when encountering WebAssembly for the first time is how to interact with the code inside the module. There are a number of patterns available for this and, in this blog post, I'll cover the main three: Command, Reactor, and Library.
When we model data structures and encode business logic into our applications, we generally use either a functional programming model or an object-oriented one. In a single process, this choice can be a matter of personal preference, but in distributed systems this choice can actually have significant impact.
The world of WebAssembly (Wasm) runtimes has evolved quickly over the last couple of years. In this short update, we'll cover the factors that drove us to transition to Wasmtime as the most natural choice to underpin wasmCloud.
We should always plan to take advantage of the benefits and clarity offered by hindsight, reflection, and learning from what came before. In this post, we take a look back at where we started, where we've been, and take a peek at where we're going.
The actor model is a model for concurrent computation originally developed in 1973. This classic definition says that in response to a message, an actor may:
I recently gave a talk at CNCF Security Conference North America on the subject of zero trust computing. In this post I'll provide an overview of the material from that talk, discussing how zero trust computing is supported at the module, runtime, capability, and cluster levels.
Born out of pizza-fueled build nights, Adobe’s Ethos project emerged from a desire to find better ways to ship cloud software. Focusing around containers, we first worked to port an exact replica of the developer's local environment in the cloud. Next we created a standardized environment in which to run our software – a basic clusterization model. By building a centralized infrastructure platform, we could solve some developer pain and create economies of scale in efficiency, security, and operations. Fast forward eight years, and Adobe’s Ethos platform runs more than 90% of Adobe's containers on Kubernetes, powering diverse applications across many different business units.
The first claim we make about wasmCloud on our documentation site is: "wasmCloud is a distributed platform..." The best definition I could find, on Wikipedia of course, is:
Distributed computing is a field of computer science that studies distributed systems. A distributed system is a system whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another from any system.
This post explores the motivation and design behind the loose coupling between our actors and capabilities.
Developers have a number of creeds to which we hold dear. Sometimes these show up as pattern and practice recommendations. Sometimes they appear in blog posts, conference talks, or streams. They can also appear indirectly via the code we write. One such creed is the tenet of loose coupling. Everything needs to be loosely coupled, because we all known and preach that tight coupling is objectively bad. Everyone seems to know this, but we rarely stop to think about why.