Unikernel is kind of the opposite of microkernel, though; a unikernel merges the application "upwards" into the kernel, while a microkernel system tries to split responsibility into lots of not-especially-trusted pieces.
At the same time, a unikernel will usually rely on a unified upstream virtual machine, which a hypervisor will provide, because you're rarely going to run unikernel applications on exclusive bare metal.
In that context you can think of the hypervisor as your microkernel which provides a unified but very low level API to the unikernel-based microservices.
Yes. Whereas in a traditional setup you'd have an "OS" running an "executable", the hypervisor-unikernel setup the unikernel plays the role of the executable. This indicates that something is very wrong with the OS APIs that this is considered the best way to arrange the desired isolation level!
I am also interested in OCaml, so thanks for sharing this. I’ve heard it’s higher level than Rust and has GC. I’ve spent most of my career using Java and after a few weeks of Rust I love many things about it but feel managing lifecycles and ownership might be too much for me.
Hang in there. Lifecycles manage themselves, mostly. You can write large, complete applications without handling a single explicit lifetime. The borrow checker becomes second nature once you get the hang of it. Don't feel bad for using Rc/Refcell/Clone everywhere. Your code will still be faster than it would have been in most other languages.
The thing about GC is that it doesn't free you from having to think about lifecycle management, it just frees you from having to write it down. I've seen a few memory leaks in Java programs due to people not putting enough thought into when a piece of data is no longer needed.
Granted, most programs don't run long enough/process enough data for poor lifecycle hygiene to become noticeable in GC'd languages.