So, if I understand correctly, a "unikernel" is what we used to call an "executive" except it is intended to be run as a guest on a virtual machine provided by a full-fledged traditional kernel/userspace OS instead of on bare metal.
The article does reintroduce some concepts that were commonplace when I was first learning computers and it gives them some new names. I like that good ideas can still be useful after years of not being the latest fad, and it's great that someone can get new credit for an old idea with just a little bit of marketing spin.
They can generally be run on bare metal, to my knowledge.
I personally don't remember exactly what was meant with "executive".
This is really well written, thanks for sharing.
I didn't understand the point of using Unikraft though, if you can boot linux in much less than 150ms, with a far less exotic environment
Which architecture can boot it in 150ms ?!
I think "in a VM" was elided. It's easy to tune qemu + Linux to boot up a VM in 150ms (or much less in fact).
Real hardware is unfortunately limited by the time it takes to initialize firmware, some of which could be solvable with open source firmware and some (eg. RAM training) is not easily fixable.
Boot is a misleading term, but you can resume snapshotted VMs in single digit ms
(and without unikernels, though they certainly help)
Stripping away unused drivers (.config) and other "bloats" can get you surprisingly far.
But 150ms? That's boot time for dos or minix maybe (tiny kernels). 1s sure.
Microvm's
Security, it isn't only memory footprint.
Hypervisor as a microkernel
I would like to follow the tutorial but it mentions a playground.
Am I missing something as I cannot find a link or instructions for the playground.
once you login with github there's a start button on top left for that
Thanks
the missing piece of unikernel is debuggability & observability
- it need to be easy to replicate on dev machine & easy to debug - it needs to integrate well with current obs stack. easy to debug in production.
without clear debuggability & observability, i would never put it into production
This is a common myth. Debugging unikernels is indeed possible[1][2]. It may not be the type of debugging you're already used to, but then again, unikernels are very different from containers and VMs, so some adjustment is expected.
As for observability, why is that the concern of unikernels? That's something your application should do. You're free to hook it up to any observability stack you want.
[1]: https://nanovms.com/dev/tutorials/debugging-nanos-unikernels...
I've found the idea of unikernels interesting for several years now, is there a tl;dr on why they don't seem to have taken off, like at all? Or is it all happening behind some doors I don't have access to?
I think that part of it is that relatively few people use bare-metal servers these days, and nested virtualisation isn't universally supported. I also found this technical critique [0] compelling, but I have no idea if any of it is accurate or not.
[0]: https://www.tritondatacenter.com/blog/unikernels-are-unfit-f...
When I first heard about unikernels my hope/thought was that people would go back to using more bare-metal servers for unikernels.
there is a workaround for nested virt requirements.
you can use PVM patch and para-virtualization. I've seen several startup using that approach to be able to create VM on small/cheap EC2 instances.
They kind of did, that is basically how serverless works.
Managed runtimes on top of hypervisors.
cool stuff