Since 2017 there has been a new W3C standard for web browsers, which enables binary code to be executed directly in the browser and thus to achieve quasi-native performance. It is WebAssembly. Just recently, Ricky wrote a TechUp-Post about WebAssembly and showed how a program in any source language (in his article his language of choice was Rust) can be converted into a WebAssembly format, the so-called WASM artifact, and integrated into the browser.
In a nutshell, you can convert any codebase into a WASM artifact and run it directly on the client browser. This not only has the advantage that the resources are used directly on the client system, but with the appropriate architecture it can also lead to a reduction in latency, as certain computing operations no longer have to be performed on the backend, but can be taken over directly by the client.
WebAssembly Timeline
WebAssembly is quite a young development and the awareness of the possibilities is not yet established. For this reason, we briefly show the major milestones of WebAssembly and thus refer to the recent history of WebAssembly as a revolutionary, distributive technology:
-
March 2017: Minimum Viable Product published, first browser engine adopted the first specification (Blink, WebKit, Gecko, etc.)
-
March 2019: WebAssembly System Interface published and enables WASM to be used without a browser
-
December 2019: W3C introduced the WebAssembly Core Specification as a new web standard
-
January 2021: Wasmer, the first universal WebAssembly Runtime was in version 1.0 published
-
August 2021: wasmCloud, a runtime designed for the cloud, will be a CNCF sandbox project
Sandboxing by WASI
WASI stands for WebAssembly System Interface and is the W3C standard, which defines how WebAssembly is allowed to interact with the operating system. Since WebAssembly only represents a binary format, there is the need of another standard, means that when a WASM artifact is executed on an implementation of a virtual machine, the underlying operating system is correctly addressed.
When accessing local files, one often thinks that with programming languages like C, the files can be accessed directly. But this is not the case. There is an abstraction level in between, the user mode, which uses system calls to ask the kernel whether the access is legitimate, more precisely whether the access rights are given. Since there are different operating systems, different APIs are used when compiling a C program. Windows uses the Windows API, whereas POSIX is used on Linux or MacOS. Exactly the same starting position presents itself with WebAssembly. If you abstract away the web browser, WebAssembly needs an interface with which it can address the underlying operating system. WASI is the standard for this. WASI ensures OS-independent interaction of WebAssembly artifacts.
For WebAssembly and WASI, two important features are in the foreground:
- Portability
- Security
The WASI standard thus allows WASM artifacts to be executed in a secure sandbox. Solomon Hykes, co-founder and initial inventor of Docker, express in one of his tweets the benefits of this as follows:
Write Once, Run Anywhere
The idea of Write Once, Run Anywhere (WORA) is not new. Java conquered the programming world with the slogan back in the 90s. That was at a time when a wide variety of chipsets were still built into the computers. It was particularly important to be able to run an application on as many computers as possible. The Java Virtual Machine does the work and ensures that a code base behaves the same on all computers and operating systems, or at least in theory. With the advent of the Internet, JavaScript became the new lingua franca of the web and is considered the quasi-standard language for web applications.
There are already a number of WASI implementations that target a WASM runtime. This includes Wasmer, Wasmtime, Lucet or SecondState. In this article we will not be able to check all runtimes for lungs and kidneys, but try to give a basic picture of what can be done with them and what a runtime could be suitable for in your company.
Kevin Hoffmann, a Software Architect at Cosmonic, the developer of wasmCloud, differentiates in his first speech about WebAssembly runtimes 3 levels of abstraction:
-
Low-Level Runtimes Interpreters and compilers, as well as JIT compilers. These offer a browser-less Execution of WASM artifacts. Examples:
- Wasmer
- Wasmtime
- Wasm3
- Wasmi
-
Mid-Level Runtimes These are runtimes that, in addition to the interpreter / compiler, also deliver additional layers such as interfaces for function / procedure calls or payloads. Examples:
- waPC
- wascap
-
High-Level Runtimes These are runtimes that provide additional layers and thus deliver an actor model that allows HTTP servers, connections to message brokers, or interfaces via Protobuf to be integrated as WASM modules. Examples:
- waSCC
- wasmCloud
Wasmer - Run any code on any client
Wasmer is a WASM runtime that executes WebAssembly artifacts standalone without a browser. According to Hoffmann’s abstraction model for runtimes, Wasmer is one of the low-level runtimes that only provides a runtime.
Installation
As you are used to from modern cloud applications, there is a shell script for installation which you can download directly using curl.
|
|
Package Manager and WASM Repository
Another Wasmer project is the wapm, the WebAssembly Package Manager. As with DockerHub, you can host WASM artifacts and download them if necessary.
An example artifact, adamz/quickjs, is a JavaScript engine. This can be executed directly in the browser using the WebAssembly shell.
Installation is a WASM artifact
|
|
Execution of the WASM artifact
|
|
WASM container in the cloud
There are fundamental advantages to using WebAssembly containers instead of classic LXC containers. Although classic container solutions also have a strong focus on security-relevant features, the possible security contexts represent a large area of attack and therefore potential danger. For this reason, cloud providers develop a small Hypervisors and so called Micro-VMs such as gVisor, Firecracker or Kata-Containers to reduce the access to the kernel and to ensure better isolation of the application environment.
WebAssembly, on the other hand, has a security-based standard that does not allow unwanted access in the first place. So WebAssembly is a real Sandbox. In addition, the WebAssembly artifacts do not have to deliver the entire libraries, interpreters or virtual machines, but only contain their own application as a binary.
Figure: Source: Cosmonic (https://cosmonic.com/)
Here Cosmonic shows how the containerization has progressed and ends in a WASM-capable runtime. The trend towards decoupling the business logic from the rest of the world is clearly visible. WASM could actually be the solution to provide a host of this quality.
Krustlet - the WASM Kubernetes kubelet
Deis Labs, the people behind well-known CNCF projects like Helm or Brigade got another project in stock, which extends Kubernetes. Krustlet, derived from Kubernetes-Rust-Kubelet, is a Kubelet, which enables rolling out WebAssembly workload on a Kubernetes clusters. The idea is to reduce the upstart time and the footprint, and to be even more hardware-independent. Even if this often does not play a major role, the container runtime (LXC), like Docker, depends on the image to be executed being delivered for the same chipset as the underlying host system.
Conclusion
WebAssembly is not just a new standard, it also has the disruptive potential to fundamentally change things in the web and cloud world. This is not just about the obvious benefit, namely shifting workload from the backend to the client devices, which ensures better latency and a better user experience. With WebAssembly in combination with WASI, you create a runtime environment with which Codebase is reduced to the business logic and can be rolled out safely with the smallest possible footprint and use of resources.
Kevin Hoffmann sees WebAssembly as the future for Distributed Computing and the basis to achieve ‘‘Write Once, Deploy Everywhere’’ regardless of the browser. Just recently, in August 2021, the first WebAssembly runtime was added to the Cloud Native Computing Foundation. wasmCloud, the runtime from Cosmonic, allows workloads to be rolled out in a WebAssembly environment in the cloud. Thus, the first course has already been set for a cloud-compatible solution thanks to WebAssembly runtimes. We can only judge to a limited extent whether this container alternative will establish itself in the future. What is certain is that we will keep an eye on WASM and its runtimes and will also use the technology ourselves in the event of widespread adoption.
Stay tuned!
Additional links and resources
Wasmer – The Universal WebAssembly Runtime
SecondState – Serverless Everywhere with WasmEdge
WebAssembly runtimes compared – LogRocket Blog
WebAssembly-Where is it going? – OpenCredo
Kruslet Brings WebAssembly to Kubernetes with a Rust-Based Kubelet
Rust, WebAssembly, and the future of Serverless by Steve Klabnik – Codegram (Youtube)
Kevin Hoffmann-Building a Containerless Future with WebAssembly – WebAssembly Summit (Youtube)
WebAssembly in the Cloud – kevinhoffmann.medium.com
Cosmonic Contributes WebAssembly Runtime to CNCF
Using WebAssembly and Kubernetes in Combination
This text was automatically translated with our golang markdown translator.