On losing and winning

On losing and winning

I won an election last week(!), to the Knative TOC. But I did not get the seat: IBM and Red Hat already have two seats, and that's the maximum they're allowed in the rules (to avoid one company having a majority – fair enough).

Coming up to speed on Knative and getting involved in a new community over the last year-and-a-bit has been amazing fun. At its best, working on open source is magic: you get to jump in feet first to a project with teams of people from different countries and companies and help to make a thing (hopefully) people find useful. Working on Knative has been open source at its best.

I've been thinking a lot about abstractions and platforms and why a higher level platform hasn't really truly taken off yet, though many have tried.

The last few years have been pretty interesting. Starting with Heroku and Cloud Foundry and then seeing the rise first of Docker and then of Kubernetes. It seems like we started - with Heroku/Cloud Foundry - at the higher levels of abstraction, leaning towards developer efficiency at the cost of flexibility and infrastructure abstractions. Then, stepwise, with Docker and Kubernetes, we got further and further from high level developer focus as we solved more and more in the realm of complex distributed system automation.

Kubernetes has very much won, but I don't think that means the ideas behind Cloud Foundry or Docker (in the context of app development) have lost, so much as there's not a place for them in a critical mass of people's heads yet. Sometimes the right solution comes along at the wrong time. Often, this happens repeatedly until the right execution at the right time (and yes, with the right marketing) helps an idea take off. I always think here about the iterations of touchscreen phones before the iPhone. Touchscreen phones hadn't lost to keyboards, they hadn't won yet.

While we don't know exactly how to build a developer platform we can all - or at least that a critical mass of people can all - agree on, it makes sense to focus on the building blocks. But the cost is high: almost everyone I've talked to that's using Kubernetes in production is either rebuilding a custom PaaS for themselves, or is dealing with a lot of unnecessary complexity for simple tasks (most often the former, actually).

I'm not ready to abandon the idea of higher-level developer-focused abstractions that hide the complexity of Kubernetes for most developers. I simply don't believe most applications should worry about replicasets or deployments or statefulsets or Secrets or ConfigMaps or CRDs or, honestly, yaml. I don't mean to devalue Kubernetes by saying this, only to say that we're not there, yet.

Perhaps the abstraction that hides the complexity of Kubernetes will look like Cloud Run or Code Engine: just pushing an image and letting the platform scale it. Perhaps it will be more lambda-like, pushing code and single functions. (Perhaps Kubernetes itself will evolve to include these things out of the box)! Perhaps - and this is my bet - we will increasingly see deployment and scaling built in to programming languages in the way Golang builds concurrency in to the language via channels (while still providing an escape hatches to mutexes and the like). It will be fun to see.

In the meantime Kubernetes is really great at the problems it solves. And in the context of developer-focused platforms it's a great building block for a building whose shape we don't quite yet know.

Show Comments