A lot of it seems to boil down to how you isolate and orchestrate *nix processes (assuming modern Linux-based unikernels at least). I suspect the general thread will evolve and get refined before anything radically new comes along.
would really like to see serverless functions based on unikernel instant starts. containers are a great way to integrate functionality like that into kubernetes.
I worked on unikernels for a number of years and this (serverless functions) was our long-term use-case we worked against.
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.
I hate to be that guy that's clearly ignorant on a particular topic, asking "why not just do <extremely hard or nonsensical thing>?" but I've always wondered..
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.
Well that's not a unikernel though, and is basically what firecracker-containerd does. You still have to traverse the syscall boundary which has a performance hit.