Performance and Composability

I’ve read blog updates and manifestos from the Unikernel crowd for the last couple years with interest and some trepidation, and I think this article is as good an excuse as any to discuss why.

First, I’d like to mention that most of the claims are true. Context switches are expensive, the venerable socket API is a limiter for super high-traffic servers, and C code is dangerous, and subject to an un-necessary array of flaws. On the other hand, I don’t believe the cases for Xen is that strong, although I’m not sure this is the best place to litigate it.

Most deployments are worried about operability and availability, not performance. I make this assertion based on my own experience- which involves a lot of worries about application-level locks, and lots of database bottlenecking- and not much that was limited by the fundamental design of Unix sockets. It’s also worth noting that it’s really not very hard to work around this problem with money- if your application is bottle necked on context switches, adding more boxes will solve that problem. This is an amazing, and amazingly easy, situation to be in, and probably any company in this position will solve it with money. It’s not even going to be very expensive. The problems that seem to keep people up at night are about things that are really hard to solve with money, and have to be solved with engineering time instead- “how do we change our database schema to scale out”, “how do we manage a migration from X to Y”, and “how is our caching layer subtly broken?”

The author also gives no value to having a common operating layer. Given a broken application, in any application, an operating system lets me run all sorts of arbitrary tools to instrument, trace, and debug the problem. All of this breaks with a unikernel. Worse, it’s now entirely language specific, which means everything must be redone from scratch on a per-language basis. It also lets people collaborate outside of the tyranny of development tooling- running statsd alongside applications that report stats is a very effective way of keeping the complexity of batching, retries, etc., outside of the various language libraries, and inside of a common, reusable program. Footnote 10 is an interesting concession to this. But it’s not clear why every other part of the author’s critique doesn’t apply- to get between VMs, you have to context switch. You could imagine building a tower of unikernel’s to get back to something that looked like a standard Unix, but to what end?

To be frank, most of the author’s identified problems with Linux look like the problem of systemic underinvestment in boring but necessary base libraries and utilities. It’s not clear to me that rewriting that universe from scratch solves that problem- wait ten years and you’re there again.