After Docker:
Unikernels and Immutable Infrastructure


I believe Docker is 2 steps forward for the world of DevOps and that the principles it promotes are forward-thinking and largely on-target for the future of a more secure, performant, and easy-to-manage cloud future. However, an alternative approach leveraging unikernels and immutable servers will result in smaller, easier to manage, more secure containers that will be simpler to adopt by existing enterprises.

Next Cloud

As DevOps matures, the shortcomings of cloud application deployment and management are becoming clear. Virtual machine image bloat, large attack surfaces, legacy executables, base-OS fragmentation, and unclear division of responsibilities between development and IT for cloud deployments are all causing significant friction (and opportunities for the future).

One example to illustrate these issues:

It remains virtually impossible to create a Ruby or Python web server virtual machine image that DOESN’T include build tools (gcc), ssh, and multiple latent shell executables.

All of these components are detrimental for production systems as they increase image size, increase attack surface, and increase maintenance overhead.

Specific to Docker, there are several issues with the current approach:

  • Kernel OS Fragmentation — Should you base your Docker images on Centos, Debian, Ubuntu, something else? Will ‘standard’ applications be supported on Docker for your OS of choice? Will your team gain leverage if you have to maintain all the images yourself?
  • Large Image Size — Docker images are large. Not as large as full VM images, but still big enough to make it difficult to transport images quickly over remote connections. Using smaller Linux base (TinyCore, NixOS) OSes can address some of this, as can building custom linux images — but this is still a nascent practice in the Docker community.
  • Still Insecure — Almost every ‘popular’ Docker image in the public repository still has a menagerie of latent binaries and shell executables available from bash to python, that can be accessed by expertly executed security breaches. (See earlier points on why this is bad)

‘But wait!’ you say, ‘CoreOS is minimal and optimized for Docker.’ Actually, CoreOS is a platform designed for orchestration and management of Docker instances. It’s not intended to be used as a base image for Docker containers. Specifically, CoreOS is based on Chrome OS, but the recommended base Docker image is Debian. This was an area of confusion for me — and apparently others too — as I learned about the CoreOS/Docker platform. It warrants more clarification in their respective collateral.

Immutable Servers & Unikernels

If you are knee deep in this world, then you should become familiar with two key concepts and start designing your operational systems with these approaches in mind.

Immutable Servers are a deployment model that mandates that no application updates, security patches, or configuration changes happen on production systems. If any of these layers needs to be modified, a new image is constructed, pushed and cycled into production. Heroku is a great example of immutable servers in action: every change to your application requires a ‘git push’ to overwrite the existing version. The advantages of this approach include higher confidence in the code that is running in production, integration of testing into deployment workflows, verifiability that systems have not been compromised.

Once you become a believer in the concept of immutable servers, then speed of deployment and minimizing vulnerability surface area become objectives. Containers promote the idea of single-service-per-container (microservices), and unikernels take this idea even further.

Unikernels allow you to compile and link your application code all the way down to and include the operating system. For example, if your application doesn’t require persistent disk access, no device drivers or OS facilities for disk access would even be included in final production images. Since unikernels are designed to run on hypervisors such as Xen, they only need interfaces to standardized resources such as networking and persistence. Device drivers for thousands of displays, disks, network cards are completely unnecessary. Production systems become minimalist — only requiring the application code, the runtime environment, and the OS facilities required by the applications. The net effect is smaller VM images with less surface area that can be deployed faster and maintained more easily.

As my colleague Kevin Goslar suggested, traditional Operating Systems (Linux, Windows) will become extinct on servers. They will be replaced with single-user, bare metal hypervisors optimized for the specific hardware, taking decades of multi-user, hardware-agnostic code cruft with them.

More mature build-deploy-manage toolset based on these technologies will be truly game changing for hosted and enterprise clouds alike.

More Discussion on HackerNews

More Reading & Resources

Errata

  • Original post said ‘CoreOS is based on Gentoo’. It’s actually a fork of Chrome OS (which is based on Chromium OS) and shares the Portage Package Manager with its Gentoo brethren. http://en.wikipedia.org/wiki/CoreOS HT to a HN commenter for the correction.