Cloud systems are always built from three layers: machine, operating system (OS), and application. A few new projects are throwing away this classic approach and starting again with all-in-one applications and OSs. Projects like Mirage, HaLVM, and LING provide a stripped-down cloud alternative to multi-purpose systems like Linux. These all-in-one systems are called unikernels.

Will the new unikernel approach work? It is already working for a few edge cases, but will it take off and become mainstream? Maybe. Vendors sell dreams and customers choose to believe, so somehow the new unikernel projects must make the IT industry believe. Will unikernel projects, despite being innovation winners, lose the battle for customers? Or will they depose Linux from cloud computing and become the new normal?

Somewhere between these two extremes are the unikernel projects. Rather than using one central kernel, these projects put device drivers, protocol stacks, and other system building blocks into a library of modules. An application, a set of modules, and a runtime are combined to form a complete system.

The unikernel approach

Some academics and organizations are developing tiny all-in-one images containing an application and just enough OS to make it go. The unikernel idea isn’t theoretical — unikernels are running in the public cloud. The Mirage website is served by a working unikernel.

To create a unikernel, a developer writes an application and adds a few cloud OS libraries. After jumping through a few more cloud OS hoops, the developer ends up with a complete running system. Each unikernel project provides a build system that helps to churn out the machine-readable code.

In the Linux world, deploying an application means packaging it up for distribution to Linux systems. In the unikernel world, the application is a machine image, waiting to be turned into running instances.

A unikernel image is small; many unikernels can take up less space than one Linux machine. Also, a unikernal has got a single job to do, so performance is faster than a multi-purpose Linux system. In fact, unikernels are so streamlined that firing up a new instance can take less than a second.

This boot-up speed leads to some interesting possibilities. A new cloud machine can be created for every new user session, and destroyed afterwards. Creating a new machine for every single session takes the ephemeral computing idea to a whole new level.

The current state of unikernels has some clear advantages.

  • Small image size. Removing most of the OS means a unikernel can fit in a 5 MB image.
  • More secure. For instance, if the system doesn’t run a shell, it doesn’t have shell vulnerabilities.
  • Better performance. Much of the multi-tasking overhead disappears.

But don’t throw away decades of Linux development just yet. The unikernel approach has plenty of disadvantages.

  • Enterprise tools don’t work with the new cloud OS build process.
  • The developer is limited to one language. Mirage is tied to the OCaml language; HaLVM is tied to Haskell; and LING is tied to Erlang.
  • It’s new. Many components that should be in the library just haven’t been written yet. Even if a module has been written, it may be in need of optimizing.
  • Wedging an application into a unikernel is mostly not possible. Serious code rewrites are required before an application will work.

Where can a unikernel run?

Unikernels run on hypervisors. OpenMirage, HaLVM, and LING unikernels are combined with Xen virtual machines (VMs), as are most Linux systems. Xen VMs are common — Xen hypervisors are used in most public clouds, including AWS, Linode, and Rackspace.

Some unikernels are built for the Xen hypervisor. A Xen VM is a simple imitation of hardware (as opposed to the more complicated JVM and .NET runtime). A Xen VM on its own does nothing useful — it needs all the software (from operating system to business logic) to provide value. A unikernel contains an application and all the OS components required for a Xen-powered VM.

Can the enterprise use it?

It’s early days. While there are clear advantages to the unikernel approach, there are quite a few barriers along the way, starting with the lack of working applications. Who will write the missing pieces?

OCaml, Haskell, and Erlang are functional programming languages, which are not as popular as imperative languages. You won’t find these names on a top 10 list of “most-sought-after-by-business” languages, so they attract fewer professional programmers. On the other hand, all computer science students are taught functional programming. Perhaps the next wave of graduates will be hoping to make their money using unikernels.