What's old is new... Unikernels are quite reminiscent of the VAXELN product from ~30 years ago; write the application code, link in the various services you need, and disk or network or ROM boot the results:
It was less "reinvention" and more "making them actually useful." From the ACM announcement[1]:
Although the concept of virtualization was first explored in the 1960s in the context of mainframe computers, it languished until Mendel Rosenblum and his students at Stanford University rediscovered the idea as a simulation tool for new multiprocessor architectures.
It goes on to point out how they created a vibrant industry and research area around the technology and spurred a shift to virtual-machine-based architectures.
Eh, most of the fun of alt.folklore.computers is listening to a bunch of geeks who were there from the time CTSS seemed like a novel idea moan about how everything was done before, either by DEC in the 1970s or IBM in the 1960s (or 1950s!). Oh, and DEC, not Digital: The VAX was an abomination and command line technology peaked with TOPS-20, if not TOPS-10.
(Seriously. One of the people I quoted claimed elsewhere, without any hint of irony, that IBM invented personal computing by putting CP-40 on System/360 mainframes, to give everyone their own personal guest system on the shared hardware. Yes, and the Ancient Romans invented radio by reflecting sunlight with mirrors; after all, it's all EM radiation!)
Or processes. If your hypervisor is KVM, then your KVM + unikernel essentially is a Unix process running on the host, just using a rather complex API instead of syscalls.
Of course in many ways "cloud" computing is just another implementation of a 370/VM mainframe system. I find the evolution fascinating. Oh and I had a comms processor (terminal server to a modem bank) which turned out to just be a MicroVAX 3 runing VAXELN. The CPU was some what "cut down" (I think optimized was the word they used) to make it more cost effective. VMS would not boot on it.
I would argue that in a world where we've progressed past Linux and C, but still talk about using PHP, MySQL and Java, and other such middleware, including Ruby, Python, Perl and so forth, not much actual progress has been made after all.
It would simply feel like standing still, for an overhwelming majority.
Exactly. In my mind that's the best thing about these projects: the technical benefits are so amazing they might actually encourage people to look beyond the Linux-and-company systems stack.
(Although, to be fair, most people run a Linux dom0.)
What's weird and funny is the collapse in complexity this represents.
Linux, NT, BSD, and other modern kernels implement all kinds of complexity around user/group management, ACLs, security policies, file types and permissions, and so on.
If we're moving to unikernels and containers and similar, all that has been replaced with stupid simple access control systems like API access tokens or login/password pairs for cloud service control panels. Your AWS access token is now a single security credential for your entire infrastructure.
Of course I'm sure the cycle of reincarnation will continue. Things like Docker or the AWS API will grow in complexity until they at least subsume the entire feature set of Unix UID/groups, Unix/NT ACLs, SELinux, etc.
For those who are interested in this, you may also be interested in ZeroVM[1].
To be clear, ZeroVM isn't a Unikernel. Instead, it is a virtualization technology based on NaCL[2] that is designed to quickly create throw-away VMs. The idea is that the VMs is created to service a single request, and disposed of afterwards.
Obviously this model has challenges, but it is similar to the model proposed on slide 24 of the OP slidedeck. The security benefits of this are real, even if the programming model is challenging.
I love the idea, always have. Does a unikernel application need statically allocated amount of RAM or is there a way to have unikernel-programs allocate memory dynamically?
Maybe this is where garbage-collected language would be useful.
The way it usually works is that the guest OS gets a certain allocation of RAM and if it doesn't want to use it all it can inform the hypervisor of which ranges don't need physical backing at the moment. From the guest's perspective this is often implemented using a "balloon" process/driver that reserves a large chunk of guest memory in order to return it to the hypervisor. It can also be handled by the guest having a more general memory hotplug capability.
I was happy to see Clive, and I imagine a RUMP implementation or other unikernel that supports Rust won't be far away. Being able to compile Go or Rust to metal byte code is absurdly sexy.
I don't know how AWS will meter it yet (yup, I love AWS) but I sure hope they're following this trend. AWS support would put so much energy behind this path forward.
No. It is SaaS with an installable client. But we do have a free tier that is perfectly aligned to the AWS free tier. Also there is no lock-in per se as you give Boxfuse an app in a standard format (.jar/.war) and Boxfuse turns it into an image in a cloud native format like an AMI for AWS. All this with just a single command.
I believe the problem isn't so much that DO, etc., don't support unikernels, as that they use something other than Xen as the virtualization layer; something-other-than-Xen is still on the to-do list of the unikernel projects.
The rump kernel unikernel (rumprun) will happily work on actual hardware. It's a bit hazy if that's a unikernel or an embedded system in that case (and what's the difference anyway?), but to avoid hairsplitting, you can replace the hardware with KVM and off you go.
http://odl.sysworks.biz/disk$vaxdocdec953/decw$book/d33vaa48...