WebAssembly Is Poised For An Adoption Explosion

After speaking with Matt Butcher from Fermyon recently I learned a few interesting details about how the WebAssembly ecosystem is developing.

Drawing a few different threads together, as I did previously, I can see WebAssembly taking off for specific types of application development. Let's step through my reasoning, and see if it makes sense.

Developers Hate Infrastructure

Developers hate being forced to deal with infrastructure. They're trying to write code. They don't want to have to make a detour to set up a bunch of infrastructure components before they get started on a project. They don't want to have to think about the details of the computers that their code is running on. Not if they don't have to. I've written about this before.

Virtual machines were one step along this path, and containers are another. Each was different in important ways, but both provided a higher-level abstraction from what was actually going on at a hardware level. "Cloud-native" development and microservices put "services" used to compose an application at the other end of a network call. I don't care how the database works, I just connect to it and store and retrieve data.

Containers made it relatively easy to build stacks of infrastructure on a laptop that look a lot like production. Developers can essentially ship their laptop into production, freeing them from all kinds of coordination challenges that human beings have proven to be fairly terrible at managing.

And so containers are now very popular for developing applications, particularly web applications and microservices. New developers learn these techniques rather than older ones focused on bare metal or VMs. There is a whole self-reinforcing ecosystem centred on containers that isn't going away anytime soon.

Building on Top

Containerd has added a Wasm runtime (using WASI) so Wasm is now a container type. Docker has also started adding support for Wasm.

This makes the entire container ecosystem available to Wasm code, which is a big deal. If Wasm containers look and feel like regular containers, you can drop Wasm applications straight into existing Kubernetes clusters and get all the same benefits (and downsides) you currently enjoy from Kubernetes. Or any other container orchestration method.

This may not be the most elegant or efficient way of running Wasm applications on actual hardware, but that doesn't really matter very much for adoption. Technology adoption isn't a maximising situation, it's a satisficing situation. Wasm containers just need to be better enough on some set of criteria that people will want to use them.

Not all of the time. Not at first. But sometimes. And then more often if Wasm proves to be more generally useful. Extending from the core set of use-cases into adjacent ones, gaining more functionality and providing more benefits with each step.

I would argue that Wasm looks like it is already good enough for plenty of common use cases, and will likely get even more so, quite quickly.

Better Enough

Wasm containers are small. The Python docker+wasm container image from VMware is under 10 MB. A Linux alpine+Python container image is more like 250 MB, so Wasm containers are about one order of magnitude smaller, which is a lot. Particularly if you have a lot of containers. The network bandwidth and storage savings would be substantial.

Wasm containers are also fast. The startup time for a container is about a millisecond. Lambda function VMs in AWS with SnapStart (the fastest way to run Lambdas at the moment) take about 200ms to start. If you have a lot of invocations of short-lived processes, Wasm is looking pretty compelling.

And because Wasm containers are small, you can fit a lot more of them into the same infrastructure. Developers might not want to care all that much about infrastructure, but if you can do more with what you already have, that postpones having to think about infrastructure for a while. You don't have to worry so much about going over budget, or having to request more capacity from IT or whoever is in charge of such things where you work.

That's also good for IT or the CFO or whoever is worried about the devs blowing up the budget with proliferating containers. If they switch from regular containers to Wasm containers, it should take longer to use up the allocation of compute and memory that already exists.

Given the current economic climate, doing more with what you already have is likely to get more attention than when money is cheap and resources seem endlessly abundant. Hitch Wasm to the current "saving money" desires of executives, and business cases will start getting approved left, right, and centre.

Thanks to the Jevons paradox, that means there's a big temptation to use Wasm containers even more than regular containers. Just like we saw with the switch from physical servers to VMs (VM sprawl), and then from VMs to containers (container sprawl). I fully expect to be reading lamentations about Wasm sprawl in a few years.

Looking Ahead

If this logic is sound, we can have a fair bit of confidence about where Wasm will lead us, because it will follow the same rough path that VMs and containers did. And that means we can anticipate those events and start preparing now.

If Wasm sprawl will become a thing, we can expect the rise of tools to manage that sprawl. Wasm component registries and asset management. Wasm component orchestration. Wasm component lifecycle management. And so on.

The biggest problem Wasm faces is the same as any new technology: it can't be too new or people will have to change too much about what they're already doing to adopt it. That takes a long time. But if adoption means changing very little, and reaping large benefits from making those few, small changes, adoption should explode. PivotNine believes Wasm is being incorporated into existing ways of working sufficiently well that an explosion in adoption is more likely than not.

PivotNine's research indicates that VMs are still the dominant way applications are run in production in the enterprise, but the trend is very much moving towards containers. Around 60% of organisations are using containers in some way, partly for internal application development, and partly because external third-parties use containers and enterprises want to use those apps or services. Container adoption is almost inevitable because everyone else is doing it, following the usual S-shaped adoption curve we see with almost every other technology.

By attaching itself to this existing, well-advanced trend, Wasm gets an almost free boost. We think it will suddenly be everywhere, seemingly overnight, probably within the next two years.

Let's check back in 2025 and see how wrong we were.