This read as "old man yells at cloud" to me.

I've managed a few thousand VMs in the past, and I'm extremely grateful for it. An image is built in CI, service declares what it needs, the scheduler just handles shit. I'm paged significantly less and things are predictable and consistent unlike the world of VMs where even your best attempt at configuration management would result in drift, because the CM system is only enforcing a subset of everything that could go wrong.

But yes, Kubernetes is configured in YAML, and YAML kind of sucks, but you rarely do that. The thing that changes is your code, and once you've got the boilerplate down CI does the rest.

> But yes, Kubernetes is configured in YAML, and YAML kind of sucks, but you rarely do that.

I'm sorry, citation needed on that. I spend a lot of time working with the damn YAML files. It's not a one-off thing for me.

You're not the first person to say this to me, they say "you rarely touch the YAML!!!", but then I look at their last six PRs, and each one had at least a small change to the YAML setup. I don't think you or they are lying, I think people forget how often you actually have to futz with it.

I think it is also a difference between developer and IT. Usually the requirements don't ask for thousands of VMs if you don't run some kind of data center or a company that specializes on software services.

YAML is fine, esp. compared to the huge collection of often 10x worse config formats you have to deal with in the VM world.

I'd prefer Ansible if I was running VM:s. Did that at a gig, controlled a vCenter cluster and hundreds of machines in it, much nicer experience than Kubernetes style ops. Easier to do ad hoc troubleshooting and logging for one.

> "old man yells at cloud"

Literally.