Another unikernel.
I wonder how mature is that.
I wonder how mature is that.
[Disclaimer, I'm one of the maintainers]
Another unikernel yes, sorry about that! :) . Unikraft started back in 2017 initially as a research project, and has been a Linux Foundation OSS project since 2018.
While Unikraft OSS is used in different use cases, our primary target is cloud deployments. Unikraft has 3 key principles:
1. A fully modular OS -- so that we can specialize the resulting unikernels (VMs) as much as possible
2. Linux-API compatibility -- so that we don't break applications
3. Integration with Docker/Dockerfiles (and other tools) -- for ease of use
Unikraft powers kraft.cloud . You can see the platform's guides to get an idea of the apps/frameworks it supports: https://docs.kraft.cloud/guides/
In comparison, compiling NGINX together with Unikraft results in a kernel size of under 2MB. This means that there is 28MB of kernel we didn't need or want.
[0]: https://arxiv.org/abs/2104.12721 (See Figure 1)
At least I know from talking to Alex that they actually know what users and people playing with kernels like in his toolchain.
Kraftcloud is just them eating their own dogfood. In my opinion it's all about the toolchain(I mean not only) and these people understand that.
In my opinion Linux didn't win because it has the best design on every front. It won, because it had the easiest toolchain for someone like me with zero experience to just read a total after school and start building a kernel.
This is similar. Building is simple, configuring is simple, packaging is simple. It has the added bonus of having people behind it, that are ALSO good researchers.
I hope that at some point they will pay for a professional audit, but it's already awesome to see where they got.
The key difference between unikernels (and library OSes) vs. other kernels is that each kernel is different with a unikernel. Your application goes through a process of specialization, where you can decide exactly the necessary features (e.g. libraries, syscalls, memory allocation, scheduler, etc.) are necessary or desired for your application. Additionally, other kernels are typically multi-process whereas a unikernel is inherently single-process since it does not support syscalls like fork. (That said, at Unikraft, we are working on supporting fork, eta. late April).
Additionally, before Unikraft, one of the major trade-offs was developer time and effort to get your application into a unikernel. Since Unikraft has been actively developed for several years by ~100+ people, it has become much more stable, feature complete and easier to use; ultimately making unikernels easier to approach.
Today, in-addition to multi-process applications, the trade-off now really depends on your usecase and so selecting whether you wish to deploy your application as a unikernel or on top of a monolithic kernel or microkernel. For example, developer environments which require many subsystems, multiple programs, etc., where you can't know everything ahead-of-time, are still best suited for multi-user, monolithic kernels that can run most workloads.
Another thing to note is that unikernels are designed to be immutable and are often created in a CI/CD context. This means that they are single-purpose and if you wish to change them, you need to re-build (or re-package).