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.
> The Multitasking Executive, better known as Exec, is the heart of the Amiga's operating system.
> All other systems in the Amiga rely on it to control multitasking, to manage the message-based interprocess communications system, and to arbitrate access to system resources.
I personally don't remember exactly what was meant with "executive".
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
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.
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.
(and without unikernels, though they certainly help)
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.
- 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
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...
Crash reporting, telemetry, useful queuing/saturation measures or a Rosetta Stone of “we look at X today in system and app level telemetry, in the <unikernel system> world we look at Y (or don’t need X for reason Z) would be more in the spirit of parity
Systems are often somewhat “hands off” in more change control sensitive environments too, these guides presume full access, line of sight connectivity and a expert operator which are three unsafe assumptions in larger production systems IMO
[0]: https://www.tritondatacenter.com/blog/unikernels-are-unfit-f...
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.
Managed runtimes on top of hypervisors.
Am I missing something as I cannot find a link or instructions for the playground.
