Talk about unikernels is starting to gain momentum. Still, these are such early days for this technology that implements the bare minimum of the traditional operating system functions. Its functionality is a topic we discussed last month in a post by Russell Pavlicek of Citrix. As Pavlicek wrote, unikernels implement the bare minimum of the traditional operating system functions — just enough to enable the application it powers.
They remove the bulk that comes with standard operating systems. They also reduce the attack surface, as they can be turned on and off at any time and are separated from the OS itself, except for the functions that are compiled with the application code into a single executable. It’s that executable that contains what’s needed for the workload to function on top of a hypervisor.
The result is a much smaller payload which can be deployed quickly, in high density, and with a greatly improved security footprint.
At ContainerCon, we discussed the unikernel topic in context with containers in a session moderated by Alex Williams, founder of The New Stack. Speaking on the panel were Jérôme Petazzoni of Docker; Adam Wick, research lead at Galois, a research and development firm; James Bulpin, head of technology for XenServer at Citrix; Anil Madhavapeddy, professor at the University of Cambridge, and Martin Lucina of Rump Kernels.
The panel addressed several questions, such as the following:
- Are unikernels related, separate or do they overlap?
- What’s the unique value that each of them offer developers?
- Where do unikernels fit into the container story?
- What programming languages are required to deploy unikernels?
Here’s a look at the similarities and differences that were discussed:
The group looked at the different choices in the unikernel ecosystem:
Some of the challenges that the panelists identified in discussions prior to the panel discussion:
- Debugging/logging integration with operations tools.
- The need for easy to use Docker-like build frontends.
- Continuous deployment and orchestration engines.
As container technology continues to move forward with the release of Docker 1.8, unikernels stand apart as a way to build lightweight applications complete with dependencies that can be taken apart, restructured, or split into further individual processes based on the needs of the project.
Galois brought an R&D project from a client in core OS design that presented unikernels as a way to refactor programs quickly while avoiding bottlenecks. Wick spoke of another instance in which unikernels were a solution offered to allow a client the ability to use Xen on a laptop to run Windows in their secure facility by re-routing network traffic to an IPsec tunnel in a lightweight and secure application.
Unikernels also allow for mix-and-match flexibility based on what a developer needs to create an application. Rump Kernels are built for getting the maximum amount done while reusing as much existing code as possible. Unikernels address current security concerns taking place surrounding containers, by presenting the ability to have applications that are robust while also having the security of a hypervisor without the drain on system resources.
Comparing Unikernels and Containers
Containers and unikernels are similar technologies, with unikernels described as, “A Docker container on a diet.” By bringing unikernels to Docker, this could allow for more development teams using them and becoming more familiar with the technology, as has occurred with Docker and working with unikernels. Rump kernels are used as a testing and QA framework, maintained and production-quality, with KVM support alongside bare metal support. Containers and unikernels accomplish the same goal, isolating processes and code to run it separately. Panelist Martin Lucina highlighted one of the major differences between Rump kernels and others during the panel, stating:
“The thing to know with Rump kernels is it’s about getting the maximum amount done with a minimal amount of ucode and re-using existing code as much as possible.”
If one is building mission-critical systems, unikernels give developers explicit control over core security areas of their application. Developers can choose the output result while working with unikernels. In comparison, Docker containers have everything they need to run enabled by default. In unikernels, many features are turned off by default, meaning more initial setup and choices for a project team. Once these choices have been made, the result is resilient new stacks that are secure while also being customizable to the needs of the project.
Unikernels in Modern Dev Environments
The first generation of cloud focused on orchestration: how to take an existing workload and make it agile. That made perfect sense. We already had fully functional, complex application stacks from the time before cloud; we just needed to fit these applications into the new world of the cloud. Panelist Adam Wick offered an example of where unikernels will shine in a modern dev environment for those that may be struggling to see where they can apply unikernels in their pipeline:
“Network protection services, network routing, or software-defined networking are great places for unikernels. If you’re asking yourself if one is great and 100 would be better, then a unikernel could be a great choice because you can run 100 pretty easily.”
However, the next generation of cloud needs to create workloads which are efficient, fast and secure. The current workloads use full machine images, from a general purpose operating system with supporting libraries and utilities up to the application layer. They have large memory footprints, can use gigabytes of disk space just on the operating system level, and can take minutes to start up. They also suffer from potentially large attack surfaces, as a full operating system layer with utilities can be fertile ground for malevolent crackers to plant their weeds in your IT garden.