I've done all of this and then some. I used to deploy websites by FTPing into the server and copying files. Then it was bash scripts, then Ansible. IMO Kubernetes hits a very good level of abstraction. You can totally deploy 30 lines of bash to every server, you just have to wrap it in a docker container. That's all k8s asks for for a workload. You don't have to use operators. That would be something to explore much later. Honestly I just think you should be more generous and not assume people have created this stuff just for fun. K8s really does address real problems around deployment and it's very well thought out.

To be fair in other comments OP made an effort not to get involved into those endless Kubernetes vs VM discussions. However either side eventually posts a snarky comment and there goes.

I think everyone just has to acknowledge that there are use cases for both. Also Kubernetes and "classic" configuration management via Ansible (or others) are orthogonal to each other. So these discussions are somewhat misguided in the first place.

For example: you might want to deploy a VM or auto-install and configure a physical machine with custom tooling and something like Ansible or Puppet and _then_ configure said machine as a Kubernetes node that handles the actual workloads. In other cases some Dev might want to install and run an application without the k8s layer using Nginx as a webserver. In this case, too, Puppet/Ansible might or might not be involved in configure the application but only handle the "OS layer" if there is such a thing. And in yet other cases you get away with a simple cloud-init script that makes your machine a k8s node and leave out other configuration management tools altogether.

Guess what: All of this is fine. Evaluate solutions based on what you need, not what other people working in giant corporations urge you to use. And then go and build it, ideally having fun doing it.

Representing either tool as a one-size-fits-all is misguiding at best and seems to be overly simplistic to the complex problem of deploying your applications.

> Honestly I just think you should be more generous

I am generous in the context for generosity. Turns out that engineering is not about being generous but rather about choosing the most efficient solution for problems that in the end need to be business driven. This requires evaluating requirements, context and tradeoffs. That takes a cold, rational mind more than generosity.

> K8s really does address real problems around deployment and it's very well thought out

It's great where it makes sense. It's less than great elsewhere.

Not everything is SaaS, not everything needs scaling, not everything needs 99.99% of uptime, not everything needs a CDN, not every company is VC backed operating at high risk / high reward, etc, etc. Context is better than ideology. If you read the article I posted you will see that stated clearly.

I completely agree that most people don't need that. This is always what people say when k8s comes up. This is also what people said about git 15 years ago (you're not the kernel etc). But the thing is you don't have to use any of the bits you don't need. At first I listened to the naysayers and was wary of k8s thinking it would create more problems than it solves. That simply hasn't been the case. It's not a no-brainer, there are tradeoffs, but I really think it makes sense especially if you're doing docker anyway. Like I said in another comment, people tend to talk about two different things. There's k8s which can be as little as just a single node k3s server which is basically docker compose with a few extras like automatic rollout etc. Then there's the over the top "cloud native" stuff. One does not imply the other.