What is an unikernel?
Have you ever heard of Unikernels? Their name comes from the “kernel”, the “core” of the operating system. The kernel is in summary what makes the link between the computer, this object made of plastic and metal, you who use it, and the applications that run on it. It’s the heart of the operating system.
The unikernel doesn’t install on a physical server but on a hypervisor that hosts VMs, virtual machines.
Virtualization
Today, there are several types of virtualization. We’re going to be interested in complete operating system virtualization systems, like vmware, xen or proxmox. To simplify, it’s an operating system installed on a “bare metal” machine (physical machine) whose purpose is to provide a system and network environment in which virtual machines will execute. These virtual machines are programs that behave like physical machines on which we install an operating system and applications.
Unikernels are part of these operating systems that we can choose for our virtual machines, as we could choose windows or linux, for example. The difference that characterizes them is a limited size and important specialization to only run specific programs/frameworks. They are a promise of operating system simplification in order to have more performance and security.
The unikernel, associated with the application, form the complete virtual machine. The classic operating system is meanwhile intended to run many applications.
Usually, when we have an application to run on a server, we run it on a complete operating system. But this system is ready for all possible cases. We actually start a gas factory that’s way too complex for our small need. This gas factory requires important skills that most developers don’t have.
Increased security
Who says “gas factory”, also says more numerous security flaws: to summarize, monitoring the border between the United States and Mexico is much more complex than monitoring the Monaco border. Unikernels, simpler, offer a much smaller attack surface than a complete system.
In any case, that’s what we’re promised.
In my opinion, they’re also much more recent in their concept and don’t allow benefiting from the experience of millions of servers running for decades. It’s therefore difficult to pronounce on overall security.
What about the application? Is the unikernel capable of catching up with flaws that the application brings?
We’ll have to see in use.
Hallucinating performances
The second important point of unikernels is the fact that they only load into memory what’s immediately necessary for the application. Exit useless system libraries and support for a whole bunch of cases we’ll never encounter with our application.
This results in an almost null memory footprint. Some unikernels give figures of the order of 5MB, which is ridiculously low, classic systems being able to use several GB of RAM without the slightest application running on them.
In addition to using very few resources, they load them fast: Unikernel startup only takes a few milliseconds, while a complete operating system can start in several minutes.
Unikernels vs Containers: An In-Depth Benchmarking Study in the context of Microservice Applications from Ghent University, in Belgium
The graphs above give comparable performances between unikernels in terms of startup, but lesser capacities in terms of requests per second. However, there are many cases, and results can be significantly different according to the chosen technology or type of unikernel.
The interest of unikernels on public clouds
The main interest of unikernels consists in the fact of being able to deploy very quickly packaged applications on public clouds (amazon, azure, GCP, etc…) while benefiting from services they provide around virtual machines, like load-balancers, virtual networks, metrology, databases as a service, etc….
When resources cost a lot, it’s interesting to be able to rely on solutions whose overwhelming majority of processing capacities are dedicated to the application and not to the environment to set up around to run them.
The rapid startup of unikernels also ensures infrastructure scaling capacity, each load increase step being low cost and extremely fast.
Don’t you see anything coming?
Unfortunately, today, all this remains only hypothetical.
I’ve been hearing about unikernels since 2014, but still haven’t seen effective application of the concept.
Searching for the term unikernel on google also denotes a lack of reality of their use:
We see peaks end 2015 and early 2016
After a peak end 2015 and early 2016, we witness a loss of public interest in the subject, which gradually falls into oblivion.
- The unikernel.org site has had no activity since 2017 on its blog.
- The ClickOS unikernel no longer has active development on its github since 2017
- The HaLVM unikernel hasn’t moved since 2018
- IncludeOS, itself, since April 2019
In conclusion
Started as a concept full of good ideas, but requiring enormous developments and tests, unikernels have never managed to reach the level necessary for their entry into production.
The multiplication of virtualization solutions, via hypervisors or containers, means that the place was very small for the development of a new type of virtualization. Resources were too weak to allow the arrival of unikernels.
In my humble opinion, the progressive fleshing out of solutions around docker and the long-standing grip of heavy hypervisors on part of the IT industry have killed in the egg emerging alternative solutions not bringing a spectacular gain in terms of maintainability, security or cost.
unikernels have the weakness of having to have heavy hypervisors as a base, without having the simplicity of use that docker can have.
But can we still hope to be able to use unikernels in production, especially in public clouds where they have certain interest?
No. I wouldn’t bet on it for the future, projects dying one by one in recent years. It was a beautiful idea, but which seems to join the cemetery of good ideas that will never reach maturity.
Sources:
On performances: Unikernels vs Containers: An In-Depth Benchmarking Study in thecontext of Microservice Applications