What is so horrible about it? Our devs are happy they can focus on fixing unit tests in pycharm, while others care about where the code is going.
It's unfortunately inherent that some people want predictable, scalable, observable, stable- and at the same time they want fast moving and many new features.
I think it's not so much that dev and admin work is terribly difficult, it's more that "a man cannot serve two masters" and someone will be focusing on stability and someone else will be focusing on quickly deploying.
Trying to do both yourself I think leads to burnout.
What’s worse is they can be condescending while shoveling out absolute garbage. If I’m honest that’s the part that bugs me the most.
I still see this, developers use archaic or absurd incantations in their build-scripts because they kludge something that works in bash on their machine then push it into yaml and move on, forgetting to comment, document or try to simplify the line so that it's easy to break apart later when it has to be debugged.
Some of the best interpreted code I have ever seen came from a former sysadmin (it was powershell though, that comes with it's own warts of course).
The issue is that we collectively decided that sysadmins should just stop existing instead of allowing it to grow properly. We forget how bad things were for developers back when we decided we didn't like sysadmins. There were companies still passing around code on a USB stick because developers didn't want to depend on SVN being down. (I am not kidding).
Git was introduced 2005 and wasn't really everywhere until 2012, but 2014 sysadmins had all but been retired. This is the timeframe we talk about.
Developers of that time were as bad as the sysadmins were, the problem was that the developers had time and space to grow and we judge the developers of 2012 as if they had all the tools, knowledge and incremental improvements in workflow that they have today.
The sysadmins who were already automating large amounts of tasks for n Unix servers and k switches with p services, had a vastly different skill set and migrated to the more modern software defined devops SRe world no problem. But plenty of sysadmins basically could (and some still) only use a gui, and do things from trial and error. Those people might have retired or become managers, but they had a lot more issues with the transition. Which to be fair the transition happened fast and hard in some companies.
Anyway this is just one tiny example but the same underlying thing starts happening in all parts of the development cycle. “My deploy doesn’t work” … well your program has an error and crashes on startup but looking at the logs would be too much work. Let’s just say we are blocked and log off.
As you can see this is a culture issue but it seems to be common when you have a devops team. And even more common when management (read senior management and up) think that developers “should just be developing”.
Anyway thats my rant.
The only solution I see is to enforce commit checks before hitting shared environments, but that comes with its own set of complaints.
If they had no DevOps team to raise a ticket with, and it had to get done they would find some way to figure it out if they had the ability to modify and initiate their own pipelines. The reason I like "you build it you run it" is I feel like I have far more control over my own destiny. You're not having to negotiate and coordinate with a separate team through some ticketing system. Far less wasted back and forth and miscommunication. If that means you have to expand one of your teams with an additional DevOps person to foster understanding of the tooling on a team who hasn't done it before that's fine. But don't make them the DevOps person. Their goal is to enable the rest of the team to pick up these skills. Their goal should be to transition into a normal contributing member of the team working on product development because the team no longer has a need for a DevOps person.
The idea behind devops was to be a single team.
I assume you are pointing out that split-teams is the insane part, in which case I agree. The philosophy was supposed to define the blurred line between developers and operations, using tooling to help facilitate the shared responsibilities where sensible and make hand-off a breeze.
As you pointed out, the division existed 20 years ago, and it still exists now at many places. That lack of integration doesn't offer much improvement in relation to the past.
People do not fix the pain they don't see, and managers doubly so. By shifting operations off to a "devops" team, you just end up with developer teams that don't know about, and don't care to fix, the things that make it painful to deploy or run their code in production. Those that have to deal with the pain rarely have any political leverage they need to even enact change. There's zero motivation for either the developers writing the software _or their management_ to fix it. Dev manager incentives are purely aligned with getting code and features built.
To give a nice real world example, building out new regions for AWS services used to be a pain in the arse (since I left I hear some major top down initiatives have fixed that). The service team I worked for, almost doubly so painful for region build. Standing up an entire region was something like ~50 days of engineering time. Not because it was especially hard, per se, but because the ops team always had to wade through piles of refactored shit that introduced new circular dependencies, or wasn't documented, or broke other aspects of any automation we could produce. (I remember one DynamoDB schema overhaul, where we did a complicated migration. Next region build, service components wouldn't stand up because we'd used the automation to create the new table schemas that had replaced the old table schema entries, but the service code still expected to see the old schemas in the right format. It took several months to get the dev manager to agree to engineers spending time cleaning up old schema references from their code base.)
The dev manager incentives were not aligned with making it easy. It wasn't their engineering resources being consumed, and they had features they needed to ship. The developers never changed the way they worked because even though they were told the issues (and even though they were, virtually to a person, great people to work with, considerate etc.), they never experienced the pain so they never thought about those consequences of what they were doing when they were doing it.
Ops manager never had any leverage, because every single time we managed to get a region launched in time as to not be an issue, and every time things were down to the wire it was clearly as a result of the ops team not building the right automation :eyeroll:, rather than that the dev teams were making some kind of brand new nightmare each time.
It wasn't until the ops team had lost enough members of staff to that BS, and region build shifted on to the developers themselves, that suddenly most of the problems went away, never to appear again. They were aware and conscious of the pain certain decisions would cause because they had felt it themselves, and they made sure not to introduce more pain.
DevOps is about making sure incentives and politics align to make things overall better. Shoving it in to a silo is literally the complete opposite.