When Wasm and Docker Work (and Do Not Work) Together
There’s been a lot of discussions recently about whether or not WebAssembly will eventually replace Docker containers. The comparison is often made about how containers — thanks to their superior portability, resource savings and other attributes — were often touted as one day making VMs obsolete, which they obviously have not.
“Rewind to 2014 for a moment: When containers first got some notice, all the early dialog was about whether they could displace VMs,” Matt Butcher, CEO of Fermyon Technologies, told The New Stack. “What we’ve learned over the years is that the two technologies are more complementary than conflicting.”
While there is some discussion about how Docker containers and Wasm will be complementary, this likely will not be the case on a significant scale. Instead, it looks like Docker will retain a stronghold across a major part of distributed applications while Wasm will carve out an ever-widening swathe of use cases, especially in those instances where Wasm’s perceived security benefits outweigh those of containers and for certain edge and other application use cases.
Overlapping Use Cases
“In the Venn diagram of capabilities, containers and WebAssembly definitely overlap, and in the next few years we will see some struggles to figure out what to do about some of the overlapping cases,” Butcher said. “But the overlap is, in my mind, small. The non-overlapping areas shed light into how these two techs are going to co-evolve.”
However, there are currently a number of overlapping use cases, Jake Levirne, head of product, Docker, said in an email response, who maintains that anyone pondering whether Wasm will one day replace Docker containers is missing the point. Development, testing and deployment toolchains that use Docker make it easier to maintain reproducible pipelines for application delivery regardless of application architecture, Levirne said. “The millions of pre-built Docker images, including thousands of official and verified images, provide a backbone of core services — such as data stores, caches, search and frameworks — that can be used hand-in-hand with Wasm modules,” Levirne said. “Over time, container runtimes and registries will expand to include native Wasm module support. In fact, this is already happening today.”
Strengths and Weaknesses
From the outset, like Docker containers, Wasm has very specific and adaptive computing structures. It can accommodate a number of different programming languages, such as the capability to integrate JavaScript (JS), C++ and Rust in addition to HTML and CSS into a single runtime platform, to execute functions in a binary format. It can be used to support web applications and extend to any edge environment and cloud native platform that runs on a CPU, including service mesh and edge Kubernetes support. Wasm has also been around for a while, before the World Wide Web Consortium (W3C) named it as a web standard in 2019, thus becoming the fourth web standard with HTML, CSS and JavaScript.
The structure and capabilities of Docker containers and containers in general help to explain why there is thus far not a tremendous amount of overlap between competing use cases. Docker and containers are also two options for DevOps among many. There are many different application-compute architectures in use today, such as bare metal, VMs, functions-as-a-service (“FaaS”) and others in addition to containers and Wasm — and “more surely to come,” Levirne said. “Developers will continue to have more flexibility in choosing how they run their code. Containers offer an ability to execute rich applications that use the full breadth of open source and commercial libraries, packages and tools available for Linux today while providing a relatively lightweight isolation capability,” Levirne said. “Wasm offers an even lighter weight approach to isolation but only for certain types of greenfield applications that don’t leverage any of the hundreds of thousands of open source projects that aren’t Wasm-based.”
Containers continue to excel in two cases, and “these cases will likely persist for at least a few years,” Butcher said. “First, containers remain the easiest option for packaging unmodified existing applications. Existing “brownfield” apps are thus much easier to package, distribute, and run as containers,” Butcher said. “Second, databases and persistent data storage will likely be better handled in containers. PostgreSQL, MongoDB, and Redis are all examples of data services that benefit from a traditional server model where a process is started once and run for days, months or even years without interruption — I don’t think that WebAssembly is poised to encroach into those two areas for quite a while, and that is because doing so does not play to Wasm’s strengths.”
Meanwhile, Wasm continues to manifest itself as a worthy alternative that can take advantage of its targeted binary structure in a number of ways. These include how it functions on a CPU level and removes many of the risks associated with vulnerable code in container images, among other touted advantages. To wit, Wasm is an excellent candidate for “what many people refer to as ‘business logic,’ that is to say the application code that comprises a web service product,” Colin Murphy, senior software engineer, Adobe, told The New Stack. In Adobe’s case, this includes the use of Wasm and WASI to allow users to sign a document in Adobe Sign or edit an image in Lightroom. At the same time, Docker will “still be mostly required for everything else,” such as databases, proxies and web servers, which run only NGINX or Apache, Murphy said. “More specifically, this includes anything which does not readily conform to WASI’s capability-based security model,” Murphy said. “Additionally, there are many legacy applications which cannot easily be ported either due to the security model or other limitations of Wasm.”
There are many different ways to extend systems with arbitrary user code, while Wasm is unique in that it provides a portable, safe and secure sandbox capable of running in-process at near-native speed, Bailey Hayes, principal software engineer at SingleStore, said.
“For a database, high performance can only be achieved by avoiding the shortcomings of other solutions, such as data duplication, network communication or inter-process communication,” Hayes said. “This is why we selected Wasm to power our Code Engine in SingleStoreDB.”
Again, security is a main selling point for Wasm. “The primary advantages of wasm over Docker are security, performance, modularity, and size,” Murphy said. “It is also much more rigid in what is allowed.”
Unlike with Docker, “you cannot simply build a massive application, copy it into a container and run it in production,” Murphy said. “There are some benefits to this, as it prevents inefficiencies such as running a JVM with a 128GB heap, but it also makes porting such applications much more difficult. The reason for this is that Wasm is itself a language,” Murphy said. “Although many languages can be compiled to Wasm, they are ultimately limited by the specifications of Wasm, and unfortunately, the applications that are already optimized for containerization and therefore have the least to gain, are the easiest to port. That is to say, applications that are currently compiled and limited in scope.”
Future Now
As mentioned above, it is emerging how Docker containers and Wasm will have very often distinctive use cases. Why would anyone want to develop a workaround to fire up a Kubernetes cluster with a Wasm tool when a container can do the job in minutes is one of many examples. In the future Wasm will see wide-scale adoption due to how most “application and business-logic people write for their companies or their own side projects,” Liam Randall, CEO and co-founder, Cosmonic, said. “Wasm is smaller, truly cross-platform and much lighter weight — allowing you to run it on any device anywhere. Bigger and established tools will likely be run as their own binaries or containers — think things like Nginx, Postgres, Redis and others that are unlikely to derive huge value from compiling to Wasm (at least in the near term),” Randall said. “Also, containers are still a great developer tool for those who need to write an application against something like a database. docker run Postgres will continue to be a great developer experience for the next while. Put another way, in the near term, building applications will be done in Wasm, whereas supporting tools and software will likely be run in containers.”
