Simplicity vs Complexity


3 mins


I just read another post (which read as a thinly disquised advertisement) discussing how great kubernetes (k8s) is, even though it’s difficult to implement and virtually impossible to use without a ton of custom development, and probably even then a consultancy should be engaged to get it right.

Umm… isn’t a framework supposed to reduce complexity?

Let’s get some disclosures out of the way: I’ve met all & socialized with one of the original k8s authors. Smart people, no question. Was k8s the right tool to solve problems they encountered inside Google when they created it?

Probably.

Is k8s the right tool for anyone else?

Almost certainly not.

Ok, now you’re hate-reading. Let’s dig in.

Containers promised simplicity. One service, one container. Wow! That’s great. Everything just works… inside that single container.

Congratulations, you’ve just reinvented the monolithic server, just smaller & less flexible.

I’ve used containers. I’ve written & deployed lambdas that do real work thousands of times. I have - by hand - written the orchestration (small bash scripts) that glues together containers colocated on the same host, such that a service running in container [a] can communicate with a service running in container [b].

I’ve never needed k8s for any of this.

But what about really complex macro applications that consist of dozens or hundreds of microservices - each running in its own container, because that’s what we were told to do? Doesn’t k8s allow you to configure and manage all the networking, ports, volumes & service names so stuff works?

Sure, but so does 100% bespoke bash scripts that exist nowhere else but in your custom-deployed shop. The overhead you’ve introduced - the complexity - with this framework eats up (and then some) any of the soft or hard costs your spreadsheeted-budget indicated you’d save by implementing containers.

"But we utilize almost 100% of our on-prem server capacity now by deploying multiple containers per server, so we are... blah blah blah"

You’ve traded known costs - that underutilization of servers & the imagined complexity of multiple services coexisting in the same IP, port & namespaces of those servers - for the unbounded costs of implementing a framework that forces you to reinvent all of those functions outside the individual containers.

How is that better?

I want to see real physical servers that are designed from the ground up to be plug-n-play with the volume size & type I need, the NICs I choose as well as CPU- & memory-compute requirements of the application that I deploy to it.1 There is at least one company working on reinventing physical servers and I’m looking forward to seeing what they create.

One server, one service. No extra configuration nonsense.

Simplicity, returned.

- jbminn

1 You’ll no doubt recognize this as nearly exactly what the cloud vendors provide, minus the physical part that you can touch. Instances are cheap, so why are you wasting time on all this extra stuff?