One day I was at lunch with my colleagues, and one of them mentioned that WASM will replace Docker and that Docker is trying to “merge” with it, to avoid being taken over.
He quoted the following:
If WASM+WASI existed in 2008, we wouldn’t have needed to create Docker. That’s how important it is. WebAssembly on the server is the future of computing.
Solomon Hykes (one of the co-founders of Docker)
At that time, I didn’t know anything about WASM, and when he described WASM, it sounded like LLVM, so I decided to look more into it, and its relation with Docker. (now having Docker+WASM as preview)
What is Wasm?
Wasm, short for Web Assembly, started as a way of introducing different languages to the web browser (thus the Web) but is now being considered for general-purpose programming as well. (via WASI – WebAssembly System Interface)
It is a standardized binary instruction format that runs on a WebAssembly virtual machine – similar to Java, Scala and Kotlin, which compile to Java Bytecode and get run in the Java virtual machine.
So instead of compiling code down to the instruction set that the CPU directly executes (ARM, x64, x86, …), it compiles to Wasm, the intermediary language, that Wasm’s virtual machine executes. (and there are a lot of them)
This virtual machine has some restrictions on the code that runs on it, to provide security. (like the apps on our phones, limiting the files it has access to for instance)
Note that this isn’t the same as transpiling code.
What’s the hype around Wasm?
Wasm enables multiple languages to use each other, allowing for better reusability of components, and potentially using the most appropriate language for specific cases.
And, on web development, it allows you to avoid having to write Javascript, yuck!🫢
How does this relate to Docker?
Wasm is hardly a “threat” to Docker.
Docker is very useful, especially in a microservices architecture, it has a big environment around it, and Wasm is still under (active) development.
However, both can work with each other (and are already), since the runtime of Docker can spin up Wasm containers, running in Docker’s engine.
This in turn allows for way faster startup times, lightweight containers (you don’t need the container’s operating system, just the binary and the virtual machine), and building only 1 image, instead of having to build 1 for each architecture.
There is a runtime for Wasm (WasmEdge) which, at the time of writing, claims to be the fastest runtime, and integrates seamlessly with Docker and Kubernetes.
It also natively supports APIs such as Tensorflow (AI) and Tokio (Rust Async).
Conclusion
Docker and Wasm will most certainly be the future, and together.
Imagine your helm apply taking milliseconds to orchestrate your deployment! It’s like Quarkus with GraalVM!
David Gomes 