Kubernetes, Scala and Simplicity

Some thoughts on KubeCon EU

Sooo.. I worry that this is gonna annoy some people. That’s not my intention and I hope this comes across as constructive — it’s supposed to be. Disclaimers: I’m speaking only for myself, I’m pretty biased (I spend a lot of time working on Cloud Foundry, which is an alternate platform in a similar space) and.. I actually think Scala is pretty great: I just wouldn’t use it for most things. What do I mean by that, and what does it have to do with Kubernetes?

The Problem with Scala

The problem with Scala, as many people have found, is it’s very complex. Each feature that got added was individually useful, but the end result is a language creaking under the weight of all the different ways it has to do things. Of course, great Scala programmers will tell you to avoid the complex bits and just write simple code. But it doesn’t really work: you can’t build simple on top of complex. [1]

The Problem with Kubernetes

Which brings me to Kubernetes. After a couple days here at KubeCon EU I worry that Kubernetes is becoming the Scala of Cloud. That is to say a breeding ground for phenomenal ideas, an example of cutting edge computer science produced by fantastic computer scientists and way too complex to have much chance of building simple things on top of.

StatefulSets, ReplicaSets, Deployments, Apps, Allocations, Taints, Tolerances, Nodes, Jobs, Custom Schedulers, Privileged Pods, Operators, Service Discovery… any of these features individually sounds ok, but taken together it’s a scary amount of stuff for a regular ol’ developer like me that just wants to push code and have it work.

Talks Highlighting the Problem

This message doesn’t seem to have been lost on the folks here. Some great talks mentioned these problems (Joe Beda’s was excellent, as were Kelsey Hightower’s and Michelle Noorali’s) and there seem to be some SIGs dedicated to trying to build (more) higher level abstractions. Paraphrasing things I heard in both Joe and Michelle’s talks: Kube is being designed by system administrators who like distributed systems, not for programmers who want to focus on their apps.

I do hope this can be solved within Kubernetes. My instinct is it’s very very difficult to un-complexify things, or to build layers of simplicity on top of things that are fundamentally complex without hiding the complex thing entirely (and therefore much of its value). In other words building Go on top of Scala doesn’t buy you the simplicity of Go, it just buys you the complexity of Go and Scala. (As a similar analogy, building a DSL in Scala is possible, but it’s still Scala at the end of the day).

What does this mean?

So, what’s the conclusion? What does this mean? As a newish user coming to Kube — again with admittedly a lot of baggage from other systems — I think there needs to be a close look at which features are really truly needed and which are not. As we’ve learnt from operating systems, hiding an option behind a panel marked Advanced Settings does not get you out of making hard choices about what features to enable: features have costs, and sometimes building the right system requires saying no to perfectly nice features (like generics) that you haven’t found a simple enough way to do yet. Yes, I can just not use a feature, but if I have to maintain someone else’s system I need to know about any feature they might have used, and that’s a pretty large ask today in Kube from what I can tell. Hard choices need to be made, features need to be said no to and accepted slowly: basically Kube needs to avoid becoming the Scala of Cloud.

Please don’t hate me.


[1] Just to be clear I know lots of smart folks that love Scala and LOTS of smart folks that swear by Kube, I just prefer plain and simple, still-no-generics Go and I think that has important parallels in Cloud. It feels like Kube is being too quick to accept quite a lot of complexity.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.