1. 38
  1.  

  2. 11

    This matches up pretty well with my experiences of what people call “DevOps”, having worked in various operations-focused jobs. Roles that actually involve mixing development and operations work seem to be much rarer than I expected. My current and past roles have explicitly been both, but I’m usually the only person in the company doing that.

    A lot of companies aiming to follow DevOps principles seem to end up having separate development and operations roles - they just call them something else. I’ve seen both “DevOps Engineer” and “Site Reliability Engineer” jobs end up being similar to a more traditional operations job, and not involve development at all. They do usually come with a focus on configuration management, infrastructure-as-code and other delivery tools - all good ideas, but they seem separate from the original principles of an engineering culture that brings together development and operations.

    1. 2

      Certainly when the concept first started making a buzz it was the idea that there was a pipeline from requirement to production, with dev, test and deploy merely being steps along the way…

      We learnt ages back that if you make the devs get involve in test…. suddenly, magically, they start to design for test…

      A classic story that happened in my team was we added a feature in 2 hours flat and threw it over the wall to test…. and they said they would take several testers 2 weeks to test it. WHAT!?

      Turns out the feature only effected a very rare occurrence and triggering wasn’t possibly and actually knowing what happened was hard since it was a component in a large system and….

      3 hours dev later and they had a hook to trigger the event on demand and logging to see the result and testing was over and done in less than a day.

      But it seems culture and political empires are harder than coding and sysadmin…. and the grand scheme of making those most capable of easing (and most responsible for creating) the pain of test, deployment and administration wear some of that pain…. has failed.

    2. 3

      Some might say that veteran admins say “AWS is the king”.

      Others say that veteran admins say “AWK is the king”.

      1. 1

        I went a little o_O when I read this.

        My experience comes from a smaller scale of companies though, I’ve never worked in “SRE” in the Google sense.

        But still, I think “just admins checking in their scripts” is a bit off. It surely is more ops than dev, but (at least what we did) is write a lot more stuff like normal programmers than scripts like ops are said to do. Also, in 9 out of 10 times it’s reading a lot of source code in the stuff you’re using. Maybe I was doing the sysadmin thing wrong, but I don’t remember reading a lot of source code of my daemons and file system drivers…

        Sure, depends on what you do and it also doesn’t help if it’s a small team in a small company that’s doing software development and run the whole infrastructure, but still - I see it more as “developing tools for internal use, mostly monitoring and reliability” and not just using them. And mostly not just automating everything.

        But 100% spot on about the YAML :P