1. 24
  1. 11

    Like ‘hacker’, the original meaning of ‘devops’ has been taken over by a cult. Limit the meaning to “solving operations problems with modern software development tools” and you can get back to devops being expert sysadmins and toolsmiths working at large scale.

    The modern meaning, which Cadey describes, is exactly like a giant internal software project where the first step was to fire all the subject matter experts. When you take the ops out of devops, you get the obvious result.

    1. 9

      On the road to SRE, there are two social concepts which work in tandem:

      1. Maintenance work is higher-priority than feature work.
      2. Every service is owned and operated by its development team.

      Even if there is no andon cord, reliability issues should be prioritized over feature requests, because a plain service which is up has higher availability than a featureful service which is crash-looping.

      1. 2

        Yes, this is so nice to read. Thank you. :)

      2. 4

        I think “solving social problems with technical solutions” is also a common reason that new microservices get introduced into systems where, from a purely technical point of view, a monolith or a smaller set of services would be superior. Conway’s Law is a real thing.

        Team X owns the release schedule for a part of the system. My team needs to ship new functionality on a different schedule. We could change the ownership structure of the release schedule, but that’s a hard organizational problem, so let’s just make a new microservice and release it ourselves. Never mind that (as the blog post discusses) our team has no operations experience.

        Sometimes that’s the best answer but I think sometimes it’s just people wanting to avoid office politics even in cases where working out the people problem would lead to a better end result.

        1. 2

          Sometimes that’s the best answer but I think sometimes it’s just people wanting to avoid office politics even in cases where working out the people problem would lead to a better end result.

          So true! I had a conversation with a coworker a long time ago in which he realized, after years of working with me, that I actually cared about “people stuff” and he was shocked. Apparently it had never crossed his mind that I actually cared about the stuff I talked about constantly, because devs aren’t “supposed” to care about that stuff.

          1. 1

            Sometimes it’s also the cheapest way of doing things, and that’s why people go for it. The move fast and break things philosophy is an excuse for tech debt, and low quality solutions.

          2. 1

            If a bad devops team is working on something no other teams rely on, then the worst that can happen is at least contained to that system. If a bad devops team is working on something others rely on regularly they can probably be circumvented or reshuffled to get back to functional. But a bad sysadmin team can bring a business to a standstill basically indefinitely, since they control all the gates and can’t just be reshuffled. So devops is a necessary evil, distributing the risk to a bunch of smaller teams. And as the article states, the cost is that teams without ops expertise end up doing ops oopses all the time.

            Devops has had some really good side effects, though, like popularising isolation and immutability.