The History of Unikraft

Last week, partly as a result of a post reaching #5 on Hacker News and then another one the #6 spot less than 24 hours later, the Unikraft Linux Foundation open source project hit the amazing 2K Github star mark, and then raced onwards to more than 2.2K stars as of this writing. First and foremost, we owe a massive debt of gratitude to our incredible community — these numbers are a testament to your support!

And now with the most important out of the way, it’s time for a trip down memory lane.

The Beginning: A Research Project about Virtualizing Routers

A long long time ago, back as far as 2009, a British EPSRC project called “virtual routers” got started with the purpose of, surprisingly enough, virtualizing routers and packet processing in general. The project had as goals (1) to place several (virtualized) routers on a single server and (2) build a single “virtual” router consisting of multiple servers — though we never got around to the second part because the first was just too much fun to work on. 😃

One of the researchers in that project was Adam Greenhalgh, who, if memory serves me well, was looking at the Xen Project as a basis to virtualize a router. At the time we were working with the excellent Click Modular Router toolkit from Eddie Kohler for packet processing, but hadn’t settled on the virtualization part. Xen being open source and based in nearby Cambridge (there were plenty of pub-based exchanges between UCL and Cambridge University at that time) made it an obvious choice for the project.

Long story short: Adam started, probably at Rolf’s suggestion, to have a look at Mini-OS. Mini-OS was, and still is, a minimalistic, Xen reference OS for building stub domains. But what was interesting for us was that because it was tiny, we could very easily build an extremely specialized OS that would do one thing and one thing only: run packet processing via Click. After lots of fun with Makefiles, Adam and co. compiled Click with Mini-OS, and a new era was born: an extremely specialized virtual machine to do packet processing, i.e., a unikernel.

But the term hadn’t been coined yet (that honor would go later to people at Cambridge like Anil Madhavapeddy and others). At the time not even the term Network Function Virtualization existed, although projects like virtual routers helped coin it. Fast forward to 2014 and the work eventually led to ClickOS, with ClickOS unikernels consuming just 5MBs of memory, cold starting in 30 milliseconds, and processing millions of packets per second — back when that was a lot 😀 .

Enter Containers and Docker

Post-ClickOS, we were busy doing unikernel research based around more general processing than just packet processing. Out of this work came things like Minipython and Minicache (yeah, we weren’t too inventive with our names were we? 😀). We had also started bouncing the idea around that we should build a much more generic unikernel project that could cater to lots of applications at once, all the while still allowing for specialization — but I’m getting ahead of myself.

What also happened around that time (2014-2015) was that Docker and containers took over the world. The trusty but heavy, bloated, and slow virtual machine (VM) was dead, and lightweight, secure and extremely easy to use containers were here to take its place. It’s 2024 and we now know that containers are not a silver bullet, but back then this wasn’t obviously so , and so we started concentrating our research efforts on showing that if you were smart about how you constructed VMs (read: unikernels of course), you could have container-like lightweight properties while retaining the strong hardware-level isolation afforded by VMs.

That line of research resulted in the SOSP paper My VM is Lighter (and Safer) than your Container, with an intentionally provocative title 😀 (in actuality, we love containers, and have closely integrated Unikraft into the Docker ecosystem as explained in this blog written by my co-Founder Alex Jung). The SOSP paper was published towards the end of 2017 (it often takes a long time to produce a complex paper and publish at SOSP, arguably the best OS and systems conference in the world) and even hit Hacker News.

At that conference, and other systems conferences where industry has a strong presence, we were starting to get questions about the possibility of applying unikernels in production, given the orders of magnitude improvement in metrics like memory consumption, boot times, image size, and TCB. Invariably our answer was along the lines of “in principle yes, but these are hand-built unikernels, each takes months to put together, and we’re just researchers”.

Enter Unikraft

What had been brewing in the back of our heads for a while now was starting to turn into a hot fire. Back in 2017 and prior, we (my co-founder Simon Kuenzer and I, but others too) had been part of the Xen Project community. Thanks to Xen’s incubation project program, and encouragement from its community manager at the time, Lars Kurth (whom we all miss) and others (I seem to remember Anil Madhavapeddy also prodding us in that direction), we successfully submitted Unicraft as a Xen Incubation Project.

