Containerless Compute

Imagine you can compile your favorite language to a universal binary instruction set that can run on any device type, from datacenters to Arduinos, at near native speeds (or better), in an environment designed to handle untrusted code. This is the promise (and increasingly the reality) of WebAssembly.

WebAssembly (Wasm) was designed to provide low-level language support for browsers, finally offering an alternative to the Web’s sole programming language, JavaScript. Wasm has been in browsers for a couple years now and will eventually eliminate the distinction between browser-based UIs and client apps. But that pales in comparison to what Wasm will do outside the browser.

Wasm bytecode executes in a stack-based virtual machine. The VM is sandboxed and relies on Javascript glue code for I/O. Currently, in browsers, JS is used to compile and load WASM modules and provide access to the DOM. On the server, new Wasm runtimes and system APIs, like WASI, are being developed, not to run graphics in a Web browser, but to unlock the portable power of the WASM stack machine on the backend. With new runtimes like WasmEdge, Wasm will support server workloads (and do things like open files and write to network sockets) in the same fast, secure, polyglot way it runs high-end graphics (among other things) in browsers. You find support for everything from C++, C#, Go, and Rust toolchains to microcontroller runtimes (wasm3), WASM-powered clouds (wasmCloud) and serverless runtimes (WasmEdge) with cold starts under 30ms.

Okay, so why is this important? Why would Wasm displace container technologies, like Docker, for example? Well, you might have noticed the 30 ms serverless cold start comment above, but more generatlly, in his own words: Solomon Hykes, co-founder of Docker:

If WASM+WASI existed in 2008, we wouldn’t have needed to created Docker. That’s how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let’s hope WASI is up to the task!

Streaming Software

Like Wasm, another Web technology that promises to have a much wider impact than originally intended is module federation . Basically, MF is to software delivery what WASM is to compute delivery. It has the potential to change how software is distributed and managed. Federation rejects the practice of transmitting and storing copies of data, when direct access is more efficient. By extension, federated software is not installed on the server, but streamed over the network as needed. This zero install, browser-like approach to software deployment has many advantages, for example, built-in deployment automation. It also happens to fit the model of WASM software distribution quite nicely, supporting functions like streaming compilation.

Federation also affords new architectural choices when designing cloud-native applications. Using it, we can sidestep certain trade-offs that today severely limit the value we can derive from software. Federation let's us build truly modular, zero-downtime, hot-reloadable software , whose components are designed to be developed by multiple teams and loaded from multiple network locations and repos, but deployed independently to a single application instance. There’s no need to distribute components as standalone executables talking over a network, like today’s microservices; especially if all you’re looking for is deployment independence or polyglossia. Developer autonomy doesn't have to come at the price of operational complexity, like it does today under distributed computing. There are many more advantages to federation. You can read about them here.