Docker recently announced the wasm integration and published a technical preview. Ever since everyone has been wondering what this means and why. And Solomon Hykes, the founder of Docker, tweeted that if Wasm and Wasi existed in 2008, they wouldn't have had to build Docker. Let's understand what this means.

So what is wasm? It is important to understand exactly what Wasm is all on its own. To explain it in the simplest of simplest terms. You have all seen Photoshop, right? I mean, I remember when I first used Photoshop, I had to download this gigabyte-sized application, then go through this hourlong installation process to finally be able to work with it.

Imagine being able to use Photoshop by simply visiting Photoshop Adobe's website. But how exactly can a sophisticated program like Photoshop be run on the web through a browser? Similarly, have you ever considered how browser-based tools like Figma can enable you to design complex wireframes without needing to install or set up anything? Are you curious about the technology behind it? Nowadays, web applications are typically created using HTML, CSS, and JavaScript.

However, limitations exist as JavaScript cannot create tools like Figma or programs like Photoshop or games. To solve this, webassembly comes into play, which is a new type of compilation target for languages like C/C++ or Rust and enables running native apps inside browsers. By compiling native language code to webassembly binary, it can be loaded and run inside the browser along with JavaScript code, using web assembly APIs.

Docker vs wasm

The significant difference between the two is that Docker wraps the program and its dependencies into a single package, while WebAssembly modules and binaries are pre-compiled C, C++, Rust, or Go applications that can be easily executed on a WebAssembly runtime without relying on the host operating system or processor architecture. WebAssembly binaries do not contain any pre-packaged file system or low-level operating system primitives. Instead, the directory, environment variable, clock utility, and system resource are attached to the Wasm module during runtime, facilitated by the WebAssembly system interface (WASI).

From a performance standpoint, WebAssembly binaries start up in milliseconds compared to several seconds for Docker containers. Additionally, WebAssembly modules are only several MBs in size, while container images may be tens or hundreds of MBs at times. WebAssembly is a powerful way to compile and run existing native code written in C, C++, Rust, or Go inside and outside of the browser, and it runs cross-platform, whereas Docker has a limitation on specific CPU architectures or operating systems.

Docker + wasm Integration

Over the last ten years, we have made substantial investments in containers and Docker, including infrastructure such as Swarm and Kubernetes clusters. Rather than abandoning this infrastructure for a new technology known as wasm, we can leverage the benefits of both by integrating Docker with wasm. This integration combines the high performance and security of wasm with Docker's portability, allowing us to run native application code inside a wasm container and share it as a Docker image. By utilizing Docker's ease of building, sharing, and reusing application code, we can efficiently integrate wasm Edge runtime with Docker. This integration can be achieved by using the ContainerD wasm Shim, which is a beta feature currently supported in a special technical preview build of the Docker desktop app.

So the answer to Will wasm replace docker and kubernetes? is No 🎉

In conclusion, while Wasm has some unique advantages, it is unlikely to replace Docker and Kubernetes, but can be used in conjunction with them to provide additional benefits.