Finding synergy

Over the past 15-20 years in my day-to-day (working) life I’ve been thinking a lot about compute platforms. Starting with hands-on operational experience and learning to operate systems at scale. Also with creating systems architecture and design, which requires a lot of forward thinking and planning. In that work, we usually look at platform aspects in relative isolation. This helps to limit discussion but also can trip you up by overlooking or under-emphasizing significance of some aspects. By virtue of doing this work long enough, over time a bigger picture on the subject matter has emerged/materialized that has really helped me make better decisions. I’d thought I’d take the opportunity to organize my brain a bit on this topic by writing it all(?) down in this post and hopefully share some useful insights.

What is significant to me

When you read the literature on systems architecture, there are so many aspects and viewpoints that are deemed significant to systems and platforms that it is hard to choose. While true, some are more significant than others ;-) and in my case I’ll be looking at how compute is provided to applications.

Isolation

In my opinion, for general compute, the key to be able to run compute well at scale is to have application multi-tenancy with some form of strict shared compute platform isolation. This isolation describes the level of control one has to limit the influence of applications interacting (interfering?) with one another and the interactions with the underlying compute platform.

Prior art

Before diving into history, I want to clarify something upfront. I’ve chosen the term “Prior art” deliberately here, since I think the elegance of these early approaches deserve our due respect and a level of awe for their creators is obliged. Not to flatter them, but to duly recognize the significance of their achievements. When you think about the times these engineers were creating these solutions, the primitive means of working with the systems, the scarcity of hardware they had at their disposal, that is an amazing feat. Our industry does not always recognize these great feats, so I’d like to flip the table on that and show my appreciation.

first steps

The industry has a long history of trying to define approaches to this potential paradoxical requirement by means of software. Since the discovery of the Turing machine, virtualization and emulation have become art-of-the-possible. Originally we only had big computers, where time-sharing is the whole paradigm to help economics and scale compute for organizations across multiple departments and users. The first isolation approaches stems of course from the Unix world, with the development of chroot, process jails, Plan9 namespaces and later Solaris Zones where a combination of process isolation and resource management that is applied to create the illusion for programs that makes them believe they are the only thing in existence. Not to be forgotten, IBM in the early 60s already developed hardware that was capable of supporting full virtualization. With the development of CP/CMS, the machine could provide to run multiple fully virtualized single user environments that each ran their independent copy of CMS.

Compute Diffusion

With the advent of the PC and the diffusion of the compute landscape also different virtualization approaches have emerged. DOS-based systems where by design wholly unsuited to run multi-tasking, multi-user programs. Their primary take was to provide and easy to comprehend single user system experience based on limited compute of the Intel 8086/8088 CPU. Newer generations processors (the 286 and later 386) have nudged the multi-taking ability ahead by addressing memory management (286 protected-mode) and true Virtual machine management (386 VVM, running multiple 8086 virtually). This allowed a few different multi-tasking approaches besides Windows to appear, remember DESQView and OS/2?

How to fix a broken CPU architecture

The thing is, the underlying architecture of the processor still did not allow for proper segregation of sensitive instructions as described by Popek and Goldberg in their seminal paper. For this segregation to work properly each sensitive instruction must be privileged so it traps to the supervisor and can be inspected and adjusted to represent the correct view for the virtual machine making the call (e.g. to hide real hardware state). And thus all solutions were pretty much stuck. In 1999 VMWare broke through this limitation by applying “dynamic binary translation”, which is scanning guest-kernel code in real-time and replacing problematic instructions with safe equivalents and providing a first safe way to virtualize multiple guests on x86 hardware (Awesome!). It took Intel and AMD till 2005 - 2006 to provide their hardware virtualization extensions (VTx and AMD-V) and now make safe virtualization on x86 hardware available to everyone.

Linux arrives

From the get-go Linux has taken a uniquely different approach, very pragmatic, more akin to Unix and provided isolation and virtualization primitives directly built into the kernel. The idea of the kernel interacting with hardware by running hypervisors is key to understand the powerful isolation this brings to every process that interacts through the kernel and the level of control that can be exerted through this. The multi-tenancy capabilities in Linux arrived over time and evolved to what we would call containers. By first adding namespaces for mounting, processes, network and finally namespaces for users, combined with the cgroups resource limit abstractions we see the now obvious power of this architecture appear.

Containers, Portability and Composability

With the rise in popularity of container technology, especially by Docker Containers, the OS virtualization approach has gained a lot of traction, and for good reason. It creates portability by providing an abstraction towards the host that provides compute, although that abstraction is not entirely consistent across different (OS) platforms. The other key winning ingredient is composability and the notion of bundling an application with its OS dependent parts as a layered stack of runtime elements that can be serviced, rebuilt and redeployed as a composable image. This allows for high degree of change absorption in layers without altering others (decoupling), which is handy for maintenance, specifically patching of layers (see Copacetic). The other is for retargeting/adaptation for other host operating systems/environments, which helps tremendously in Application Development and CI/CD scenarios by providing flexibility, see DevContainers.

