Unikernels

Unikernels are a cool concept. Take your application, take just enough OS to run it, and then combine them into a disk image you can boot in a hypervisor.

What

Containerisation is the current cool thing (or maybe it was cool a while ago, and I’m just behind); I’m sure others have noticed that the permissions system is a bit weird. Rather than start from a blank slate and add required permissions, we’re in this position where we’re not quite doing the opposite - but we’re still assuming far more permissions are required than may actually be required. This is exacerbated by docker images that run as root and ship with bash and curl by default.

Anyway, containers are taking full access and stripping it back to make it more secure. This isn’t just a case of filesystem access, it extends upwards and outwards, by means of cgroups and apparmor/selinux. You start with everything, and work towards nothing.

Unikernels approach from the opposite direction, in the most extreme way that could be practical. We start with nothing, and bolt on what’s required. The resulting image is ran on top of a hypervisor, and can do no more than what is strictly necessary.

I’m not particularly interested in the differences between containers and virtual machines, and I’m not going to talk about it here. They’re both ephemeral objects that do stuff.

Imagining the now

At the moment, you have a collection of nodes running kubelet. And those nodes running kubelet are managed in a system named Kubernetes. You tell kubernetes what you want by means of a HTTP API, and it (in turn) tells kubelet on each node what to do to make your dreams come true. More often than not, your ‘dreams’ are for a specific container, abstracted into a pod, which is abstracted by a deployment, to run in at least one place. Kubelet talks to docker, or cri-o, or something that can run the container, and keeps an eye on it while it runs.

That container is your application, and it is written to run on Linux, in a container based on Debian Stretch, on AMD64 hardware, with HTTP routing to the application handled by another container running some sort of HTTP reverse proxy that updates its upstreams based on information Kubernetes gives it periodically.

Imagining the future

In the future, you’ll have less nodes. Half because the government has restricted commercial power-usage to 1000kWh/y, and half because general-purpose computers capable of cryptographic primatives have required a license to operate since the terrorist bombing of Gateshead Ikea in 2029.

So you have fewer nodes. Those nodes also run a bare-metal hypervisor of some sort, maybe Xen with XCP-ng. You tell XCP-ng your dreams in a GUI, and it (in turn) tells Xen what to do to make your dreams come true. Unlike in the times before the Overseer came to power, your dreams are not abstracted into containers, into pods, into deployments. They are instead operating system images, and they run on top of virtual machines made by Xen.

That image is your application, and it is written to run on bare-metal. That sounds like a lot of work, but you used a library operating system, so it was really just some scaffolding and a lot of imports. You didn’t pull in Linux, and you didn’t pull in a Debian Stretch userland, and the archtiecture doesn’t matter since the machine it runs on doesn’t really exist. Routing to your application is handled by another unikernel that implements a HTTP reverse proxy. And the startup time for both is so fast that you don’t need the reverse proxy to update periodically - Xen just spins up another machine, which does its initial fetch, and then exchanges the IP address once it is confirmed ready.

Instead of orchestrating general-purpose Linux environments we’ve trimmed and shaped to be fast and secure, we instead orchestrate specialised virtual machines that were always fast and secure, and can’t be any other way.

I’m rambling

I am. This stuff isn’t even new. Virtual machine orchestration is the bread and butter of VPS providers, and has been for eons. But unikernels haven’t taken off yet. Here’s what I think is going to happen over the next decade:

1. Kubernetes is going to support virtual machines as a first-class alternative to containers. Kata already exists, but I’m talking formal first-party support from Big G. Unikernels and Serverless (marketing wank) are the reasons I imagine this happening.
2. Unikernels stop being scary. Maybe they get a friendlier name. Virtualisation stops being enterprise-y. Right now, I hear ‘VMware’ and ‘XenServer’ and think “enterprise misery”.
3. A big company takes the plunge. A real big company, that’s actually cash-flow positive. Not just some trendy startup on the front page of hackernews that’s in their second round of funding to cover the fact they have six million customers that don’t pay anything.

This post has been one big ramble. But I think that’s probably just how things are going to be these days. Rambling is certainly easier than carefully-worded and carefully-arranged thoughts. We’ll see.