[HN Gopher] Why Twenty Years of DevOps Has Failed to Do It
       ___________________________________________________________________
        
       Why Twenty Years of DevOps Has Failed to Do It
        
       Author : mooreds
       Score  : 31 points
       Date   : 2026-01-17 19:21 UTC (3 hours ago)
        
 (HTM) web link (www.honeycomb.io)
 (TXT) w3m dump (www.honeycomb.io)
        
       | blutoot wrote:
       | I can't wait for indie developers to build super-agents that
       | commoditize providers like Honeycomb.io and more importantly
       | clone all their features and offer them up for free as OSS.
        
       | mjr00 wrote:
       | > most orgs are used to responding to a daytime alert by calling
       | out, "Who just shipped that change?" assuming that whoever merged
       | the diff surely understands how it works and can fix it post-
       | haste. What happens when nobody wrote the code you just deployed,
       | and nobody really understands it?
       | 
       | I assume the first time this happens at any given company will be
       | the moment they realize fully autonomous code changes made on
       | production systems by agents is a terrible idea and every change
       | needs a human to take responsibility for and ownership of it,
       | even if the changes were written by an LLM.
        
         | hippo22 wrote:
         | What happens if the person who wrote the code went on vacation?
         | What happens if the code is many years old and no current team
         | member has touched the code?
         | 
         | Understanding code you didn't personally write is part of the
         | job.
        
         | blutoot wrote:
         | I think the opposite will happen - leadership will forego this
         | attitude of "reverse course on the first outage".
         | 
         | Teams will figure out how to mitigate such situations in future
         | without sacrificing the potential upside of "fully autonomous
         | code changes made on production systems" (e.g invest more in a
         | production-like env for test coverage).
         | 
         | Software engineering purists have to get out of some of these
         | religious beliefs
        
         | tarxvf wrote:
         | If companies were generally capable of that level of awareness
         | they would not operate the way that they do.
        
       | politelemon wrote:
       | If your developers weren't looking at dashboards before, they
       | won't use a chat interface to interrogate it either. That doesn't
       | really bring it to them any more than their existing
       | capabilities. There's also a worrying underlying assumption being
       | made here that the answers your LLM will give you are accurate
       | and trustworthy.
        
         | amtamt wrote:
         | > There's also a worrying underlying assumption being made here
         | that the answers your LLM will give you are accurate and
         | trustworthy.
         | 
         | I first hand saw in, AWS devDays, an AI giving SIWINCH as
         | "root-cause" of Apache error in a containerized process is in
         | EKS for a backend FCGI process connection error. It has been
         | extremely hard since that demo to trust any AI for system level
         | debugging.
        
           | temp0826 wrote:
           | If we were smart we'd use AI to grok a system in order to
           | help us reduce its complexity. I don't think we're anywhere
           | close to even being able to provide all the necessary context
           | to solve problems like this.
        
       | jhawk28 wrote:
       | DevOps is dead because it's run by a bunch of ops people who
       | don't know how to do dev and a bunch of dev people who don't know
       | how to do ops. The only tooling problem is that a bunch of
       | companies created "DevOps tools" that then get dictated to use:
       | K8s, terraform, etc. The only way this works is if you build the
       | application to fit within those frameworks. Writing an indexer
       | that is massively parallel and is mainly constrained by
       | CPU/Memory. Instead, you have devs building something that gets
       | thrown over the fence to a devops team that then containerizes it
       | and throw it on K8s. What happens if the application requires
       | lots of IOPS or network bandwidth? K8s doesn't schedule
       | applications that way. "Oh you can customize the scheduler to
       | take that into account". 2 years later, it's still not
       | "customized" because they are ops people who don't know how to
       | code. If you do customize it, the API is going to change in a few
       | months which will break when you upgrade.
        
         | blutoot wrote:
         | I would say, in pre-CC (pre-claude-code), this might seem like
         | a daunting task for average DevOps engineers. But in post-CC,
         | there is just no excuse to fret from such challenges.
        
           | gmane wrote:
           | Spoken like someone who has never had to deal with business
           | critical production environments.
        
           | pryelluw wrote:
           | It's like saying that in a post-Viagra world there shouldn't
           | be men who have trouble getting laid.
        
             | blutoot wrote:
             | Don't want to get too deep into your analogy. I was
             | addressing the "DevOps cannot code" part. To me it is a
             | leadership failure if a DevOps team is still afraid of
             | tackling bigger challenges (like the example given by the
             | OP). That, of course, depends on whether DevOps teams will
             | exist in the long run.
        
         | orsorna wrote:
         | Would you say it's truly dead or that it fails to meet the
         | performance bar you've described?
         | 
         | The reality is that most devs do not consider a holistic
         | picture that includes the infrastructure they will be deploying
         | to. In many cases, it's certainly a skill issue; good devs are
         | hard to find. And to flip the coin, it's hard to find good ops
         | people too.
         | 
         | The reason DevOps continues to linger, however vague a
         | discipline it is, is because it allows the business to
         | differentiate between revenue generating roles and cost center
         | roles. You want your dev resources to prioritize feature work,
         | at the beckon of PMs or upper management, and let your "DevOps"
         | resources to be responsible for actually getting the product
         | deployed.
         | 
         | In essence, it's a ploy to further commoditize engineering
         | roles, because finding unicorns that understand the picture
         | top-to-bottom is difficult (finding /top/ talent is
         | difficult!). In this way, DevOps is well and alive, as a Romero
         | zombie.
        
       | mosura wrote:
       | It failed because there is an ongoing denial that development and
       | operations are two distinct skillsets.
       | 
       | If you think 10x devs are unicorns consider how much harder it is
       | to get someone 10x at the intersection of both domains.
       | (Personally I have never met one). You are far better off with
       | people that can work together across the bridge, but that
       | requires actual mutual trust and respect, and we're not able to
       | do that.
        
         | tsss wrote:
         | You don't need 10x developers. You just need to avoid the 1/10
         | multiplier of pitting separate development and operations teams
         | against each other.
        
       | gardenhedge wrote:
       | In my company, instead of relying on an ops team.. we rely on a
       | devops team.
        
       | zug_zug wrote:
       | "I think the entire DevOps movement was a mighty, ... it failed."
       | 
       | I'm so sick of this nonsense. "Devops" isn't failing, isn't an
       | issue, you can rename it whatever you want, but throughout my
       | career the devops engineers (the ones you don't skimp on) are the
       | best, highest paid professionals at the company.
       | 
       | I don't know why I keep reading these completely crazy think-
       | pieces hemming and hawing about a system (having a few engineers
       | who master performance/backups/deployments/oncall/retros) that
       | seems to be wildly successful. It would be nice if more engineers
       | understood under-the-hood, but most companies choose not to
       | exclusively hire at that caliber.
        
       | jbreckmckye wrote:
       | Because the idea you can have all aspects of maintaining a
       | complex piece of technology, maintained by a single cross-skilled
       | team of interchangeable cogs, is utopian and unworkable past any
       | reasonable level of scale
       | 
       | DevOps, shift left, full stack dev, all reminds me of the
       | Futurama episode where Hermes Conrad successfully reorgs the
       | slave camp he's sent to, so that all physical labour is done by a
       | single Australian man
       | 
       | Speaking darker, there is a kind of - well, perhaps not
       | _misanthropy_ , but certainly a not-so-well-meaning
       | dismissiveness, to the "silo breaking" philosophy that looks at
       | complex fields and says "well these should all just be lumped
       | together as one thing, the _important stuff_ is simple, I don 't
       | know why you're making all these siloes, _man_ " - assuming that
       | ops specialists, sysadmins, programmers, DBAs, frontend devs,
       | mobile devs, data engineers and testers have just invented the
       | breadth and depth and subtleties of their entire fields, only as
       | a way of keeping everybody else out
       | 
       | But modern systems are complex, they are only getting more so,
       | and the further you buy into the shift-left everyone-is-
       | everything computer-jobs-are-all-the-same philosophy the harder
       | and harder it will get to find employees who can straddle the
       | exhausting range of knowledge to master
        
       | alphazard wrote:
       | DevOps only works when the developers are always right. What
       | usually happens is the DevOps team thinks they know best (they
       | are developers too, just not the ones using the tools), and they
       | build a lot of garbage that no one wants to use, often making
       | things more complicated than they were before.
       | 
       | Eventually a bureaucrat becomes the manager of the team, and
       | seeks to expand the set of things under DevOps' control. This
       | makes the team a single point of failure for more and more
       | things, while driving more and more developer processes towards
       | mediocrity. Velocity slows, while the DevOps bottlenecks are used
       | as a reason to hire.
       | 
       | It's an organizational problem, not a talent or knowledge
       | problem. Allowing a group to hire and grow within an
       | organization, which is not directly accountable for the success
       | of the other parts of the organization that it was intended to
       | support, is creating a cancer, definitionally.
        
       | blutoot wrote:
       | My message to the CTO of Honeycomb.io (who apparently wrote this
       | post): please avoid getting philosophical and controversial to
       | gin up curiosity about your AI platform. If you want to highlight
       | the benefits of your platform then do so earnestly and
       | objectively. Please don't mask marketing with an excoriation of a
       | profession that has never been well-defined (or has always been
       | defined to fit into an organization's political landscape for the
       | most part). And you guys (like every other SRE/Ops platform)
       | capitalized on that structural divide and deservedly got rich by
       | selling licenses to these teams. I don't think you can come in
       | now with this holier-than-thou best practice messaging just
       | because platforms like yours have zero moat in this post-CC/Codex
       | world.
       | 
       | Hence my vitriol: https://news.ycombinator.com/item?id=46662287.
        
         | TacticalCoder wrote:
         | > id getting philosophical and controversial to gin up
         | curiosity about your AI platform
         | 
         | Also: please could he please avoid doing it by illustrating his
         | non-sense with graphs that are _both_ childish and non-
         | sensical?
        
       | anonymars wrote:
       | Am I the only one who remembers when DevOps meant "developers are
       | responsible for dealing with the operational part of their
       | software too, so that they don't just throw stuff over the wall
       | for another team to deal with the 3AM pages"?
       | 
       | It seems to have become: "we turned ops into coding too, so now
       | the ops team needs to be good at software engineering"
        
       ___________________________________________________________________
       (page generated 2026-01-17 23:00 UTC)