Docker is dead. Long live the Unikernel.

As the cloud-native ecosystem evolves, it is beginning to appear as if a challenger to containerization has emerged. In this blog post, I'm going to dive into what unikernels are, and why I think they will be the most likely candidate to replace container-based infrastructure.

Introduction

While there is no doubt that containers have changed the landscape in a positive way, they are not the promised DevOps silver bullet. On the other hand, unikernels are an emerging software infrastructure paradigm that seek to fulfill the DevOps manifesto by providing specialized, single-address-space machine images.

A unikernel is made of the following components:

• System libraries
• Language runtime
• Necessary applications

These components are compiled into a single bootable VM image that runs directly on a standard hypervisor.

Containers ≠ DevOps

One of the key things you have to look at when comparing containers and unikernels is the fact that the former still differentiates between the (op)erators who manage the applications, and the (dev)elopers who code the application.

In contrast, unikernels fulfill the DevOps promise by removing this barrier and forcing the development team to bundle everything they want into the deployment unit. Furthermore, deploying unikernel applications requires completely rebuilding the VM, so using configuration tools like Terraform and Jenkins is out of the question.

Unikernels avoid vendor lock-in

Another major advantage to using unikernels in your infrastructure is added agility by avoiding the trap of vendor lock in. Because a unikernel is a VM at it's core, it is inherently cross platform and cloud-agnostic.
Because a unikernel's basic unit of compute is a VM, it is easy to shuttle it from one cloud platform to another.

Unikernels also exchange the idea of "servers" for a more serverless approach. There is still a server, but for the most part it is self-sustaining and does not need the oversight of an operations team.

Containers are still too complex

Although they have solved a lot of problems in the DevOps space, containers as a paradigm were not the prophesized toolset that was supposed to take us to operations-free pastures. The complexity involved with running containers is often very time-consuming for teams, and those teams often find out that the hyped up tools have a lot of quirks that cause issues in production.

It often requires an entire ops team to manage and deploy a Kubernetes based application, while deploying a unikernel to Google Cloud with today via ops is merely a series of two commands and it will be running within two minutes.

Unikernels are secure

One of the biggest selling points for unikernels is their security when compared to containers. The architecture has many features that either prevents or disables certain attacks altogether. Let's look at a few of them!

No shell access

Most remote code execution attacks invoke 

/bin/sh

No Syscalls

On Linux systems, syscalls are often used to invoke the OS and attack computer systems. Because they lack an OS, unikernels don’t have these system calls. They only have function calls. For an attacker this means they’ll have to know the exact memory layout of your application in order to invoke the operating system.

No access to Ring 0

A common criticism raised against unikernels is that the whole application runs in “kernel space” and has root privileges. Currently, this is true, however this is because unikernels need to manage virtual hardware and page tables to run.

However, if the hypervisor can set up the VM before it is booted and provide para-virtualized interfaces to the hardware, access to ring 0 is unnecessary.

Conclusion

Containers will fade into obscurity. I can't say for certain when it will happen or what form it will take, but all technological paradigms come and go as the industry evolves.

Do you think my predictions are correct and we're about to see the dawn of the unikernel? Or do you think it's just another overhyped tool?