Can WebAssembly really replace Kubernetes?

Abstract: Many developers always compare WebAssembly with Kubernetes habitually. Maybe some kind of technology will appear in the future to deploy and manage distributed applications in the cloud environment and eventually replace Kubernetes. The author of this article believes that it Unlikely WebAssembly.

Original link: https://ift.tt/YL0OWij

Disclaimer: This article is translated by CSDN, and reprinting is prohibited without permission.

Author | Cameron Gain

Translator | Crescent Moon Editor | Zheng Liyuan

Produced | CSDN (ID: CSDNnews)

In my opinion, WebAssembly can solve some problems of Kubernetes.

WebAssembly, or Wasm for short, is a way to run code on a web browser, acting as a compiler of sorts. It is also well received as a language, and in 2019 the World Wide Web Consortium (W3C) named it a web standard, making it the fourth web standard after HTML, CSS, and JavaScript.

Today’s major web browsers, including Mozilla, Chrome, IE, etc., are compatible with Wasm because it has become an emerging channel for writing code and creating applications on web browsers. In addition to JavaScript, Wasm is also compatible with many other languages ​​including Rust, Go, .NET, C++, Python, Java, and PHP.

As an interesting example, Adobe relies on the Wasm/WASI platform to run C++ code directly on the browser. In this way, users can run Adobe’s Photoshop and Acrobat directly in the browser, without having to download these tools to their devices.

Finally, the developers realized that Wasm could also run on server operating systems and could be extended to hardware platforms. It turns out that Wasm works well on many different hardware environments, from server-side to edge deployments and IoT devices, or anything that can run code directly on the CPU. The code will be neatly packaged into a Wasm executable, sort of like a container or even a mini operating system, and Wasm requires very little configuration to run the code. Code can be deployed anywhere, and applications are no longer limited to the environment of a Web browser.

In many ways, Wasm is the equivalent of a polyglot compiler, as it can accommodate many different languages. However, in contrast to compilers, Wasm binary executables can run on multiple platforms without the need to profile the code on Wasm and the target device.

From this perspective, Wasm even surpasses compilers, because in the era of compilers, executable files and code on the target environment host must be reconfigured. The advantage of Wasm is that it can create a cross-platform binary executable without reconfiguration.

“With Wasm, we can finally move code between servers, clouds, and edge devices without developer involvement,” said Torsten Volk, an analyst at Enterprise Management Associates. Previously, developers had to spend a lot of time tweaking code and supporting The era of code on different target platforms is over. Wasm provides a unified runtime that can serve all platforms.”

Combining the above reasons, we believe that Wasm can be a good Kubernetes alternative in some cases. The main advantages of Wasm over Kubernetes include:

• simplicity. Wasm can save some steps when deploying applications, even if the application needs to be distributed to different target devices. Cosmonic’s PaaS version provides a graphical interface, so very few commands need to be run to deploy an application. Additionally, Compute@Edge from Fermyon and Fastly are also available.

Relatively speaking, it is very difficult for developers to learn to use Kubernetes. There is a steep learning curve, lots of YAML files to configure, and many steps and processes to deploy the code to the cluster.

Installing Kubernetes and deploying your first application typically takes hours, but installing the Fermyon platform on DigitalOcean, AWS, or Azure takes only seven minutes, and then you can deploy WebAssembly applications without writing any YAML.

• safety. In a distributed environment like Kubernetes, security remains an important issue. The interconnectedness of microservices means that once an attacker gains access to one of the hundreds of entry points in a pod, it has the potential to wreak havoc on an organization’s entire infrastructure. On the other hand, the management of secrets is also a problem, and it is difficult for us to specify who has access to the confidential data in the container.

The portability and consistency of Wasm can reduce the difficulty of managing security and compliance. In addition, Wasm’s very simple structure means that code is released in a closed sandbox environment, almost directly to the endpoint – we are not saying that Wasm does not have any vulnerabilities that can be exploited, but Kubernetes is more likely to be attacked. high.

Wasm and Kubernetes have different goals

Wasm presents a huge opportunity and could become a way to deploy applications at scale, and in the coming months and years we will see vendors find ways to create more opportunities for users to take advantage of Wasm. But we can’t simply think that Wasm will eventually replace Kubernetes. Perhaps there may be some kind of technology in the future that deploys and manages distributed applications in a cloud environment and eventually replaces Kubernetes, but it is unlikely to be Wasm.

Kubernetes has its unique uses, such as orchestrating microservices and containers. We can assume that Wasm will run in Kubernetes, and it has been argued that Wasm is a good fit for running in a Kubernetes environment.

“Wasm is a serverless runtime that developers can deploy code into without having to write and maintain massive amounts of infrastructure YAML at the same time. Wasm provides applications with a standard set of APIs for us to uniformly access the core runtime Services, such as SQL or NoSQL, Kafka messaging, or code debugging.” Volk said: “The resource orchestration that Wasm needs to rely on can be provided by Kubernetes or other schedulers.”

However, not everyone thinks that Kubernetes’ container orchestration capabilities will always be irreplaceable. Many in the Wasm space are drawn to HashiCorp’s Nomad scheduler, Butcher said. ermyon has abandoned Krustlet (Wasm-on-Kubernetes) in favor of HashiCorp Nomad as a scheduler.

Butcher said: “Nomad’s container scheduling and WebAssembly are excellent, and we think this is the future of cloud orchestrators. I think maybe in the future Kubernetes will gradually disappear and be replaced by Nomad.”

Nomad also offers the ability to orchestrate containers, just like Kubernetes, but with an important addition: orchestrating non-container workloads. “At Fermyon, we schedule applications through Nomad and then execute them through WebAssembly without writing a single line of code,” Butcher said.

In the meantime, Kubernetes developers need to embrace WebAssembly and change the built-in, container-specific functionality. Microsoft was the first company to really embrace this concept, and their runwasi project is an example of running WebAssembly inside Kubernetes.

Butcher said: “It’s just that the runwasi project is only the first step. If Kubernetes wants to maintain its dominance in the field of microservices and containers, it needs to undergo a series of transformations. In this competition, Kubernetes is currently at a disadvantage. If you don’t want to be Nomad and Wasm go above and beyond, and developers and maintainers need to act quickly.”

potential threat

Wasm threatens the survival of Docker and containers. The advantages of Wasm in terms of simplicity, portability, and security make it one of the candidates to compensate for the shortcomings of Docker, especially for edge and distributed applications. However, Docker excels at providing environments for two different types of applications:

• Long-running processes, such as databases and message queues, have strong demands on I/O and memory management.

• A lot of legacy code left inside the application not only saves state, but also makes heavy use of threads.

Butcher said: “Docker has a strong and solid position in the market and is unlikely to be replaced by Wasm. However, for the back end of microservices and web applications, I think WebAssembly can completely replace Docker.”

The text and pictures in this article are from CSDN