WebAssembly is going to fundamentally change how we construct systems.

We've gone through many different iterations of system architectures and most recently, many organizations have been settling on microservices to build systems.

How did we get there?

A lot of it comes down to the pitfalls of monolithic systems when it comes to scaling. When implemented properly (which is not nearly as often as we'd like) microservices allow us to scale systems by having well defined, enforceable, boundaries. This (should) give us the ability to release independently, decouple the tech stack and scale utilization efficiently.

But there is a cost to all of this: this method of building component-oriented systems is *incredibly* infrastructure intensive. Most organizations have moved to kubernetes for implementing microservices and that is a whole new level of infrastructure complexity to manage for teams that need to deploy these systems.

So what does WebAssembly (Wasm) have to do with all of this?

WebAssembly is an executable format that allows programs to run on any platform that has a supporting VM (Virtual Machine). Since this includes modern browsers that means everything from desktops to mobile to TVs. WebAssembly can also run on servers and edge devices. It's like the original promise of Java without the heavy weight and the security issues.

So what does this have to do with building systems? It certainly seems nice to have write-once, run anywhere, but we've had that before.

The answer is the WebAssembly Component Model. This model allows several components, written in different languages to run as part of the same program using high level interfaces and well-defined, enforceable, boundaries.

Think about that. You can have a service written with core logic in go and a rust module for http communication and a C module for accessing a database. No complicated deployment coordination, no sidecars, no random OS binaries.

This makes the choice between monoliths and microservices much more balanced. You'll be able to have good boundaries between components either way and choose the deployment model based more relevant needs like resource scaling, resilience, etc.

Is this ready for prime time? Not yet, but this is what we have to look forward to.

Here's an excellent post about the history and evolution of Wasm by Bailey Hayes, CTO of Cosmonic https://cosmonic.com/blog/engineering/evolution-of-wasm-standards-building-the-component-model