Unikernels compile source code into a custom operating system that includes only the functionality required by the application logic producing a specialized single address space machine image, eliminating unnecessary code. Unikernels are built using the library operating system, which has the following benefits compared to a traditional OS:
Fast boot time: Unikernels make provisioning highly dynamic and can boot in less than a second
Small footprint: Unikernel code base is smaller than the traditional OS equivalents and pretty much as easy to manage
Improved security: As unnecessary code is not deployed, the attack surface is drastically reduced
Fine-grained optimization: Unikernels are constructed using compile tool chains and are optimized for device drivers and application logic to be used
Unikernels match very well with the microservices architecture as both source code and generated binaries can be easily version-controlled and are compact enough to be rebuilt. Whereas on the other side, modifying VMs is not permitted and changes can only be made to source code, which is time-consuming and hectic. For example, if the application doesn't require disk access and a display facility. Unikernels can help to remove this unnecessary device driver and display functionality from the kernel. Thus, the production system becomes minimalistic only packaging the application code, runtime environment, and OS facilities which is the basic concept of immutable application deployment where a new image is constructed if any application change is required in production servers:
The transition from a traditional container to Unikernel-based containers
Containers and Unikernels are a best fit for each other. Recently, the Unikernel system has become part of Docker and the collaboration of both these technologies will be seen soon in the next Docker release. As explained in the preceding diagram, the first one shows the traditional way of packaging one VM supporting multiple Docker containers. The next step shows a 1:1 map (one container per VM) which allows each application to be self-contained and gives better resource usage, but creating a separate VM for each container adds an overhead. In the last step, we can see the collaboration of Unikernels with the current existing Docker tools and ecosystem, where a container will get the kernel low-library environment specific to its need.
Adoption of Unikernels in the Docker toolchain will accelerate the progress of Unikernels and it will be widely used and understood as a packaging model and runtime framework, making Unikernels another type of container. After the Unikernels abstraction for Docker developers, we will be able to choose either to use a traditional Docker container or the Unikernel container in order to create the production environment.