The current state of play is that an enormous ecosystem of containers and adjacent technology has taken shape and it has been very successful in getting us here, providing general compute.

Declarative boundaries

The obvious question to where we are right now with regards to compute abstractions is to ask: “What’s next or what’s missing?”. The thing that to me stands out the most is that it is really hard to govern what a container can and cannot do on a platform. Basically what and how is a container allowed to interact with the host system. We have a broad range of permissions we can apply, but nothing more fine grained. The reason for wanting to have this is to be able to control what a container can do and nothing more. A true sandbox with explicit permissions to perform I/O across explicit allowed boundaries.

NextGen with Web Assembly Systems Interface

Web Assembly Systems Interface (WASI) is where the declarative boundaries come to life. It is a WebAssembly sandbox for running platform agnostic WebAssembly code, that runs within explicitly declared and allowed I/O boundaries as defined in a manifest. WebAssembly in the past couple of years has initially been viewed as “some gadget to run things really fast in a browser”, but more recently with the addition of WASM components, has been labeled as the next generation MicroVMs. It builds on the Web Assembly Interface Type (WIT) specifications and Binding definitions that jointly combined create a very strong security posture that allows for running untrusted code in a sandbox with confidence.

The WASM / Wasm Component/ WASI ecosystem

The WebAssembly ecosystem is progressing steadily but relatively slowly. It is as of today in no-way on-par or comparable with the container ecosystem but significant progress is being made especially on the standardization front, where W3C working groups are going through the motions of defining web standards to maximize opportunity and interoperability. In the mean time there are working solutions delivered based on the intermediate standards plateaus. What needs to happen to make it even more mainstream is the inclusion of tooling in our everyday toolchains. That is only happening slowly, thus broad adoption is not here yet (but I have high hopes).

Why it ultimately is important to get on the WASM / Wasm Component / WASI bandwagon

The simple answer is: “The ability to run untrusted code with confidence”.

Safe execution environments for AI

Look at what we’re building with all AI tooling, there is lot’s and lot’s of “on-the-fly” generated code executed on request by LLMs. This code has to run in a safe environment without compromising trust-boundaries of the platforms the LLMs themselves run on.

Limit attack surface

Even more, with the advent of Mythos and alike tools, security concerns, especially of containers (the ones you’re running in production now) have become more serious. The ability to declaratively constrain what a guest can do on a platform means we get to have more control over what runs with a strongly limited attack surface. That means it becomes orders of magnitude harder to attack applications running in a container and escalate privileges, simply because the runtime configuration does not allow for that.

Near Native speed

WebAssembly runs at near native speed cross platform, which means there is no virtualization penalty like you have with interpreted languages. Ultimately that means you can either scale the amount of compute you run larger on the same hardware or run it more power efficient, leading to improved TCO.

How to get there

Containers first!

The only viable way I see for teams looking into adopting WASM/WASI is by first adopting compute via containers. It is essential to learn about composition, maintenance and running these things at scale securely before you move on to the next generation platforms. Lear about the toolchains involved, the specifications, interoperability across languages and all the cool features. Learning with tools from a mature ecosystem allow for easier adoption and less falling-down.

Gentle progression, learn-by-doing

Once your compute estate is on containers, start by looking ahead and learn about WASM/Components/WASI. Build a few demo apps, learn about where the tooling is and what the limitations are. Then look into picking a few smaller applications and see if you can build them natively on WASM/WASI using the existing toolchains and specs. As mentioned before, the ecosystem is still evolving and the feature richness you find in the container ecosystem is not there yet. But, when you get to run it, it’s portable, it’s fast, it’s small, it’s secure (if you configure it right). That is a lot of goodness you can harvest while you’re preparing to learn all bout this new, nextGen compute platform!

Closing words

From experience I know it’s expensive and painful not just to have to rethink a compute platform adoption, but also having to go through executing on that change. That journey is riddled with unknowns, frustrations, moments of falling-down and getting-up again. It is expensive, because “why change it when it’s already running well”. These are all true, but… The big assumption is that the World around you does not change and there is no need to become better at defense, sovereignty or anything like that. It is the ostrich sticking it’s head in the sand. I think the World-at-large in 2026 has shown us the need for deliberate action, in not just mentally preparing, but executing on a stronger security posture for all our applications.

Synergy

A note on finding synergy, for those who have not picked it up. the TL;DR; The synergy arises from adopting containers as a platform primitive, that creates the opportunity to, at a later point in time, smoothly adopt an inherently safer and more secure way of providing compute to applications, while along the way learning how to build, secure, operate and deliver applications in a composable manner.