The underlying problem is that ops doesn't scale well unless they can use generic abstractions over things like reliability, scalability, security, etc. Those

The underlying problem is that ops doesn't scale well unless they can use generic abstractions over things like reliability, scalability, security, etc. Those generic abstractions require applications to adhere to ops best practices, or they don't work (e.g. Kubernetes can't scale a stateful app). Without those generic abstractions, you need a ton of ops people. Enough that there are at least a couple members of ops with in-depth knowledge about each app, and each ops member can only realistically know <5 apps that well. Really, you need several ops members to know each app that well, because that style of ops tends to burn people out rather quickly and they quit. Ops also has to be intimately involved in the design process, and have some kind of veto power to say "you can't build a stateful app, then throw it over the fence and demand we somehow make it scalable". With the generic abstractions, you need fewer ops people, but they really only know the generic abstractions and can't help diagnose errors via log messages. A lot of (bad) devs want a world where ops is just held captive by dev. Ops has no authority to say no to the design process, and no ability to say that some things aren't possible with the application architecture. It just doesn't work. Even if ops can somehow do things like remove state from stateful applications, everyone capable of doing that work is going to quit. It's not fun or interesting work to do, it's exhausting and frustrating to expend man-months of effort on a problem that could have been solved with man-hours or weeks of development effort.