Containers and Unikernels: Similar, different, and intertwined
unikraft.io
unikraft.io
What made me stop believing in this was WASM/WASI. When it matures it will have similar performance, far better start-up times (microseconds) and a superior transport in/out of the application - WASI is a lot more convenient compared to serial ports and ethernet, which are how a unikernel normally talks to the world.
I still think unikernels are a good idea, but, imo, serverless functions isn't a valid use-case anymore.
What might hinder unikernels, is that chiseled containers is already halfway there.
Why can't you just make a Linux kernel module that takes an arbitrary ELF and runs it in kernel space? This is identical to what unikraft describes doing only with their own kernel. We have firecracker starting full Linux very quickly these days.. no more worries about missing syscalls, drivers, weird scheduler behavior etc? It would be just like running your app as a Linux process but sans the constant hops from ring 0 to 3 and back.
You can, and we've written about the differences also, here [0].
The summary is that there is still a performance hit for boot time (100s of milliseconds to seconds vs. 1 to 100 of milliseconds for Unikraft); performance hit at runtime (even removing the syscall boundaries has a less-than-ideal impact based on previous studies); and, there's extra bloat from the image size itself (the image is still at the very least 30MB+ vs. as little as 100KB for Unikraft) which affects startup time and cost of storage + transport.