The expanding world of Wasm
WebAssembly can be combined with OCI containers to allow us to run the exact same container image on any hardware and operating system that we choose, whether it is the fastest, most efficient, or cheapest.
When I think of Wasm – and I’m starting to think about Wasm more – I picture it as one of those magic grow capsules I used to have as a child: You just pour water on the capsule and it expands to many folds and shapes.
Wasm, or WebAssembly as it is officially known, started out small as a binary instruction format to run a stack-based virtual computer. It was originally designed for the browser. Although it’s still small, developers will “pour water on” it. I believe it will continue to grow and shape-shift as they “pour water on” it. Not least as a way for us to write applications once and then deploy them on the increasing number of software and hardware platforms that are driving our lives (sometimes literally).
Hardware is experiencing a significant boom. In a previous era, Intel was as important to hardware processors than Kleenex was to facial tissue. It’s a multi-lingual hardware world. Arm, RISC–V, Apple M1/M2, AWS Graviton and Fujitsu have joined Intel or AMD processors to develop a variety of new use cases. These include lightbulbs, cars, enterprise applications and web servers that bind everything together in a modern world. For many years, all of these hardware architectures and legacy stuff will have to co-exist.
There are many languages. Java as well as .NET have allowed developers to create an application once and then run it anywhere. However, there are some limitations and overhead. There is an implicit understanding with Java and.NET that all of your software ecosystem will be written in Java and.NET. Although.NET supports a few languages, it has never been the default, multilingual interpreter for all languages. There was always a clear separation between Java and.NET, where the OS managed polyglot processes (Python Ruby, Perl C, C++ etc.). ), and the VM which managed the processes within of the software ecosystem (Java and.NET).
Although there have been several attempts to expand the Java Virtual Machine (JVM), with JRuby and Jython, they never really caught on. This purpose has been served by the operating system through standardized C library which almost every language uses. However, it’s not always been easy to share libraries among languages like Ruby and Python. Maybe a universal binary format has always been required! ?
Where Wasm Fits in
In 2015, the World Wide Web Consortium (W3C), announced Wasm, also known as WebAssembly. It published it in 2018. The original Wasm was intended for browser use only. However, it is now being used in-the-weeds as a barrier breaker in different software and hardware environments. Wasm was originally designed to allow developers to use compiled languages such as C++, C++ or Rust safely in the browser. It also prevents the code from overtaking a user’s computer.
The vision evolved to something similar to Java and.NET but for all languages. Developers can compile any language into a binary which could run on any platform using Wasm interpreters. This allows them to use Wasm interpreters in any browser, on the desktop or as a plugin framework within another piece of software. This vision is now true portability for a broad range of uses. It’s still not there.
Wasm is perfect for certain uses today, such as browser-based apps or plug-ins. Wasm is expanding to allow you to compile Python into a Wasm binary which can be run on a Wasm program. You can now run my Python programs, because the Python interpreter has been compiled into that format. The Python interpreter will run on any hardware that supports a Wasm interpreter. We are also seeing Wasm evolve so that the same Python program can use libraries from other languages that run under the Wasm interpreter. There is a push for portability, both on the software and hardware sides.
Rust is the most used language with Wasm at present. These Wasm binaries are being used by people who compile Rust into them. It’s evident in many plugins but also in specific cases such as Envoy, a popular network proxy and Krustlet which is a program that replaces the Kubernetes Kubelet. Krustlet will run Wasm binaries instead of OCI containers.
We’re seeing people use C++, Ruby and Python beyond Rust. This means that there is polyglot support on the software side. We are also starting to see tools such as Podman, CRI-O, and others that use OCI containers and Wasm together. OCI containers are designed to run the binaries directly on the kernel of the container host. This comes with the drawback that the binary inside the container must be compiled to support the hardware architecture.
Crun, a container runningtime that is commonly used by Podman, CRI-O and CRI-O includes an experimental feature that detects Wasm binary within the container image and then runs them on a Wasm interpreter on the host. OCI and Wasm containers can be run together to provide additional security and the ability to use the same containers on different operating systems and hardware architectures.
There is still a lot to be done with Wasm.
One, language support must be expanded. However, APIs for more and greater use cases (networking is severely lacking) within more languages are being added every day.
Wasm, a specific instruction set architecture that isn’t POSIX-compliant at the moment, is perhaps the bigger problem. This means you can’t use Wasm to do many of the standard things developers expect (think about opening a file, or a network socket). Wasm will soon have an additional API called WASI which will allow Wasm some of these general computation tasks. However, Wasm will remain limited in its use until then.
The future of Wasm
There is much discussion about Wasm’s potential right now, as well as millions of dollars in venture capital invested in companies that are working to develop the technology. That’s money that I consider to be well-spent. I can see a day when a developer using a Mac, Windows or RHEL laptop or workstation will be able compile an app for edge, IoT or cloud platforms. They will use Wasm. This workflow is currently difficult and/or slower than it used to be.
Cross-compiling the code is not what the developer wants. They just want it to work. Theoretically, Wasm can do that.
Wasm can also make containers more portable and stronger.
Giuseppe Scrivano, my colleague, has done two proofs-of-concept (PoCs) using crun. These demonstrate how a Wasm binary is run from a Docker/OCI Container using podman/crun on Linux or using CRI/O/crun in Kubernetes. The container runtime detected the Wasm binary and ran it using a Wasm interpreter. (At the time this writing, crun supports WasmEdge and Wasmer.
Giuseppe’s PoC shows that Wasm could allow you to run the exact same container image on any hardware, or at least anywhere where there is a Wasm interpreter. This would eliminate the need to build and compile different containers images for RISC-V or Arm. Today, this is what we are forced to do. If the binary needs to run on three different hardware architectures we must compile and rebuild it three times, create three separate container images, then push them all onto a registry server. Giuseppe’s PoC demonstrates that Wasm allows a developer to build once and deploy anywhere. This is one of our long-held dreams with containers.
That’s the hybrid cloud story. Imagine a Kubernetes cluster running on a variety of nodes. I could download an app and run it where it is most efficient, fastest, cheapest or close to the consumer.
Wasm has a lot of potential, and I believe we can achieve it, especially if the Wasm people can resolve the language and POSIX issues. POSIX is an operating system feature that has been around for over 20 years. You can’t ignore the legacy software of two decades.
The Wasm trajectory is something that the WebAssembly community knows about. They are currently working on APIs to remove the blocks and make Wasm more useful for more uses. All of this will make Wasm a more general-purpose architecture that organizations can use to optimize and support the hybrid cloud model.
Scott McCarty, senior principal product manager at Red Hat for RHEL Server is arguably the most important open-source software company in the world. Cloud, containers, workload expansion and automation are the areas of focus. Scott works closely with customers, partners and engineering teams. He also provides feedback from customers and partners to improve and tailor Red Hat Enterprise Linux’s strategic capabilities.
Scott is a social media startup veteran and an ecommerce old-timer. He has also been a government research technologist for many years. His experience spans seven person startups up to technology companies with over 12,000 employees. This experience has given Scott a unique perspective in open-source software development, maintenance, and delivery.