Introduction, What’s a Unikernel and What do you use it for?
Running an application involve a whole set of layers running behind it, in the traditional way you’ll need:
- The language interpreter
- API’s of the OS
- API calls requiring other level privileges (user space vs kernel space)
- The OS where everything is running
- Which can be a VM on VMware, Xen, etc
- Running on its own virtualization OS
- The one finally runs on hardware which in turn is bootstrapped by a BIOS or UEFI
This development path involves complexity. It’s understandable why this is the current path, because OS are designed for general purpose, they are built in a general way that will allow you to built almost any kind of application and it works for the majority. But, when looking for specialization and reducing the complexity of this development process, another options rise up on the horizon. These new options attempt to remove some of the layers in order to simplify the complexity of application development proposing more lightweight and lean approaches, which of course will have an improvement in cost, speed, maintenance and even security.
The first attempt to simplify application development is the transition from traditional VMs to container-based approach. Traditional VM’s are a logical/software abstraction of a machine that can be used by end users as a physical machine. The hypervisor is the tool used to provide, manage and maintain the virtual machines. They grew up in popularity because VM’s allowed to run multiple operating systems in a single machine thus reducing costs and maintenance.
Containers, a newer approach, are logical entities running on the same host operating system. They provide a lightweight virtual environment that isolates a set of groups and resources like memory, CPU and disk from the host and other containers. Unlike VMs that require a OS host to run on, containers uses an abstraction engine which abstracts the OS level details from the application.
So, basically, in a traditional virtualization each application runs in its own private VM, with its own OS instances, libraries and binaries. On containers, each application runs on its own container with its own libraries and binaries in an isolated process with its own virtual filesystem, but shares common guest OS with other containers on the same OS instance.
But, lately, another option arose to the surface, and it’s called Unikernels. Unikernels try to be the “just enough” of the operating system to run your application removing the layers that separates hardware from applications, thus removing the complexity of current OS. This way, all the drivers, services or packages that don’t apply to your application can be dismissed from your Specialized Kernel (Unikernel). The official definition of Unikernel from Unikernel.org is the following: “Unikernels are specialised, single address space machine images constructed by using library operating systems. A developer selects, from a modular stack, the minimal set of libraries which correspond to the OS constructs required for their application to run. These libraries are then compiled with the application and configuration code to build sealed, fixed-purpose images (unikernels) which run directly on a hypervisor or hardware without an intervening OS such as Linux or Windows.”
So, in few words, Unikernels are a summarize and reduced version of a current kernel, keeping only the most basic kernel libraries needed for your application to run, disposing what’s not needed but without reinventing the most need ones.
- Improved security – Reduce the amount of code deployed which reduces the attack surface
- Small footprints – Are smaller than traditional OS deployments
- Fast boot – Boot times measured in milliseconds
- Highly optimised – Its compilation model enables whole-system optimisation across devices and application logic
Unikernels and Containers (Docker)
Containers already provided to traditional OS the possibility of multiple containerized applications moving this way towards the microservices world. But now, Docker has acquired this year Unikernel Systems with the purpose of integrate Unikernel support to its own tools. By this recent movement Docker plans to work even further on the microservices world. So instead of just having containers in current VMs, now containers can start living in Unikernels and take advantage of the benefits Unikernels provide such as security and efficiency. This path is also shrinking the payload, that started from VMs, moving to containers and finally going after Unikernels.
Unikernels indeed contribute with benefits at the time of application development but they are not of course the answer to everything. Because they are specialized to specific applications thus they are only able to run a single application.
If what you need is an application with as little overhead as possible then writing it as a Unikernel is the solution. To do this you will use a library operating system. This will provide the basics to create you own Unikernel and when I say the basics I mean, a set of drivers and libraries needed for you to not reinvent things like TCP stack and those kind of things. Some of the libraries operating system or Unikenel implementations are:
- MirageOS – Written in OCaml language and runs under Xen hypervisor. It’s a library operating system that constructs unikernels for secure, high performance network applications across a variety of cloud computing and mobile applications.
- ClickOS – High performance, virtualized software middle box platform based on open source virtualization. ClickOS VMs are small (5MG), boot quickly (20ms), add little delay (45us).
- Clive – Operating system written in Go, designed to work in distributed and cloud computing environments.
- Drawbridge – It combines two core technologies: a picoprocess, which is a process base isolation container with a minimal kernel API surface, and a library OS, which is a version of Windows enlightened to run efficiently within a picoprocess.
- HaLVM – A port of the Glasgow Haskell Compiler tool suite that enables developers to write high-level, lightweight VMs that can run directly on the Xen hypervisor.
- IncludeOS – A minimal, service oriented, includeable library operating system for cloud services. Currently a research project for running C++ code on virtual hardware.
- LING – A unikernel based on the Erlang/OTP and understands .beam files. Developers can create code in Erlang and deploy it as LING unikernels. LING removes the majority of vector files, uses only three external libraries and no OpenSSL.
- OSv – Designed specifically for cloud VMs from Cloudius Systems. Able to boot in less than a second, OSv is designed from the ground up to execute a single application on top of any hypervisor, resulting in superior performance, speed and effortless management. Support for C, JVM, Ruby and Node.js application stacks is available.
- Rumprun – A software stack which enables running existing unmodified POSIX software as a Unikernel. Rumprun supports multiple platforms, including bare hardware and hypervisors such as Xen and KVM. It is based on rump kernels which provide free, portable, componentized, kernel quality drivers such as file systems, POSIX system call handlers, PCI device drivers, a SCSI protocol stack, virtio and a TCP/IP stack.
Unikernels are growing in popularity although the implementations and documentation around them are still in low levels. But, what I can say from this brief research is that Unikernels are the result of this increasing wave to simplify more and more the development application process. It’s been a constant improvement where reducing costs, complexity, time and processes around it play an important role. Unikernels are bringing a whole new way of application development impacting on one of the most important components of the development process, the OS, one of the low levels on the application development chain. Is not like it’s being discarded but it’s being simplified to only contain the most essential and fundamental code for your application to run, making of this new development process a very truly specialized one.
This new paradigm if we can call it this way, make me think that, maybe in future we will see new technologies working around lower levels in the application development chain.