[HN Gopher] In retrospect, DevOps was a bad idea
___________________________________________________________________
In retrospect, DevOps was a bad idea
Author : aard
Score : 17 points
Date : 2025-07-21 20:22 UTC (2 hours ago)
(HTM) web link (rethinkingsoftware.substack.com)
(TXT) w3m dump (rethinkingsoftware.substack.com)
| jbverschoor wrote:
| DevOps is a good idea. But most have no clue about the Ops part
| rednafi wrote:
| All the devops I have encountered so far have been "sysadmin in
| a trench coat." Most couldn't write anything beyond basic
| Python and Shell scripts. It was mostly ops folks jumping into
| a fancy new title. So every time something would go poof, they
| had to pull in devs to debug the most basic stuff.
| JohnMakin wrote:
| This article is really light on concrete examples and any kind of
| point outside of the title, which is a shame, because I think
| this is an extremely relevant discussion to most tech-y people's
| work and day-to-day, so I'll try to elaborate on why I agree and
| disagree with some of these points that have been repeated 50,000
| times over the last ~10-15 years. disclaimer: spent most of my
| career in what probably would be described as "DevOps" at most
| places, and have led multiple devops teams.
|
| For my tone, I apologize, but there is just so much _wrong_ in
| this post that I don 't want to go through it all, but here's one
| example of why I think this person, with all due respect, has
| very little idea of what they are talking about. It's irritating
| because it seems to devolve into some weird rant about "locked
| doors" which are 100% and absolutely necessary in any operation
| of size and scale:
|
| > Originally, DevOps was about trusting developers with
| production. But modern DevOps teams operate on the belief that
| developers can't be trusted with production.
|
| I don't even know where to begin with this one. Who hurt this
| guy?
|
| > And because DevOps owns the compliance checklists, they bake
| that mistrust into the rules.
|
| That isn't _remotely_ how compliance works and suggests a child-
| like understanding about any of this. At most they are
| responsible for implementing the checklists, which comes from a
| security team, compliance team, or some external entity, and even
| _those_ checklists are not really generated or controlled by
| these entities, they are following established guidelines already
| in place that most people need to adhere to. So, red flag number
| one this person doesn 't know what they're really talking about,
| but I'll digress to my main point because I think the spirit of
| the post is correct even though most everything in it is silly.
|
| I have the opinion that the industry fundamentally misunderstood
| what DevOps was supposed to be and do. Of course this is rarely
| challenged, but where these arguments fall short are what are we
| supposed to do instead? The author comes close to recommending a
| solution - have them work closer to the devs and thus the product
| teams. Boom. Simple. That's it, and in fact, tons of places not
| stuck in the practices of 20 years ago have done this, and
| successfully! They're just not typically called "devops." Like,
| at meta for instance, the closest thing to that (and forgive me
| if I'm misremembering or this has changed, this is from a round
| of interviews some years ag) is a role called "systems engineer"
| and they work on and with the dev teams.
|
| The existence of a team called "DevOps" to me is a massive red
| flag anymore that a company isn't getting it, but I have still
| seen this "chuck it over the wall at each other and pray"
| approach work fine enough. It's also created a job title that can
| mean practically anything and predicts very little about a
| person's skill set - you have "senior" devops guys and leads that
| basically got promoted from a Sys admin or IT support role, which
| for some reason companies thought was a perfectly natural
| progression, and then devs who did actual development for a while
| and now write fully functional platforms and automation for the
| dev teams they support. These people are _not_ the same, which
| makes the hiring /interviewing process a nightmare. To make it
| worse, even tech people can barely understand the difference
| sometimes. So you'll run the gamut of having teams full of
| "devops" guys that can barely string together 6 functional lines
| of code, to full stack guys that could probably work with any of
| the dev teams they support as a dev.
|
| I don't pretend to know the fix but I've increasingly gone out of
| my way over the last several years to avoid "devops" titles
| because it just seems to be a dead giveaway that the team is
| clueless or at best apathetic about how to do this.
| hadlock wrote:
| > Originally, DevOps was about trusting developers with
| production. But modern DevOps teams operate on the belief that
| developers can't be trusted with production.
|
| This right here pretty much discredits him (or her) completely;
| there's no way you would survive five minutes of an audit where
| developers have direct access to Prod in any kind of regulated
| business (finance, medical, banking, nuclear, military etc).
| This might be acceptable for an owner operated website that
| sells trading cards but absolutely not for any company > 500
| employees.
| smackeyacky wrote:
| I'll give you a concrete example of how it goes so very wrong.
|
| I worked for a bank for a short period of time, where the
| development team had gone a bit far with a shotgun approach to
| moving their systems to Azure. It was pretty hard to find
| things and as their approach evolved, the older conversions
| weren't revisited. Most of that team quit. New team is brought
| in (including me) which had some excellent engineers with years
| of experience in system architecture, how to make Azure work
| better. So we tried to homogenise things around a more
| reasonable approach.
|
| This caused operational problems to worsen (understandably) but
| it was a short term pain, long term gain thing we couldn't be
| allowed time to do. So the CIO decided to take all the
| sysadmin/devops type work and give it exclusively to the system
| administrators. Who weren't developers. They fixated on one
| particularly narrow solution for deployment. To make it easier
| for themselves, but one that didn't really address the bigger
| picture of how to make it easy to monitor and deploy etc.
|
| Anyway it ended up a disaster. The development team in their
| newly narrowed roles struggled to make their systems fit in the
| rigidly defined holes. Operationally it was no better and
| sometimes worse, but there was absolutely no compromise on how
| things should work or any consultation with the devs at all,
| ever.
|
| I no longer work there. If you're going to do devops you have
| to listen to your experienced engineers, not the snotty kids
| who think clickops is engineering.
| digi59404 wrote:
| This is a valid story, and I have no doubt it's real. I've
| heard and seen many stories like this that have happened.
|
| But... I'm going to say the dirty, quiet, and unlikable thing
| out loud.
|
| That had nothing to do with DevOps or its philosophies,
| processes, or patterns. That was bad leadership from the top
| down plain and simple. It's likely not even the individual
| engineers faults. It's leaderships fault for not setting
| clear objectives, implementing them, ensuring that the
| engineers had a real plan before beginning, and making sure
| no individual was too in charge of things.
|
| Leadership in your case was likely career management who knew
| very little about technical items. Managers who were
| technical were probably shot down for not playing politics
| properly, not producing the correct "metrics" and "kpis". So
| they moved on.
|
| That's a company culture issue that has little to do with
| tech.
| fduran wrote:
| Good food for thought but the article assumes how currently
| DevOps and Dev teams (and there's also an Ops team?) operate and
| there's a lot of different ways in how "DevOps" is done at
| different organizations.
|
| Take any combination of dev, platform engineering, devops, SRE,
| ops teams (existing or not) and combine with different
| responsibilities and how they work together and there's a company
| out there using that model.
|
| Heck, we don't even have a common understanding of what a
| "DevOps" team does https://docs.sadservers.com/blog/what-the-f-
| is-devops/
| rednafi wrote:
| Most of the DevOps folks I've encountered, unfortunately,
| couldn't code much. So it was mostly ops work with a fancy new
| title.
|
| The idea of a single entity being responsible for development,
| operations, observability, and support is flawed from the start.
| That's not a one-person job, and the expectation simply doesn't
| scale. So DevOps often ends up being either ops folks or dev
| folks, and rarely a true blend of the two.
|
| What we need are feature-focused developers, ops-savvy devs who
| can deploy their own work, and a strong team dedicated to
| observability and applying modern SRE practices.
|
| So I think curious developers who aren't afraid of infra, along
| with a solid platform engineering team, are a real improvement
| over the status quo.
| RecycledEle wrote:
| For years idiots pushed DevOps and I told them it was a terrible
| idea, so they did not hire me. I wish I could get back pay
___________________________________________________________________
(page generated 2025-07-21 23:01 UTC)