According to the definition from the Unikernel Organization, Unikernels are specialized,single-address-space machine images constructed by using library OS. Unikernel has been proposed to solve the security issue in Cloud environment, as it is non-trivial to set up the configuration of a traditional OS’s security, e.g. setting up the security policy of a Linux Cluster would be a challenging task, not to mention the security of the whole system needs to be monitored and upgraded 24x7. SELINUX has become the de facto standard for recent Linux systems, the isolation issue still exists, causing further potential risk expose. Containers such as docker has been widely deployed in cloud environment, but they are not a perfect alternative. The memory print of Docker images is smaller than that of the traditional virtual machines, and the computational resources scale is more convenient to manage. However, docker still has not solved the booting time and even a much smaller footprint.

Unikernels can be the solution to cloud environment security and performance as they have properties of fast booting and small size.

Let us consider a simple example from a literature. Assume we would like to develop a DNS server from the scratch on the cloud. We would like the DNS server to receive the domain name and translate it to ip address. Except for this function, we do not it to do anything else. As a result, it does not need console access routines nor advanced math library. In this case, if we develop this DNS server on a physical or traditional virtual machine, substantial resources will be wasted. Even if we build it on a docker image on the cloud, there are a great amount of libraries or processes that we do not need, thus causing a huge waste of computational resources. However, let us think of implement the above DNS server through a unikernel, only requested resources will be included in the project, thus saving much space and resources which can be instead dispatched for other tasks. And as the unikernel is dedicated to the DNS server, the resources can be designed to be high-isolated, which improves the security of the DNS server. Only essential libraries plus the functional code of the implementation would contribute to a much lower foot print.

There are also some issues exist in unikernel, which probably prevent it from being widely adopted by the industry. The developing and debugging on unikernel could be tedious as it is nearly impossible to debug a unikernel on the fly. As currently many services need to meet a strict SLA, it is impossible to let the system down and then debug or update it. This can be solved by providing redundancy(of unikernel). Someone advocates that it is not necessary to debug in a production environment. By accessing the data or log from unikernel, developers can debug the programs in develop environment or testing environment.

For the benificial of security enhancement, the use of unikernel makes some pieces that are routinely attacked by hackers absent:

  • command shell
  • utilities (to co-opt)
  • unused drivers or unused libraries
  • password files
  • connections to machines and databases

Currently, there are many open source Unikernel projects such as Unicraft, ClickOS, OSv.

By the time of writing on this blog, the unikernel organization has not been updated for a long time; and from the search results on Goolge and Google Scholar, the unikernel has become less popular than 2 or 3 years ago? Why would this happen? In my opinion, the disadvantage of unikernels are so obvious and inevitable that people are not confident to deploy their projects with unikernel, especially for those large-scale cloud-based projects. Below is the list of some aspects that unikernel has limitations,

  • Most Unikernels only support single process
  • Most Unikernel only allow single-user mode
  • As mentioned before, limited debugging
  • And impoverished library ecosystem

For me, if someone asks me about deploying a project on the cloud, I would suggest them to go for a docker and scale them with a k8s. I would only use Unikernel to do some hobby projects, which.

  • do not require multiple processes on a single machine
  • no need for multiple users
  • I can debug it my way
  • needs milliseconds startup time
  • might make sense as a transient microservice
  • I am tired of everyday security tools
  • needs to scale into a very high number of instances

Reference [1]Russell Pavlicek, Unikernels Beyond Containers to the Next Generation of Cloud, O’Reilly,2017