Basically you replace the system calls into the kernel with library calls. So you end up with a single binary that contains both the application as well as the operating system functionality.
This can lead to some rather spectacular performance benefits. One thing is that you remove the syscall overhead, but more importantly you can do a lot more optimizations at the compiler/linking steps.
You can remove complex code that tries to dynamically model the world with rather plain code that does just what it is supposed to. With IncludeOS (C++17 unikernel) we did make a firewall implementation that instead of using complex data structures relied on preprocessing the rule set and translate it into C++ code. The code to do this was quite simple and resulted in pretty amazing figures wrt number of rules per packet per second. Metaprogramming can sometimes deliver amazing results.
Similar things can be done in a traditional kernel as well and we've seen eBPF firewall implementations that are able to get similar numbers. On the flip side eBPF and it's firewall implementation is order of magnitude more complex. However, you can push eBPF code onto the networking card which can be a huge benefit. And ofc you could make a kernel module that implements a specific firewall ruleset and get similar performance without eBPF.
I like unikernels because I feel I can understand them better. You can reason about them and they are easier to optimize for very specific workloads.
So why aren't we using them? Likely because we know Linux so well and we've invested a lot in it. It runs everywhere and is extremely well supported. Bringing a new operating system to market is challenging, bringing a new operating system with a entirely different architecture is even harder. Even if it, on a purely technical level, could yield better results.
Another performance benefit (unsurprising in highsight) comes from removing KPTI and similar Spectre mitigations. These have really made system calls in regular kernels expensive.
On the other hand if you run only one application on your VM you can just disable them, because one you have access to the userspace application there is nothing else on the machine to steal via side channel attacks.
Absolutely. As of course you know but for the benefit of others reading this, Red Hat [we both work there] is concurrently looking at many different approaches (straight containers, Kata, restructuring QEMU, optimizing the kernel, unikernel Linux, and probably half a dozen others I've forgotten). I doubt that any single approach will be always better.
This can lead to some rather spectacular performance benefits. One thing is that you remove the syscall overhead, but more importantly you can do a lot more optimizations at the compiler/linking steps.
You can remove complex code that tries to dynamically model the world with rather plain code that does just what it is supposed to. With IncludeOS (C++17 unikernel) we did make a firewall implementation that instead of using complex data structures relied on preprocessing the rule set and translate it into C++ code. The code to do this was quite simple and resulted in pretty amazing figures wrt number of rules per packet per second. Metaprogramming can sometimes deliver amazing results.
Similar things can be done in a traditional kernel as well and we've seen eBPF firewall implementations that are able to get similar numbers. On the flip side eBPF and it's firewall implementation is order of magnitude more complex. However, you can push eBPF code onto the networking card which can be a huge benefit. And ofc you could make a kernel module that implements a specific firewall ruleset and get similar performance without eBPF.
I like unikernels because I feel I can understand them better. You can reason about them and they are easier to optimize for very specific workloads.
So why aren't we using them? Likely because we know Linux so well and we've invested a lot in it. It runs everywhere and is extremely well supported. Bringing a new operating system to market is challenging, bringing a new operating system with a entirely different architecture is even harder. Even if it, on a purely technical level, could yield better results.