Docker Gets up to Speed for WebAssembly
For those who still are looking to discuss whether WebAssembly (Wasm) will replace containers and even Kubernetes is missing the point. Both are very different, yet important technologies. And even though there are some overlapping purposes they also often serve specific and separate needs.
At least in the immediate future, many organizations will be loath to replace their container infrastructure and Kubernetes environments. Besides likely losing their investments in those by replacing them with WebAssembly, WebAssembly is not a replace-all technology for all containerized environments. Comparisons between containers and Wasm and how Docker will continue to support containerized infrastructures when Wasm is in use was one of the many main talking points during Wasm I/O 2023.
During the course of the week of the conference, Docker made a series of announcements about how it will accommodate and extend support for WebAssembly. How both will work together and especially how Docker is used with containers to allow for them to deploy and manage applications with WebAssembly were often discussed. These adaptations are largely seen as necessary to pave the way for Wasm’s adoption and use with containers and Kubernetes.
Docker sees Wasm as a complementary technology to Linux containers where developers “can choose which technology they use (or both) depending on the use case, Michael Irwin, senior manager of developer relations, wrote in a blog post. “As the community explores what’s possible with Wasm, we want to help make Wasm applications easier to develop, build, and run using the experience and tools you know and love,” Irwin wrote.
Indeed, Docker has made and continues to make progress as it seeks to support Wasm. Following its October release of Docker+Wasm and after joining Bytecode Alliance for Wasm and WebAssembly System Interface (WASI) development, Docker released Wasm runtimes at the same time as this month’s Wasm I/O 2023:
The three new runtimes use the runwasi library. It is used to create the namespaces, configure the networks and other workload tasks that Containerd manages for deployment of the Wasm module.
Given Wasm’s likely importance for a wave of deployments and use cases we will likely see in the new future, it is up to Docker to continue widening its support. Docker is motivated to do this since “The Docker Desktop key value proposition focuses on developer productivity,” Torsten Volk, an analyst at Enterprise Management Associates (EMA), said. “Wasm simply constitutes another deployment target for Docker Desktop, in addition to standard Linux containers. As was the case many years ago with Linux containers, Docker has now set out to simplify the adoption of Wasm, an application runtime that has the potential to save significant developer cycles by consistently running the same code on any infrastructure,” Volk said. “This lets developers worry about code, while platform engineers can take care of the scalability and resiliency of the underlying servers, network, and storage resources. Making this capability available to its user community definitely adds to the appeal of Docker Desktop.”
Bringing containers and WebAssembly closer “will benefit everyone,” Djordje Lukic, a software staff engineer for Docker, said during Wasm I/O 2023. “WebAssembly can make use of all the existing infrastructure for building and delivering the workloads…and adding WebAssembly features to container orchestrators makes them a great choice for running workloads where performance and a small footprint is paramount,” Lukic said.
Wasm and Docker Action
Announcements are often interesting but they are not worth much when the technology is not ready. That concern about Docker’s announcement was allayed during the talk “Containers Deep Dive” and demo that Djordje Lukic, a software staff engineer for Docker, during Wasm I/O 2023, gave. During his talk, Lukic demoed running a WebAssembly module locally using Docker and containerd (a container runtime) and running the module in the cloud on a Kubernetes cluster. The demo covered “what it takes” for a container runtime to be able to run a Wasm module, and the benefits of this approach, including faster startup times, security guarantees and easy integration into multi-tier services, Lukic said.
During his demo, Lukic ran a Wasm module with Docker inside Kubernetes. He showed the Kubernetes cluster running on the Docker desktop. We can see in the images below show Kubernetes and a pod running, as well as the definition of the Wasm module. “What it’s saying is okay, I have a deployment;” Lukic said:
As mentioned above, Wasm and Docker and containers, in general, both often serve very well specific functionalities. “I think containers versus WebAssembly is really about how you want to build your applications,” Kate Goldenring, senior software engineer, at Fermyon, said during the panel discussion “Containers vs. WebAssembly: What’s the Difference and Which Should I Use?.” “If you’re interested in serverless event-driven applications, WebAssembly is there for you. If you’re interested in continuing with the microservices architecture you have today — such as using Kubernetes even if WebAssembly is next to it — is an option.”
Daniel Lopez Ridruejo, a senior director at VMware and CEO of Bitnami before VMware acquired it in 2019, said during the panel discussion that he both agreed and disagreed with Goldenring’s statement. While “most containers in the world running Kubernetes are running virtual machines,” there is much activity around engineering how to run WebAssembly on containers on Kubernetes, he said. “But what I’m particularly excited about is and through your work and Microsoft pioneers and this is how you run this on IoT devices: how you actually get rid of containers and get rid of VMs and can have that unit of portability on devices that you will not typically associate with running software,” Ridruejo said. “In a way, you can think of this as a wave…that I think it’s going to be disruptive once you can put compute and standardized compute in devices.”
Serverless has not lived up to its earlier promise of allowing for the deployment and management of applications with a minimal amount of operations required to support them. To this end, WebAssembly providers are speeding ahead to fill shortcomings in these serverless applications. Recent examples include Fermyon’s release of open source Spin 1.0 which is geared for serverless. Meanwhile, containers and Docker will likely remain part of the equation for serverless deployments with WebAssembly. Fermyon and other companies working on Wasm for serverless are focusing on speed of deployments for the management of modules, Shivay Lamba, a software developer specializing in DevOps, machine learning and full stack development, said during the panel discussion. “That helps you to save costs as well. So, if you have such use cases where you have smaller functions, those can be very easily replicated inside of Wasm. And while we are working on some of these toolings, which are still not supported very well in Wasm, those can still be run very easily in Docker or in containers.”
In a nutshell, Wasm should “in no way in the near future” serve as a direct replacement for all containerized Docker workloads, Saiyam Pathak, director of technical evangelism for Civo Cloud, said during the panel discussion. Instead, applications that do not necessarily run very well with Wasm should continue to work just fine with Docker and containers, reflecting how to “take the best advantages of the Wasm ecosystem.”