> Sorry, but we did all of that 20 years ago, and those approaches remain a lot simpler for basic use cases.

Yeah, we did, and they were complicated then and they're complicated now. The difference is some of us have decades of experience which make them feel simpler.

> And if you think that Kubernetes is always the right approach, then you clearly are NOT aware of the tradeoffs.

I was very explicit that Kubernetes isn't always the right approach. Allow me to quote myself: "If all you're ever doing is hosting a static blog, then yeah, you don't need something like Kubernetes". My point is that things like Kubernetes and Docker Compose are increasingly viable defaults for nontrivial cases. In other words, if you know you're going to have a bunch of services to manage, it's a lot easier for most people (i.e., those lacking decades of experience) to manage them with the aforementioned tools rather than trying to build an equivalent "platform" from scratch.

Kubernetes wraps several layers of abstraction around the old way of doing things. There is no world in which the operation of the site is in any way clarified by involving Kubernetes. Kubernetes also adds performance overhead. There are things which are easier with Kubernetes. But only after you've climbed a long learning curve.

From what I've seen, even people without "decades of experiment" find the non-abstracted system easier to understand and reason about than the Kubernetes version. And the difference in ease is dramatic.

Examples where it makes sense include:

1. You need to deploy multiple independent systems with similar configurations. (Even then, consider ansible.)

2. You have to deploy different clusters of connected systems with related, but different, components.

3. You need to scale up and down what needs to be deployed. (Except don't try to use autoscale. That only works in marketing blurbs.)

4. Somebody else has set it up and you never need to actually understand it. (Good luck if you need to debug.)

But there is no reason to introduce Kubernetes because you need a database, a few webservers, front end proxy, failover, etc. And if you are using Kubernetes for that, odds are that you'll save yourself a world of headaches (and potential security holes!) by migrating away. No matter how much the "chief architect" may claim otherwise. I've seen how this plays out in practice.

I think we have starkly different experiences then. I’ve been part of several orgs that started out doing it “the old way”, and anything to do with servers was so difficult that it was relegated to a team of experts. Then we introduced Kubernetes and while there was a learning curve, the development teams were able to own significantly more of the infrastructure with the infrastructure experts owning management of the core and a few convenience operators. Stories like this are echoed all over—that’s virtually the DevOps narrative—container orchestration enables development teams to own their own infrastructure with a dedicated team maintaining a common platform.

Moreover, for single-server use cases, Docker Compose eschews a lot of the complexity that Kubernetes brings for HA purposes while also masking over much of the complexity of managing bare servers.

The Kubernetes (and other container orchestrators) learning curve is substantial, but it masks a lot of incidental complexity that operators would otherwise need to understand to do it themselves.

The fact that you're talking about organizations large enough to have multiple development teams which serve their stuff separately puts you squarely in my case #2.

A 50 person company with <10 developers has very different problems.

No, but the operation of Kubernetes is clarified by actually running Kubernetes. Hacking.. or “homelab”-ing is doing it for the pleasure or the edification.