I think grumpy old man knows about the drawbacks with VMs, but grumpy old man also knows that for his particular service k8s has drawbacks. Grumpy old man is thinking that if his particular service goes down, some users just tell him it's not working and it's not a huge problem like people are losing $10 million per hour because of it. And in the event that happens sometime in the next 23 months (if it happens at all) he'll just do that little manual process for a couple more VMs, and that's all the time he'll spend on it. Contrast that with the time it would take to get it ready for k8s and keep someone around who understands k8s well enough to take care of it, even though their need for it might be so low.

And grumpy old man also knows that compared to the 5-year overhead costs of some overcomplicated k8s system, it's quite reasonable to overprovision the bejesus at the colo bare metal>hypervisor layer as cheap insurance.

Every time I read something like this I think that there has to be a tipping point were a well-written (i.e. compiled, not interpreted) solution running on a beefy server has to more cost efficient than running the same thing spread over several containers.

Definitely not an expert, but I get the impression that this point is a lot higher that most people assume it is.

Spoiler alert: a well written application on a beefy server almost always beat the k8s rube Goldberg machines on cost. I still don't get why people refuse to think for themselves and just jump on the latest hype train.

K8s makes little sense unless you run on bare-metal. Once you jump to vms you are injecting another abstraction layer and take on a herculean level of ops without understanding what you're getting into.

VMs are nice when you can't fill a machine with a single task (plus whatever redundancy). Once you get to a single machine, you want to scale up that one machine; you can go a long way where scaling up is cheaper than scaling out. But at some point, scaling out gets cheaper.

I'm not sure where the check points are now, but typical points where cost jumps are desktop -> server socket, single socket -> two sockets, two sockets -> four sockets, four -> eight sockets. AFAIK, AMD EPYC isn't offered at more than two sockets, and going to four sockets used to be possible off the shelf but very expensive, and eight sockets was very expensive if off the shelf or very expensive because custom engineering. Sometimes ram costs go way up for the highest density too.