Unikernels and Containers (2016/06/14)
Thanks to Docker (and Go of course) containers are applied for a broad range of use cases. They became especially important in the services world, for testing and development, and they also start to be interesting in the HPC community having specialized frameworks.
Since a year Unikernels became a topic, too. Until now it looks like the basic development of the frameworks is the main focus. Especially from companies focusing at IoT. I just stumbled over unik which allows to pack Go applications in a Unikernel.
So what are Unikernels and what differs them from containers?
Unikernels are OS machine images which are based on library operating systems. The typical case is that fully fledged operating systems are running and hosting many applications at the same time. With containers you still have the main operating system but through kernel features like namespaces, cgroups, and chroot you can isolate the containers from each other in a way that it feels like running in a different OS.
So with Unikernels you are doing something contrary: instead of sharing the same OS kernel you isolate applications within independent operating systems. Isn’t that what VMs are doing? No, since Unikernels are created for a particular application and hence only provide OS functionalities required for the particular application, they also seem to run in a single address space. Some advantages are certainly that you have real isolation between them (unlike containers), there is no specific kernel version and feature required for the shared OS under-the-hood. Also performance is certainly an aspect when it comes to HPC. No waste of context switches between privileged and unprivileged address space, IO, compute cycles, interrupts for unnecessary OS functionality. Highly specialized OS images can be tuned exactly for one use case and they are much smaller.
But how to personalize OSs without having an immense admin overhead?
This is where the library of the operating systems comes into play. The OSs are finally just created by frameworks during application development. So what we see is a movement from an admin controls everything paradigm on the compute farm (has to install libraries, applications), to devops where developers also has to think about how to ship the application like packing it with its dependencies in containers, to developer-packs-apps-with-dependencies-in-specialized-os.
Again this goes hand-in-hand with cloud computing paradigm where the infrastructure is just available (and as big and flexible as your pocket) and the developers have to deal with it directly. For running it on-premise the hypervisor approach seems to be used because of the underlying difficulty of having the right device drivers.