Welcome to issue nine of the digest. Browsertech SF is one week away. If you’re in San Francisco, come say hi!
Apropos of Apple’s addition of two new chips to their M2 line, this issue is about how Apple silicon is breaking developer workflows, and why it could be a catalyst for server-side WebAssembly.
The golden age of universal containers is over
In the nine years since Docker was first released, container images have become the default way to package software for deployment on servers.
The core benefit of container images is that they minimize the surface area between a program and the computer it runs on. Rather than depend on certain properties of the system environment they run on (say, libc version), container images bundle up the environment and ship it with the executable as a single artifact. This reduces the headaches that come from trying to run programs with incompatible or complex dependencies.
For most of Docker’s life, developers could take for granted that the image they built on their laptop could be run on most servers, and vice versa. Container images felt universal, at least to developers deploying in Kubernetes clusters and to cloud providers.
Part of the reason for this illusion of universality is that until recently, developer machines and servers both used Intel or AMD processors with the x86-64 instruction set.
Apple threw a wrench in that by switching to their own processor on the ARM architecture. If you build a container image on an M1 chip and run it on a server with an Intel chip, it will sputter out and die. (I’m being a bit dramatic, it will just display a weird error.)
The Docker solution for this is multi-architecture images. Docker’s multi-arch support pre-dates Apple silicon, but was more of a nice-to-have than a necessity. Instead of building your container image once, you build it for each architecture you might want to run it on. The Docker client negotiates with the registry server to pull the right one.
This does work, but it adds a bunch of friction to something that developers used to not think about.
Docker’s embrace of WebAssembly
Over the last few years, WebAssembly (Wasm) has matured as a credible alternative universal runtime for the cloud.
The advantage of Wasm here is that it is not tied to a particular CPU architecture. Wasm defines its own instruction set, which is translated into the host machine’s CPU instructions at runtime.
Docker, for their part, has seen the innovator’s dilemma-type threat of Wasm and embraced it. Even though their Wasm support is in beta, it is already prominently featured on their site, even in the header.
While I think that Docker the company will find ways to monetize their DevOps institutional expertise if the industry embraces WebAssembly, it’s not obvious to me that Docker the product offering makes sense in a Wasm world:
- A lot of the complexity that Docker’s registry infrastructure deals with stems from the fact that container images can be large. Wasm modules tend to be significantly smaller.
- On the runtime side, a lot of the complexity comes from dealing with the surface area of Linux (namespaces, cgroups, etc.), which Wasm’s isolation model replaces.
- Docker Desktop’s primary appeal is running the Docker daemon on non-Linux systems, which Wasm has no equivalent need for.
Wasm’s Fragmentation
I’m excited about the potential of Wasm, but the ecosystem is currently very fragmented. Unlike containers, which can be run interchangeably across multiple container runtimes, Wasm modules are typically not interchangeable yet across runtimes from different vendors.
This is because unlike containers, which have a POSIX(ish) system interface, Wasm doesn’t have an official system interface. Community consensus has emerged around WASI to play that role, but it still lacks basic things, so each vendor fills in the gaps in unique and incompatible ways.
The Wasm Component Model is poised to help here. It provides a common way to specify interfaces such that they can be implemented by multiple runtimes.
My eyes now are on whether vendors find enough common ground for a useful standard interface to emerge. Fortunately, the Wasm ecosystem seems to agree that this would be a good thing. If it doesn’t happen soon, it could kill the momentum fueling Wasm’s recent growth.
Browsertech SF
As I mentioned at the top, one week from today, the Drifting in Space team will be in San Francisco to host our first Browsertech meetup outside of NYC. We have two awesome speakers, Gabriella from Womp and Hamilton from Rill Data, and we’ll show off some new things we’ve been building at Drifting.
Until next time,
Paul
(PS thanks to Alessio for reading a draft of this)