Short read: friends! π
Now for the longer read π. Before we can explain how these two technologies can come together, it makes sense to take a step back and explain what unikernels are and what they can do.
A Uni-what?
At a high level, a unikernel is a highly specialized virtual machine that, in principle, contains the code needed for a specific application to run and nothing more. This includes any operating system/kernel code, libraries, etc. As a result, unikernels tend to be rely on OSes that have either small kernels, or even better, modular ones (also known as library OSes), as is the case with the Unikraft Linux Foundation project.
Another characteristic of unikernels is that they tend to have a single memory address space: since isolation comes from the hypervisor underneath, the typical kernel space/user-space divide found in general purpose OSes like Linux adds another layer of (unneeded) isolation at the cost of efficiency (although note that thereβs nothing fundamental about unikernels having multiple address spaces).
So typically a unikernel-based virtual machine image is mostly the application code, plus a thin layer, or as thin as possible, of OS code/libraries to support the application. In other words, as close as the application can get to the hypervisor/hardware as possible, while still having hardware-level isolation. The result is millisecond cold starts, smaller memory consumption, faster I/O, and a smaller TCB, to name a few of their advantages.
In the case of Unikraft, one fundamental aspect was to be Linux-API compatible, or as close to is as possible, such that we donβt force apps to be modified in order to run on Unikraft: if it runs on Linux it should run on us. And of course tooling integrations with Docker and the like to ensure that making use of such technologies is as seamless as possible.
WebAssembly and the Cloud
When an app or service gets deployed to the cloud, in almost all cases itβll be running within a virtual machine/ hypervisor underneath, as these provide the strong, hardware-level isolation required by multi-tenancy. This means that if you deploy a WebAssembly program on a public cloud, youβll be running it on top of (or rather within) a VM.
Indeed, at the 2023 Microsoft Build conference, Mark Russinovich, Azureβs CTO, explained that
βWasm lacks the kind of isolation that we require for running a public cloud.β
In other words, WebAssembly provides language-level isolation, not the hardware-level one needed by public clouds. But this need not be a showstopper.
Unikernels and WebAssembly: A Perfect Marriage?
So we want to run WebAssembly on the public cloud, we want to do so with strong, hardware-level isolation, but we want to retain its lightweight properties, how do we achieve this?
You can probably guess where this is going: put your WebAssembly program in a thin, lean unikernel and deploy it on Unikraft Cloud of course π. For instance, in this guide we use wazero to run a WebAssembly blob within a Go program, and cold start the entire thing in about 20 milliseconds:
We also have Spin on the platform; Spin is more heavyweight, but at least Unikraft Cloud makes it so that the underlying cloud stack adds very little overhead. Oh, and you can also have these WebAssembly apps scale to zero via the -0
flag.
Conclusion
Hopefully this settles, or at least sheds some light on, the question of whether or not unikernels and WebAssembly are competing technologies: in short, unikernels can be leveraged to deploy WebAssembly programs in public clouds in an efficient and hardware-isolated manner. As always, please let us know what you think either on our Discord server, email or LinkedIn.
Get early access to the Unikraft Cloud
If you want to find out more about the tech behind Unikraft Cloud read our other blog posts, join our Discord server and check out the Unikraftβs Linux Foundation OSS website . We would be extremely grateful for any feedback provided!