Unikraft Unikernel Project
linuxfoundation.org
linuxfoundation.org
Now we see a use case (call it "microservices" if you want) where people want to run a single application as if it was alone on a machine, and where the concept of "user" doesn't even make sense.
This second use case is what unikernels are for. It may make a lot more sense to run a Unikernel application on an hypervisor than a whole OS in a VM, and probably than a container too.
Look at a non-trivial application such as Postfix. It still is simple enough to be understood by one individual human, but it's complex enough to make use of file system rights and various forms of interprocess communication to do its job.
Once you've re-implemented this with unikernels, haven't you re-invented access control and authorization, which you wanted to do without? And yet, you've only got your email transport up. Still a long way to go for a modern collaboration server.
Real world systems, like airline bookings or ERPs, are orders of magnitude more complex than that. I'm not convinced I'd not rather have those use standard components for things like ACLs, process accounting and user ids. They were invented for a reason, and makes it easier to reason about data at rest and things like backups and process scheduling. My suspicion is that you'd want to reinvent them pretty soon when your system grows beyond that single micro service.
i think osvirt is a more efficient abstraction, but the industry clearly has other ideas.
in the case of Xen, you will have linux or *bsd in dom0 which will probably have aslr enabled. so, when you launch your unikernel and do aslr you will be randomizing an already random memory layout.
my point of contention is with the hypervisor+unikernel model. once you try to increase the tenant density of a particular piece of hardware with virtualization you lose most of the advantages of removing the os and re-introduce the complexity in a different way.
Unikernels let you combine the top 3 layers of the (Hardware -> Hypervisor -> Kernel -> Userspace -> Application) stack into one. That's a big win for reducing complexity. And if unikernels take off, I expect better tools for managing them to be built right in to hypervisors to help restore whatever functionality gets lost in the squish.
Funny thing is, if you squint a little, the resulting (Hardware -> Hypervisor -> Unikernel) stack looks a lot like (Hardware -> Operating System -> Application), which we all know and love from traditional pre-virtualization environments. In a sense, we're not so much rejecting the multi-user model as we are reinventing it for a cloud-based age.
Maybe this is indeed a big waste of time, but I don't think so. When it comes to multi-tenant computing, we operate under radically different assumptions than we did 30 years ago.