WASM will replace containers

In the year 2030, no one will remember Kubernetes.

Portability

Containers solved a lot of important problems in software development. We had VMs before containers, but they were not as ergonomic to use. The experience of containers was, by comparison, a true delight. Fast(er) builds, near-instant startup, no virtualization, etc.

Now we're in an era where containers are annoying to work with. The promise of DevOps has been eroded by complicated tooling and tight coupling of program-container-linux. In my experience, developers want to write code and ship features to hit their quarterly goals. Learning how to use Docker is a distraction. No one has a goal to "improve Docker build times" unless you're part of the new PlatformOps (formerly DevOps (formerly Ops)) team.

My money is on WebAssembly (WASM) to replace containers. It already has in some places. WebAssembly is a true write-once-run-anywhere experience. (Anywhere that can spin up a V8 engine, which is a lot of places these days.) You can compile several languages into WebAssembly already. Languages that can't be compiled will eventually have their own interpreters compiled to WebAssembly. The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated.

A very obvious argument against WASM succeeding is the Java Virtual Machine (JVM). It's almost exactly the same promise: write once, run anywhere. After all, over 3 billion devices run Java. There are many languages that run on the JVM: Java, Kotlin, Scala, Clojure, Jython, etc. The biggest limitation is that JVM bytecode cannot run in a web browser (RIP Java Applets). Web browsers are a crucial target for app development. Anyone that wants to share code between platforms will avoid the JVM. There is an interesting, slow-moving trend away from the JVM and towards statically compiled binaries. See: GraalVM, Kotlin Native, Scala Native, Jank.

Microservices

In a microservice architecture, you communicate with other services through HTTP or RPC calls, or using a message broker. This decoupling has important tradeoffs. The success of the model suggests most companies find the benefits outweigh the costs. Importantly, it creates strict boundaries between parts of your system. Conway's Law, etc. You don't need network boundaries to create good encapsulation, but it sure helps when you have a lot of developers.

Perhaps the biggest downside is the cost associated with having many small services communicating over a network. Not only do you pay for the bandwidth and resource overhead, but you have to engineer solutions to improve the reliability of each system in the face of network partitions.

With the advent of "serverless" platforms like AWS Lambda, you can take microservices to the extreme: just deploy single functions in the cloud. My favorite serverless model is Cloudflare Workers. If you have one Worker call another Worker, there is no actual network request. Instead, it just calls the Worker code in the same V8 runtime. Meaning you don't pay the cost of a network roundtrip.

Importantly, Cloudflare Workers all run in V8 sandboxes. There are no containers. You have the option of writing your worker in JavaScript/TypeScript, or compiled WASM. A container cannot call another container in the same process. But V8 can. In other words: by deploying WASM in V8 sandboxes, you get all of the developer benefits of microservices with all of the runtime benefits of monoliths. Cloudflare is not the only provider doing this. Wasmer is trying to build a solution in this space as well.

Adoption

WebAssembly is still a young technology. But it's rapidly developing, and support seems to be growing. Maybe it doesn't work for you yet, but keep an eye on it. Try developing on Cloudflare to see what the future looks like. (TV infomercial voice): if you or a loved one are building Docker images, you may be entitled to a better experience.

If you primarily develop in languages like Python, Ruby, or PHP, be patient. I recommend adding a compiled language like Go or Rust to your Golden Path so you can be prepared when the WASM reckoning is upon us.