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.
It may seem odd or counter-intuitive, but most of us within the WebAssembly community are eagerly awaiting the day that WebAssembly becomes "boring". Choosing so-called boring technology is a good, safe bet for building production systems. Boring technology does what it's supposed to, it's easy to work with, it doesn't crash or break down, and has a simple developer experience. This is what we want WebAssembly to be: boring and ubiquitous.
It's hard to believe that wasmCloud has been around for 3 years, and the inspiration and desire even longer.
It was a pleasant, cold winter's day in February of 2016. A friend of mine had sent me an inconspicuous link to an unassuming article. Surely this link would never send me down an inescapable rabbit hole from which I have yet to escape to this day. Surely.
Today we thought we would give you a glimpse of the future of WebAssembly and wasmCloud. As wasmCloud maintainers, we've always had a goal to follow all standards in the WebAssembly community. However, our other goal has been to create a platform on which you could leverage the power of Wasm for real projects. For the last few years, these two goals have been somewhat at odds with one another due to the bleeding-edge nature of Wasm. We've had to bridge the gap between Wasm's current state and the requirements needed to do Something Real™ with it. This is starting to change!
TinyGo is "a Go compiler for small places". It is a language designed specifically to work on embedded systems and WebAssembly. If you squint hard enough, you can almost imagine that WebAssembly is a form of embedded system (it's embedded in a host runtime).
One of the core tenets of wasmCloud has always been that we embrace the specification without doing anything proprietary. In other words, anyone who knows the "wasmCloud ABI" can create actors in any language that compiles to freestanding WebAssembly. While this is technically true, it's certainly a lot easier when we have an easy SDK and code generation support for a language. Using our SDKs gives you a more friendly library while helping insulate your code from changes to the underlying WebAssembly spec.
The newest language in our arsenal is TinyGo.
We spend a lot of time talking about how the wasmCloud capability provider system, from its abstract contracts to the ability to hot-swap providers, is a way to separate non-functional requirements from business logic code. While all of that is true, it's also a fairly enterprisey way to describe it. In this blog post, I'll describe them another way using terms from functional programming.
With the general availability of GitHub Packages container registry, or GHCR for short, an easily accessible Docker registry made its way into the same platform many developers use for version control today. This was great news for containers and simplifying infrastructure, just like Actions greatly simplified workflows on GitHub.
But wait, there's more!