Inside IncludeOS - what is a unikernel?

IncludeOS is a unikernel, a special type of library operating system that allows developers to write and run their application in the cloud… in place, that is, of a more traditional OS.

Unikernels are said to run without many of the ‘heavy’ overheads of Unix-like OSs.

CEO of IncludeOS Per Buer argues that the cloud model of service-centric datacenter-driven computing exposed the shortfalls of generalised OSs and showed us how resources were often wasted on unnecessary functionality.

Some progress was made with containerised OSs, which became lightweight, but the design didn’t really change. The same generalised OS kernel sits on top of the hypervisor, which all containers running on the same host share.

So how do unikernels work?

Buer explains that unikernels turn the whole OS concept on its head. Only the libraries necessary to run a program are injected into the application itself. Architectures are clean; everything they include at the point of runtime serves a purpose.

The following text is presented as a Q&A with IncludeOS’ Per Buer.

CWDN: What are the advantages of unikernels?

Per Buer: A modern OS architecture organises virtual memory into kernel space and user space. The kernel secrets are kept away from users’ prying eyes. As Unix-systems were designed back when all applications ran on big shared servers, this made sense. This separation, however, means having to switch in and out of kernel mode, costing significant CPU time and resources.

Unikernels, by contrast, don’t need to do this ‘context switching’ so are relatively ‘lean and mean’.

Unikernel apps can also be started and stopped very quickly. A virtual machine running a unikernel only runs a single application so there are no ‘secrets’ to protect.

Another advantage of unikernels is security.

Traditional OSs are fundamentally insecure. The ability to dynamically reconfigure a system is the root cause of modern computer security problems. A unikernel’s simple design doesn’t let the OS reconfigure itself. Instead it relies on the sysadmin to build a new image and redeploy the server. Back in the 90s this wouldn’t have made sense, but today, this is often the preferred methodology for managing a complex infrastructure. You could say that unikernels are “immutable by design”.

A unikernel’s small code base also means fewer bugs. I remember many security issues back in the 90s with the «eject» program, which ejected the CD-ROM tray. The program even caused problems on servers that didn’t have CD-ROM devices. With a unikernel, the OS has no unused bits – these are stripped out during the build process.

CWDN For which type of applications are unikernels best suited?

Per Buer: Unikernels are a good fit for a range of applications.

Currently, unikernels create small, fast and ultra-scalable services that operate further down the stack than containers. So far we’ve used them successfully for firewalls, load balancers and similar applications. The virtual machines are small and fast, outperforming comparable Linux-system by quite a margin.

Our goal at IncludeOS is to expand the application runtime support to include those written in C++ and C, so Node.js and Python are strong candidates. Once in place it should be a good platform for edge applications written in these languages. For Node you could imagine doing «npm include» or similar and having the build system spit out a virtual image that boots straight into your Node application.

For people writing in languages such as OCaml or Reason, the Mirage Unikernel is excellent.

CWDN: Why aren’t unikernels more widely adopted?

Per Buer: Unikernels are a radically different approach to creating an OS — and we know from history that it takes time to benefit from any new approach to a widely standardised technology.

Back when steam engines ran factories, each factory had a giant engine driveshaft running through it. Later factories started replacing these giant steam engines with giant electric motors. It took considerable time before people realised that instead of having one huge driveshaft, they could connect several small motors in different parts of the factory using electric cables.

The situation with unikernels is similar.

We have this new thing and to some extent we’re using it to replace general purpose OS jobs. But we’re still very much limited by how we think about OS. Replacing Linux with a unikernel is one thing, but the really exciting stuff will happen when we realise that the way we view OS is holding us back.

The idea of having to emulate a whole computer with BIOS, PCI bus, and a floppy drive in order to run a virtual machine is pretty silly. Once we can free ourselves from that limitation, a whole new world for unikernels will open up.

I find that really exciting.