WebAssembly vs. Kubernetes
Yes, WebAssembly can solve some of Kubernetes’ ills.
WebAssembly, or Wasm, was shown to be a very practical way to run code on a web browser, serving as a compiler of sorts. And it has worked so well as a language that the World Wide Web Consortium (W3C) named it a web standard in 2019, thus becoming the fourth web standard with HTML, CSS and JavaScript.
The major web browsers including first Mozilla, then Chrome, Internet Explorer, etc. became compatible with Wasm for its burgeoning use for writing code and creating applications on web browsers. In addition to web workhorse JavaScript, other languages Wasm can accommodate include Go, .NET, C++, Java, PHP, Rust and Python.
One of the more interesting use cases is how Adobe relies on Wasm/WASI platforms to run C++ code directly on the browser. This allows users to run Adobe’s Photoshop and Acrobat directly on the browser, thus removing the need of having to download these software tools on the user’s machine to work.
Eventually, it dawned on developers that Wasm could run on server operations systems as well and its use now extends across hardware platforms. It has shown to be very effective in a number of different hardware environments, ranging from server-side to edge deployments and IoT devices or wherever code can be run directly on a CPU. The code runs bundled in the neatly packaged Wasm executable that can be compared to a container or even a mini operating system that can run with significantly less — if any — configuration required for the code and the target. Wherever code can be deployed, essentially, the applications are much farther out than just being confined inside the web browser environment.
In many ways, Wasm’s capabilities can be compared to a multilingual compiler “on steroids” for the number of different languages it can accommodate. Yet, the comparison to a compiler largely ends there. This is largely because compared to the compilers the same binary executables of Wasm can target and run on multiple platforms — without configuration of the code on wasm and of the target device.
In this way, Wasm is definitely an improvement over the days of compilers where the code on the executable and the target-environment host had to be completely reconfigured. A single binary executable across multiple targets without having to be reconfigured: that’s the beauty of Wasm.
“Wasm finally lets us move code between servers, clouds, and edge devices without involving developers. This would finally end the era of developers having to spend a ton of time worrying about adjusting their code for and then supporting this code on different target platforms,” Torsten Volk, an analyst for Enterprise Management Associates (EMA), told The New Stack. “It is Wasm’s job to provide one consistent runtime across all of these platforms.”
For these reasons, Wasm can offer a very good alternative to Kubernetes — in some cases. The main plus compared to Kubernetes are:
Simplicity. There are just a number of steps that are conspicuously absent when deploying an application, even when the application is distributed to different end targets. A PaaS version of Cosmonic can be used to deploy an application in just a very few command lines, mostly with a graphical interface. The same is true when using Fermyon, and Fastly’s Compute@Edge.
If it walks like a duck, it is a duck: #wasm and @wasmcloud currently just work. I saw firsthand and even worked through some of the commands to setup and run an app on microservices with @wasm. Hint: Incredibly easier to do versus @Kubernetes. 1.@baihay @thenewstack @cosmonic pic.twitter.com/eX7gHaxPma
— BC Gain (@bcamerongain) October 26, 2022
Conversely, as developers and DevOps folks know very well, learning how to work with Kubernetes as a developer is tremendously difficult comparatively. It requires a significant learning curve and usually involves, among other things, configuring YAML files, and ensuring that that code goes through numerous steps and processes before it even reaches operations for deployment and management.
Instead, installing Kubernetes and getting a first application deployed typically takes hours, Bindle maintainer and Fermyon Technologies CEO and co-founder Matt Butcher told the New Stack. It is possible to install Fermyon Platform onto DigitalOcean, AWS or Azure in about seven minutes, and then deploy WebAssembly apps “without ever writing a single line of YAML,” Butcher said.
Security. In this highly distributed environment of Kubernetes, security is and will remain a real issue and an exhaustive list of the problem points is too long to mention here. Interconnectivity of microservices means one entry point among hundreds in a pod that an attacker gains access to can potentially wreak havoc on an organization’s entire infrastructure. Secrets management is another issue, and like names, poses difficulties in designating who gets access to them in a container.
Wasm’s portability and consistency can make security and compliance much easier to manage (again, it runs in a binary format on a CPU level). Also, part of Wasm’s simplicity in structure means that code is released in a closed Sandbox environment, almost directly to the endpoint. Not that Wasm never has vulnerabilities to exploit. It’s just that Kubernetes has comparatively more numerous possibilities and access points to compromise.
But They Are Not the Same Thing
Wasm offers immense opportunities and will likely serve as a way to deploy applications on a wide scale that we’ll see during the coming months and years as vendors become more creative with how users can take advantage of it. Comparatively, those predicting that Wasm will eventually eat Kubernetes’ lunch and will replace it completely are arguably missing the point. It is impossible to say what will happen and what other technology for deploying and managing highly distributed applications in cloud environments may eventually replace Kubernetes. But it is highly unlikely that it will be Wasm.
This is because Kubernetes will always have its uses. It’s always going to be used to orchestrate microservices, as well as containers, of course. It can also be thought of actually in that Wasm will be something that will run within Kubernetes and already its proponents do say that Wasm offers a very nice fit to run in Kubernetes environments.
“Wasm is a serverless runtime for developers to deploy code to without having to write and maintain a ton of infrastructure YAML at the same time. Wasm provides application code with a set of standard APIs for consistent access to crucial runtime services, such as SQL or NoSQL, Kafka messaging or code debugging,” Volk said. “But Wasm then relies on a resource orchestration layer, that can be provided by Kubernetes or any other scheduler to provide the infrastructure resources required for these services to run. These resources can then be delivered in the form of a container, VMs, bare metal, or some fancy future technology nobody has thought of just yet.”
However, not everyone believes that Kubernetes’ capabilities for container orchestration will remain the de facto choice indefinitely. Many in the Wasm space are gravitating toward HashiCorp’s Nomad scheduler, Butcher said. Indeed, Fermyon has given up on Krustlet (Wasm-on-Kubernetes) and has pivoted to HashiCorp Nomad as its scheduler. “Nomad does an amazing job of scheduling both containers and WebAssembly, and we think it’s the future of cloud orchestrators,” Butcher said. ” I think that we can imagine a world where Kubernetes fades, and Nomad takes its place.”
Nomad offers the ability to orchestrate containers, just as Kubernetes does, but has a crucial additional feature: It can schedule non-container workloads, Butcher said. “At Fermyon, we were able to get Nomad to schedule and execute WebAssembly applications without writing a single line of custom code.”
Meanwhile, it’s incumbent on Kubernetes developers to embrace WebAssembly at a low level and change the built-in, container-specific assumptions, Butcher said. Microsoft is the first company to really embrace this concept, and its runwasi project is an example of how WebAssembly can be executed inside of Kubernetes, Butcher said.
“The runwasi project is merely the first step, though, in a series of transformations that Kubernetes needs to undergo if it is to retain its supremacy in the microservice/container world,” Butcher said. “The game is Kubernetes’ to lose, but [its developers and maintainers] need to act quickly if they don’t want to be overtaken by Nomad and Wasm.”
Existential Threat
Wasm poses an existential threat to Docker, as well as to containers, though. Similar to its superlatives over Kubernetes, Wasm’s advantages for simplicity, portability and security, make it at least a good candidate to make up for Docker’s shortcomings, especially for edge and distributed applications. However, Butcher noted how Docker excels at providing an environment for two distinct kinds of application:
- Long-running processes like databases and message queues, which have both strong I/O and memory management needs.
- Heritage (legacy) code that retains state in the application and makes heavy use of threading.
“My thinking on Docker is that it has a strong and defensible position in the market that Wasm is unlikely to unseat,” Butcher said. “But when it comes to microservices and web application backends, I think WebAssembly is poised to eat into Docker usage.”
So, as a possible Docker and container replacement for certain use cases, yes, Wasm can replace Docker but using Wasm to orchestrate containers and microservices to the extent that Kubernetes can be done for highly distributed cloud and on-premises environments definitely not.
