The goal of dev is to be able to change everything whenever they want.
The goal of ops is to have a strong infra that has the fewest changes possible.
They are opposite and usually there are more devs than ops but the first respondent to an issue are ops.
You can only have devops if both roles are intertwined in the same team AND, the organization understands the implications.
Everywhere I've been, devops was just an excuse to transfer ops responsibilities to dev because dev where cheaper. Dev became first respondents without having the knowledge of the infrastructure.
So dev insisted to have docker so that they would be the one managing the infra.
But everyone failed to see that whichever expensive tools you buy, the biggest issue was the lack of personal investment to solve a problem.
If you are a 1.5x dev in a 0.9x team, you get all the incidents, and are still expected to build new stuff.
And building new stuff is fun.
Spending 2 days to analyze a performance issue because a 0.3x dev found it easier to do a .sort() in Linq instead of Sql is fun only once.
People can’t care about stuff they don’t know about. Split the roles and you split responsibility. It’s the same with dev and QA. Suddenly, the person paid to care about quality or stability realizes that the person who’s paid for something else doesn’t care like their job depends on it. Because it doesn’t. So OP above is right, splitting things and specializing horizontally is most times a bad and, if you think about it, not very smart move.