Now, before everyone writes in to call me out on mistyping the project’s name 😀, note that Unikraft was born Unicraft, and only later changed to Unikraft because of name clash/trademark reasons. And kraft with a “k” means power in German, where the project originated, out of the NEC Europe research labs in Heidelberg. So unikernel + power = Unikraft, super clever I know (we were clearly better researchers than marketing/naming specialists 😀).

But back to our story. In addition to the amazing warm welcome into the Xen community, a Xen incubation project has the added benefit of coming with Linux Foundation membership (you can still read the announcement from December 2017 here ). And so one late fall day, with this simple, initial commit, Unikraft was born:

Incidentally, just prior to this commit we had tried to register Unikraft as a Github organization and had noticed that someone had already done it, except we had no idea who it was. I even went as far as contacting Github, asking if I could get the person’s contact details to clear things up, but they answered that the best I could would be to report a fraud. Eventually Google came to the rescue: we found a certain Alex Jung from Lancaster University who was absolutely convinced that the vision behind Unikraft was correct, who then came to work with Simon and I, and who eventually become our co-founder (good thing I didn’t report him for fraud! 😀)

But back to Unikraft. The reason behind its creation was to build an operating system and toolkit that would make it easy for people to build unikernels, and through that make their power accessible to more than just a number of researchers and OS experts. We designed Unikraft around three key principles:

1. Fully modular, to make it possible to fully specialize each virtual machine image, and extract the best possible performance out of deployments.
2. POSIX compatible, so that if and app/language runs on Linux it should run on Unikraft, unmodified.
3. Tooling integrations, to meet users where they’re at, integrating with popular tools like Docker, Kubernetes and Terraform.

But this was just the beginning.

A 5-Year Development Journey

To make a long story short, from that first commit it took the better part of 5 years to get Unikraft to the point where it was functional enough to run a wide range of modern applications and languages. The effort was led initially through a number of EU research projects, including the aptly named Unicore project (we never got better at names 😀), universities and research institutes.

The culmination of years of effort were summarized in the Eurosys 2021 paper Unikraft: fast, specialized unikernels the easy way, which received the best paper award (as this is an article about the history of Unikraft and not its technical aspects, I invite you to delve into its gory details in that paper). That paper also hit Hacker News.

From there on out, the Unikraft community continued to grow, thanks to amazing efforts by maintainers, contributors and individual supporters; a big boost came undoubtedly from having Razvan Deaconescu come on board as the most amazing, full-of-energy community manager. As shown in the graph, Unikraft has experienced pretty steady growth, with noticeable spikes whenever the project hit sites like Hacker News.

2022: A Startup is Born

And that brings up almost to present day, or at least to 2022, where my two co-founders and I, our community manager Razvan and our head of engineering Marc Rittinghaus, decided that Unikraft was mature enough to bring it to real-world deployments. Towards the end of that year we launched Unikraft (the company), backed by a set of incredible investors who shared our vision of creating a revolutionary, much more efficient cloud offering (you can see a longer explanation of the story behind the startup here).

And so KraftCloud emerged: a next generation cloud platform leveraging Unikraft unikernels and offering millisecond cold boots, autoscale and scale to 0, all of the while being able to stuff potentially thousands of hardware-isolated VMs (well, unikernels of course) on a single server. Special shout out to our amazing team! (see pic of smiling team at the bottom of the page 😀) .

Onwards and Upwards

What about Unikraft’s future? Well, needless to say, we’re extremely excited about it, and would love for you all to come build it with us! Here are some concrete actions you could take if you’re interested:

• Join our OSS Discord server.
• Check out our OSS site and locally deploy your first unikernel with a single command.
• Sign up for KraftCloud and experience the only millisecond cloud platform (closed beta).
• Join the KraftCloud Discord server
• And of course give us a star if you haven’t yet 🙏

A huge thanks again on behalf of the entire Unikraft team and looking forward to building, together, the future of Unikraft. Onwards and upwards! 🚀