I am much of an ops person and I will say k8s has its place and its in 10-20% of companies max.

It is absolutely ridiculous how many places use k8s and rarely for what it can really do.

Cargo culted complexity, indeed.

Some people are really good at writing software, other people are really good at running systems. k8s/cloud allowed the former to pretend to be good at the latter.

k8s is misunderstood. Everyone focuses on the complexity/over-engineering/etc arguments when those really don't matter in the grand scheme of things.

It's not about any of that, it's about having a consistent API and deployment target that properly delineates responsibilities.

The value of that then depends on how many things you are running and how many stakeholders you have taking part in that dance. If the answer to both of things are small then k8s value is small, if the answer to either of those is high then the value is high.

i.e k8s is about organisational value, it's technical merits are mostly secondary.

The "it's too complex" argument usually reflects more on the commenter than on kubernetes itself. It's actually one of the most very straight forward and thoughtfully designed platforms I've ever worked with.

What I've found in my experience is that applications in general are complex -- more complex than people assume -- but the imperative style of provisioning seems to hide it away, and not in a good way. The inherent complexity hides behind layers of iterative, mutating actions where any one step seems "simple", but the whole increasingly gets lost in the entropic background, and in the end the system gets more and more difficult to _actually_ understand and reproduce.

Tools like ansible and terraform and kubernetes have been attempts to get towards more definition, better consistency, _away_ from the imperative. Even though an individual step under the hood may be imperative, the goal is always toward eventual consistency, which, really only kubernetes truly achieves. By contrast, MRSK feels to be subtly turning that arrow around in the wrong direction.

I'm sure it was fun to build, but one could have spent 1% of that time getting to understand the "complexity" of kubernetes - by the way, which quickly disappears once it's understood. Understandably, though, that would feel like a defeat to someone who truly enjoys building new systems from scratch (and we need those people).

You've hit the nail on the head. Ten thousand simple, bespoke, hand-crafted tools have the same complexity as one tool with ten thousand facets. The real velocity gained is that this one tool with ten thousand facets is mass produced, and in use widely, with a large set of diverse users.

I don't know a single person who's been responsible for infra-as-code in chef/terriform/ansible who isn't more or less in love with Kubernetes (once they get over the learning curve). Everyone who says "it's too complex" bears a striking resemblance to those developers who happily throw code over the wall into production, where it's someone else's issue.

> Understandably, though, that would feel like a defeat to someone who truly enjoys building new systems from scratch (and we need those people).

Exactly. Building new systems from scratch is tons of fun! It's just not necessarily the right business move, unless the goal was to get the front-page of HN, that is.

I'll take this bait:

Nomad is better for smaller teams and smaller companies with smaller problems than what k8s is for.

Helm is an abomination on top of it but that seems to be slowing down, thankfully.

I've been using Nomad for about 5 months now, and couldn't disagree more. K8s is better documented, with far less glue, and far more new-hire developers are familiar with K8s compared to Nomad. Nomad-autoscaler alone is becoming a decent reason not to use Nomad. The number of abandoned issues on the various githubs is another. That Vault is a first-class citizen of K8s and a red-headed-stepchild of Nomad is another.

I do agree about Helm tho, I avoid it as much as possible.

Fair enough, I don't know anything about nomad-autoscaler.

I hate kubernetes as much as anyone, but building your own container orchestration platform so that you can deploy a handful of CRUD webapps sounds a lot more like resume-driven development than using a well-known and standard (if somewhat overengineered) solution.

I don't think the authors care about their resumes at this point. There are rational reasons to use a static scheduling regime and a set of conventions around deployment and support services rather than a dynamic scheduler. If it were me, I'd build this with Nomad, but I can imagine not wanting to manage a dynamic scheduler when your workloads are as predictable as theirs are --- you make their case for them when you point out that they just have a "handful of CRUD apps".

There are other options between k8s and “build your own”.

What is there really? There is docker swarm, which doesn't seem to be really further developed, and... what else?

This whole space seems to be neglected since cloud providers are trying to sell k8s to big company "devops"guys but old school sysadmins don't even know what docker is. Any development in this area is very welcome.

> Perhaps this is the endgame of resume-driven development: cargo culted complexity and everyone using the same tech for similar-ish problems and then wondering why it’s so hard to stand out from both a product and an employee perspective.

Spot on. Tech is a fashion industry and most people just follow trends. I still sometimes wonder if people are playing the elaborate long-term resume-optimisation game, or if they don't value simplicity highly enough to optimise for it, because the downsides are externalised.

If there's discussion it isn't a sacred cow

k8s folks get paid big money to keep it running. Not surprised by the comments here at all. As the saying goes, "in complexity, there is opportunity." and the k8s devops team is milking it hard.

Agreed. I was having similar feelings reading comments.