Unikernels wins the ASPLOS most influential paper award / Apr 2025

I was gobsmacked to get a note from the SIGARCH ASPLOS steering committee that our 2013 paper "Unikernels: library operating systems for the cloud" won the most influential paper award at the conference last week! I couldn't make it to Rotterdam myself due to the travel time, but Richard Mortier was already there and so accepted the award on the whole team's behalf!

My officemate Simon Peyton Jones pointed out to me that these 'test of time' awards are his favourite, as they indicate that a piece of research was actually useful over a number of years to other people in the field:

The ASPLOS Influential Paper Award recognizes historical ASPLOS papers that have had major influence on the field. The Program Committee nominates highly influential papers from any ASPLOS conference that occurred ten or more conferences ago, with the final selections being made by the ASPLOS Steering Committee. -- SIGARCH awards

My long-time colleague Dave Scott wrote up a great overview of why he likes unikernels, especially in areas like Docker where he is a senior maintainer these days. Dave uses a nice jigsaw puzzle analogy to show the value of a library operating system approach when building complex systems glue; they're good for high assurance applications, for rapid experimentation and iteration, and for deep systems customisation.

I almost rage-quit academia

Richard Mortier's note brought up some memories about how this particular work made me almost rage-quit academia entirely. Back in 2009 after I returned to academia with Horizon fellowship, I spent a year of my life working on lots of libraries for the very first iteration of MirageOS, and published a USENIX workshop paper on it.

After that, it was time to do the full conference paper, so I spent another year (joined by more colleagues like Thomas Gazagnaire and Dave Scott in the early days) bringing yet more OCaml libraries to life to make the thing actually useful. Charalampos Rotsos and Richard Mortier spent forever on an OpenFlow implementation in pure OCaml; Balraj Singh sorted out the mess I made of the TCP stack congestion algorithms; Steven Smith hacked on Xen with me to add immutable pfn support. There was a lot of intense hacking going on.

We then trimphantly wrote up our work as a submission to OSDI 2012 after staying up all night for several days in a row to get the evaluation done, and... it got rejected. But the paper didn't just get rejected, it got rejected so hard that I couldn't bear to look at another OSDI proceedings for years. So hard that I can still the weight of the punch of that email as I opened it eagerly, a decade on. Some of our colleagues also had rejected OSDI papers that year; the Naiad paper got six reviews but bounced (later to win best paper at SOSP 2013), and Andrew Warfield had another that got nine (!) reviews before being shown the door. But ours got...three reviews indicating it bounced in the very first round, and one review scored us at '1/5', the lowest possible value. It made all that intense work seem like a total waste of our lives.

But then... one of the reviews shone out like a beacon. It was the longest review, and was full of directly actionable feedback. It began very constructively:

The approach described in this paper is a very reasonable design point, a natural intersection of the exokernel and libOS and the type-safe OS. It would help to refocus the abstract and intro on the precise benefits that Unikernel can provide, and to attribute each benefit to its origin. Let me take a stab at this, based on my read of the paper:

The reviewer then reinterpreted our submission to add more clarity:

• "eliminate several classes of security threats via type-safety" -- clearly due to the top-to-bottom use of type-safe OCaml.
• "eliminate several classes of security threats via ... an address-space which can be made immutable" -- is there any reason an analogous technique could not apply to a libOS version of libc?
• "progressive specialization" -- I didn't find this contribution very exciting. It's nice that I can execute the same OCaml app in a Linux context to debug it; perhaps this is especially important since we don't yet have good symbolic debuggers for OCaml apps standing alone in a VM. But it really doesn't seem like a central benefit.
• "developers no longer need to become sysadmins" -- This claim is specious. If a third party packages an app together with a Linux guest-OS stack to become an appliance, there's no reason that appliance would require any sysadmin-ish behavior more than a Unikernel appliance.
• "The resulting unikernels are also highly compact" -- Could this property not also be readily achieved with a tuned libc-based (that is, not type-safe) libOS? How precious is this property? Is the working set actually much smaller? And finally, how much of the reduction is because the rewritten application is much less functional than the industry standard it replaces? [...the review continues on for several pages]

Now, I didn't agree with all the points in the review, but they were restructured in such a way that made it clear that the reviewer had really thought about it, and had tried to pull out their own insights from the system construction. We ate up this feedback, and resubmitted it in a matter of weeks to ASPLOS adopting much of the structure suggested by this OSDI reviewer, and the paper got in with accepts across the board.

The best bit of all this? The OSDI reviewer voluntarily unblinded their review:

Review by Jon Howell howell@microsoft.com, intentionally unblinded.

Jon's obviously an expert in the field (his own 2011 paper on Drawbridge won the ASPLOS influential paper award last year), but it's how much time he took in helping out a sibling system that stuck with me. His kind, constructive and direct review kept me in academia, and although I still haven't met him in person (life got really busy right afterwards with Unikernel Systems), I definitely still owe him a pint!

Systems research a decade or more on

Mort also made me think about what we learnt from all this work that current students might learn from.

You never know which papers will sink or swim in the fullness of time and most never get that popular outside a small niche, so don't worry about that right now when doing the work! Focus instead of honing your systems intuition for why you're building something, and bring out the delta of your contributions clearly in the paper. When you're building a complex system, there's a lot of boilerplate and scaffolding necessary, but the core of the "thing that hasn't been done before" is what you know best, and it can take some time and conversations to figure out what that is.

Back in the day, most of our discussions about systems research happened after a day of deep hacking down at the pub. Since the pandemic, we seem to have lost a big chunk of that social discussion around our work collectively. While I still see people regularly for a swift half, it somehow seems more difficult to gather people in general. Part of that is that I don't go into the department much anymore due to the noise and cold (something Jon Sterling also observed recently), vs my cosy Pembroke office.

I'm not sure if it's just me or everyone else also feeling this, but I'm so zoned out after even a few Zoom calls that I'm just not very social afterwards. So one thing I'm aiming to do more consciously after Easter is to try to gather people down at The Mill more for a swift half (where they serve excellent Guinness Zero), and really cut down on remote interactions that aren't necessary.

And the last tip is from Barry Schwartz, who noted that the secret to happiness is low expectations. No matter how much works goes into a system, don't bank too much on the big papers making a splash. Instead, enjoy every step of the journey -- from building things, scrapping them, debugging odd failures, throwing ideas around, releasing the software, seeing adoption, scrapping it all and starting again, the whole journey! There will always be a reviewer 2 waiting to ruin your day if you let them, so don't let them in.

I also wonder how long paper publishing in its current form will survive; with the sheer number of publications coming out these days and the amount of AI generated output, it's difficult to see something published today having the same ramp as the work we did in the past few decades. Instead, adoption and rapid iteration seem to be the way to go. Thankfully, our University intellectual property rights remain liberal (patents aside, but who cares about those these days for software), so there's nothing stopping us!