The advantage comes from unikernels being even more disposable than containers. Your kernel is built with an absolutely tiny number of options. You wouldn't eve

The advantage comes from unikernels being even more disposable than containers. Your kernel is built with an absolutely tiny number of options. You wouldn't even need things like the console driver, because if a unikernel crashes, you just restart it, with crash logs sent somewhere for analysis. You can remove a lot of your networking stack, because your HTTP server, that only ever speaks http, can get rid of base things like UDP support. You don't need a full-featured filesystem, because things are only written to at compile time. The number of syscalls you expose can equally be tiny. In short, you have an absolutely minuscule kernel. From there, you can start stripping out other things. You don't need a huge init system because all you're doing is running a single application. Your libc can be made tiny, or removed completely, because you can strip it of all the calls your app doesn't need. You don't need to run an sshd, because there is no shell to get into. You can get rid of PAM because there's no accounts to access or authenticate against. On real machines and VMs, these things are necessary so you can run tests, do cleanup, etc. Unikernels are centered entirely around the idea that those things are someone else's job, and if needed, can be shouted for across the network.