> if they're using Kubernetes at all then presumably they've got at least a few hundred machines being managed by a couple different product teams.
I think this, unfortunately, does not hold up in practice. I am seeing way too many small orgs/teams use Kubernetes to orchestrate dozens and even sub-dozens of machines. From the perspective of solving for sub-dozens to thousands, I think there is some merit to TFA's perspective, even if it doesn't match the Kubernetes use-case you describe.
I honestly think the solution is to encourage smaller shops to stop using Kubernetes. You can get pretty far with VMs running systemd/init.d services and a mechanical way to apply filesystem changes. This is how "typical" services were operated for decades, and it has distinct advantages at small scales.
If I were advising a startup on technical architecture, I would recommend they write their software as if it runs in Kubernetes (avoid hardcoded configuration, bundle dependencies into the build artifact, use mTLS instead of firewalls) but otherwise behave like someone running a LAMP stack in 2003.
Sound advice. Sadly, the industry is by and large ignoring it, and the median k8s cluster size is single digits. There are a few elephants who run thousands of nodes, and at that scale the benefits outweigh the complexity tax. But a huge chunk of the industry is tiny and has been convinced they need to k8s, while another chunk of the industry is trying to figure out how to scale k8s down, on the faulty hypothesis that you can then grow effortlessly.
On one hand ... yeah, just get a VM, use config management (Chef, Ansible), maybe try terraform to manage "your cloud" (so the state is managed), get docker on it, and run the app from the image you built on your CI.
... but, using k3s is a lot simpler than fighting Ansible, it gives a standard. Yes, it takes a week to get used to it, but then it works, and it gives a lot of benefits.
I think this, unfortunately, does not hold up in practice. I am seeing way too many small orgs/teams use Kubernetes to orchestrate dozens and even sub-dozens of machines. From the perspective of solving for sub-dozens to thousands, I think there is some merit to TFA's perspective, even if it doesn't match the Kubernetes use-case you describe.