Comment by nderjung
1 month ago
Hey! Co-founder of Unikraft here.
Unikraft aims to offer a Linux-compatible environment (so it feels familiar) with the ability to strip out unnecessary internal components in order to improve both boot-time/runtime performance and operational security.
Why would you need a memory allocator and garbage collector if you serve static content? Why would you need a scheduler if your app is run-to-completion?
Linux gives you the safety-net of generality and if you want to do anything remotely performant, you by-pass/hack it altogether.
In the article, Unikraft cold-boots in 150ms in an emulated environment (TCG). If it was running natively with virtualization hardware extensions, it can be even shorter, and without the need for snapshots which means you don't need to store this separately either.
Unikraft is cool, I still have it in my 'todo' list to play around with sometime.
Linking the app with the 'kernel' seems pretty nice, would be cool to see what that looks like for a virtio-only environment.
Just wanted to point out that the 150ms is not snapshot based, you can get <10ms for small vms (128MB ram, 2GB ram moves you to ~15ms range), for 'cold' boots.