[jasode]

>Why would you spin up a full kernel to run a single application

You're misunderstanding the levels of abstraction probably because the word "kernel" within "unikernel" is throwing you off. The idea is to use a partial kernel (only the minimum services one needs). The so-called "kernel" is a library of code where you compile the minimum bits into the single-process image.

>Operating systems already solve this problem relatively well, without the overhead, via processes

A full operating system like Linux is expending extra overhead to schedule/prioritize/monitor processes (plural) -- because Linux is designed to be more general purpose and open-ended than a specialized unikernel. In contrast, a unikernel with only 1 singular process (say a specialized db engine) doesn't need to expend extra cpu on processe(s) scheduling.

All that said, it doesn't seem like unikernels have enough advantages to attract widespread adoption like containers.

[hypertele-Xii]

So it's less of an operating system and more of a single app that runs on metal?

[packetlost]

Yes. Think of it like depending on a small kernel directly in your build step. So your application gets compiled with everything (including OS interface) that it needs and nothing more. The result is a bootable image that is only capable of running your app.

I think the value isn't in the containerization vs unikernel comparison. If you're using containerization you've accepted certain security risks. Where unikernels have a lot of potential IMO is in high security environments where the security risks of containerization are not acceptable.

[chakkepolja]

Another way to describe it is OS-functionality-as-library.