back to article IT's Holy Grail, but is DevOps a Poisoned Chalice for sysadmins?

DevOps is 2016’s tech holy grail – unified development and operations, both working to deliver what the business needs, quickly, reliably, and adaptably. Done well, DevOps transforms the way organisations work; it helps break down barriers between tech teams, and between technology and the rest of the business. Good DevOps is …

  1. tiggity Silver badge

    Dabbling

    After just reading the latest excellent Dabbs standup article, with it's humorous potted bio, it took me a few seconds to realise that this potted bio with its holistically transformative buzzwordiness was actually meant to be taken seriously

    1. Anonymous Coward
      Anonymous Coward

      Re: Dabbling

      I've worked in a lot of places where the development areas were involved in the "sysadmin" process. All of them, without exception, were a disaster area. All of them were costly to run and made delivery of a usable service very difficult. All of them moved away from that model, saved money and improved the service.

    2. Dan 55 Silver badge
      Happy

      Re: Dabbling

      Including the last paragraph?

      Be water^WDevOps my friend.

    3. PleebSmasher
      Dead Vulture

      Dabbling in The Force

      "Done well, DevOps transforms the way organisations work; it helps break down barriers between tech teams, and between technology and the rest of the business."

      Dang, yo. DevOps is like, The Force. Wicked.

  2. WraithCadmus
    Happy

    Bring on the Future

    I'm a sysadmin, I like the DevOps idea, I just want there to be a path for people like me into it, all the stuff I see at the moment is aimed at devs.

    "Yeah so deploying a server now is just like with your Mongoloid artefacts with you pull them from ToastMushroom into your Bangarang build"

    *blinks* "Mate, I just want to make sure I've got vim and dig on all my machines"

    I've got a very basic puppet setup running oneoffs and templating stuff like Apache proxies, but I realise I'm only using about 6% of what this stuff can do for me. Doesn't help that the top dog in this area is changing hourly. I'm wondering whether to jump to Ansible or Salt or just give it all up and go live on the Moors hunting sheep with my bare hands.

    1. SolidSquid

      Re: Bring on the Future

      I've been messing about with Ansible and it's been pretty nice so far, although largely I've been using it to build a local development environment. Documentation seems pretty good now too, which I understand was an issue it had previously

    2. Doctor_Wibble
      Thumb Up

      Re: Bring on the Future

      I was thinking something similar, and to extend on that a little this does look rather like the job description for 'the IT guy' (gender!) if we go back to before the turn of the century in any of a thousand small companies where you were expected to do near-enough everything and there were few enough people that everyone knew what everyone else was doing and provided decreasingly-useful input at the pub afterwards.

      This doesn't invalidate this new name 'DevOps' by any means but it's important not to forget that some of us did this already, under various different titles. And before anyone starts, none of them were 'neckbeards' and I'm not sure I ever even saw one in real life, I think they only exist in movies and academia (a kind of nut I understand).

      1. Chika
        Unhappy

        Re: Bring on the Future

        This doesn't invalidate this new name 'DevOps' by any means but it's important not to forget that some of us did this already, under various different titles.

        For many years, yes.

        To be honest, this seems to have been seen by my managers at the time as a way of cutting me out of the operational scene then, having done that, making me redundant. It just seems to be yet another way of cutting jobs by stealth. They aren't really re-thinking anything.

        Believe me, marketing and executive buzz words will eventually kill this industry.

        1. Steve Davies 3 Silver badge

          Re: Bring on the Future

          You are forgetting the PHB's with their shiny new MBA's and Management Speak consisting almost entirely of TLA's, FLA's and adjectives worthy of the man who used to compere 'The Good Old Days' on TV.

          1. Anonymous Coward
            Anonymous Coward

            Re: Bring on the Future

            I'm in a similar camp I believe. Automating APIs and Chef where possible normally for new non production environments. Of course long before all that scripts of all sorts and a standard sysadmin tool kit to provide the standard required gum and sticky tape were the norm, if you need to do it more than once - automate it.

            I prefer the notion of Test Driven Infrastructure or Agile Infrastructure... or err "automation"

            As I've said before on similar articles, devops may work in a company where all your applications are built by an internal (or very closely integrated third party) development team and everything else is SAAS.

            But I suspect most of us work in a world of disjointed infastructure built over two decades, with an array of bespoke internal apps, bespoke 3rd party apps, off the shelf enterprise and consumer apps, SAAS, IAAS, hypervisors and operating systems. With a layer of weird switches, funny firewalls, bizarre VPNs, legacy SANs, new SANs, managed services, internal kit, colo kit, something that guy in Germany a few years built, another thingy that does something that you tried to figure out once, some sticky tape and, monitoring applications. Oh and all with less money than last year and demotivated teams.

            While "Devops" may work for the internal apps made by an actual dev team internally that have all their ducks in a row I find the rest is left to the Infrastructure type people to figure out. Whilst being called obsolete because Digital is where it is now.

            Though I'm pretty sure I've not seen an analogue server in the building.

            Oh well!

      2. Novex

        Re: Bring on the Future

        I too was doing a DevOps style of work back in 2005-2007. I lost that work then due to the 'outsourcing' mania of the noughties, and couldn't adapt to something else before the Crash set in. So fads come and go, and I reckon DevOps will come in and out of fashion as time goes by.

      3. Anonymous Coward
        Anonymous Coward

        Re: Bring on the Future

        Me too. We've seen some low-level adoption of devops internally, and I do quite admire it, even with 15yrs of well established cynicism of technology and it's buzzwords. But, like you note, I'm feeling somewhat sidelined by it. It does seem to be focussed on code and not the infrastructure - at least, I'm always pulled in at the last minute to 'optimise' something rather than being part of a team.

      4. John 104

        Re: Bring on the Future

        Sadly, neckbeards do exist. Most of them work at Adobe, though.

  3. Anonymous Coward
    Anonymous Coward

    Frankly, I still see this a "niche" market - albeiit a large one

    1) DevOps, like is explained here, looks to work only for in-house developed applications. If you're an ISV, it will inevitably end at the test stages, because you won't like to be responsible for roll-outs on sytems you have no control over.

    2) There's always the costs/benefits ratio to take into account. This model requires a lot of resources (and/or a level of expertise), which may be not available in many SMBs situations. Not everybody is Google or Amazon.

    3) In my experience, it's a long time developers need to do on-call and firefighting. Many sysadmins can't see the time they can say "it's an application problem" and pass the hot potato to developers (which often find that it was a deployment/configuration issue... <G>)

    That said, developer can build-in realiability, scalability and security up to a point. Even if infrastructure can be coded, it doesn't mean it will be a developer to do it. Real syadmin has been coding infrastructure for years. Youn don't need fancy new buzzwords and standards to do that, most devices and software have been automatable for years, and skilled people did it.

    Sure, new tools make this even more powerful, but you still need someone who knows the nuisances of orchestrating a datacenter to perform it, only a few developers may have that knowledge. And good sysadmins always worked with other tech roles to understand what is the best way to integrate everything into a smooth, optimized running system.

    It looks we are talikng about bad sysadmins here. Those who don't give a damn about what runs on their systems, as long as it doesn't troubles them, and they don't care if they didn't spend half an hour to optimize it to run faster and better. The ones who prefer to spend their time on simple repetitive tasks, so they don't have to learn anything new, take any "risk" automating something, and maybe be asked to do something more in the time they then have. The ones if there are performance issues, just buy more and/or expensive hardware to solve them. Those who setup their systems as it was still NT4 or Unix SRV4 era, because they never kept their skills up to date - and never update a configuration since the device has been installed. Those who will never allow any change to their preciousssss datacenter for that very reason.

    Do we need those? No, if they become extincted like dinosaurs life will be better.

    Good ones will be finally able to spend more time on the real valuable (and enjoyable) parts of their job, instead of having to put again an ISO into a server and apply all the patches.

    But are operations going away? Of course no. Systems will still need to be monitored. Hardware will still die and need replacements. User needs will evolve, and there will be still configuration changes to review, approve, implement. And user will make mistakes, while security incidents will happen.

    The landscape evolves, and someone needs to keep updated knowledge about what is going on, and future needs. GitHub learned the hard way hardware firmwares may need to be updated as well.

    DevOps sounds like a new buzzword for practices good teams always implemeted, maybe with less standardization and less automation - a buzzword to sell new tools, training and outsourcing to the very people who will never understand how to master it properly, and risk just to spend a lot of money for nothing. The others. are already doing - within the available resources.

  4. Kleykenb

    No doubt

    Not a shred. DevOps is the death of the BOFH. All Hail the new BSYSOFH

  5. John 104

    Is it May 6th yet?

    1. Dan 55 Silver badge
      Trollface

      I wonder when they'll be announcing Continuous Lifecycle 2017.

  6. Anonymous Coward
    Trollface

    Devops is filling a capability vacuum

    Devops wouldn't be needed if ops staff weren't almost all 'tards. Just saying.

    Luckily my company is at most 2 years away from 100% SaaS, so it's fuckity-bye to the DBAs, tape-jockeys, SAN-man, Sharepoint BOFH, SCCM greybeard etc.

    1. Trevor_Pott Gold badge

      Re: Devops is filling a capability vacuum

      Ops wouldn't be needed if devs knew how to write proper code.

      1. Anonymous Coward
        Anonymous Coward

        Re: Devops is filling a capability vacuum

        It was the obligatory reply to an obvious idiot troll dev, of course.

        But in all seriousness, even if devs could write proper code there would *still* be a need for ops, because Murphy rules and sh*t happens and somebody needs to pick up the pieces.

  7. Erik4872

    It cuts at both ends of the spectrum

    As has been mentioned, bad sysadmins don't do anything differently from the way they did 20 years ago, and don't automate things as a general rule. That's the low end of the spectrum. At the other end are the wizards and greybeards of systems -- the "specialists." Both are being squeezed in this brave new world. Specialists have extreme domain-specific knowledge on a narrow range of products -- SANs, Cisco network gear, VMWare, management tools -- and contribute to the silos in enterprise IT. Vendors don't help either, making their products specifically hard to work with unless you invest time to gain that extreme level of knowledge.

    I still think there's room for qualified generalists in the middle who would more easily be able to make the leap. I know a few bad sysadmins who are very worried. I also know a few wizards. For example, the Citrix wizard is getting a little worried now that Terminal Services is getting better and more client apps are HTML5 based. The Cisco savant is starting to see SDN encroaching on his world. I've always been kind of an end-to-end guy when it comes to sysadmin work, so hopefully I'll be able to make the move when and if it does come around. Who knows, it could all be a fad, but in this world of cost cutting and offshoring, I'm assuming it isn't.

  8. From the States

    “If you aren’t making mistakes, you aren’t taking enough risks.”

    I get that, but in a financial services environment, mistakes don't go over well, or at least repeated mistakes don't, especially if gain/loss is involved.

  9. Captain DaFt

    Hey Ballmer!

    One last dance?

    Dev-ops dev-ops, dev-ops, dev-ops!

    Dev-ops dev-ops, dev-ops, dev-ops!

    Dev-ops dev-ops, dev-ops, dev-ops!

    Dev-ops dev-ops, dev-ops, dev-ops!

    Dev-ops dev-ops, dev-ops, dev-ops!

    Dev-ops dev-ops, dev-ops, dev-ops!

    Dev-ops dev-ops, dev-ops, dev-ops!

    Dev-ops dev-ops, dev-ops, dev-ops!

    Or... how about enough already!?

  10. Trevor_Pott Gold badge

    Dear Mr. cantor

    "Operations staff, who have spent their careers learning how IT systems work...can shorten the length of time it takes for developers to understand the infrastructure by orders of magnitude."

    "Operations staff have a lot to contribute to DevOps, in the short- and long-term. They just need to see it."

    You have done an excellent job in this piece of explaining why operations teams are required in the short term for DevOps. Specifically: knowledge transfer. You have also discussed at great legnth how it benefits the business to convince the operations teams to participate in this knowledge transfer willingly.

    You did not even remotely touch on the role of operations in the long term. What sort of positions they might fill once the knowledge transfer is completed nor what value the business will see in continuing their employment past that point.

    This entire article has been about the importance of convincing ops not to fear for their jobs when DevOps begins implementation, but I must say that I finished it feeling only more convinced that once the knowledge trasnfer is complete, operations will be kicked to the curb.

    Can you please help me understand how DevOps is anything other than a protracted method for handing everything over to developers?

    Furthermore, given that developers are functionally allergic to testing, QA, UAT or any form of resiliancy, redundancy or stability, why should I, as a business owner, want to undertake a DevOps transition that seems to be aimed at eliminating the positions of the people who actually keep things running?

    Bonus question: how many DevOps transitions are actually "successful"? How many are just some manager throwing a copy of The Pheonix Project into the dev pen and then waiting until they can start firing ops teams?

    What is the benefit to me, as an operations guy for taking the risk of working to make DevOps succeed?

    What is the benefit to me, as a business owner for taking the risk of trying DevOps at all?

    1. Doctor_Wibble

      Re: Dear Mr. cantor

      > Can you please help me understand how DevOps is anything other than a protracted method for handing everything over to developers?

      Surely not, the Ops staff will be able to re-train as Devs, so hurrah nobody is out of a job, right...? I'd definitely prefer the intent to be clear so I at least know where I stand.

      Anyway, if there's no actual Ops people, who is going to be the one to be repeatedly ignored when having to repeatedly tell the Devs that something is not going to work or will have strange consequences or has dependencies that you already told them about, listed, documented, and yes they are a bit odd but that's the legacy system they failed to comprehend? It also means when they break something by being careless or stupid they don't get to blame it on anyone else. Been there, been the scapegoat, and it doesn't matter if the truth emerges later, your standing with the management will never fully escape the toilet.

      </bitofawhingesorry>

    2. Down not across

      Re: Dear Mr. cantor

      Furthermore, given that developers are functionally allergic to testing, QA, UAT or any form of resiliancy, redundancy or stability, why should I, as a business owner, want to undertake a DevOps transition that seems to be aimed at eliminating the positions of the people who actually keep things running?

      Apart from few exceptions, that is unfortunately all too true. I've lost count how many times I've had to perform small miracles to make things work (especially if old legacy systems are involved) when outsourced developers are just too clueless. And no, of course they did no testing. You'll be lucky if they even bother to implement any error handlers (beyond one that just ignores any errors).

      Reminds me of the old motto "With willing hearts and skillful hands, the difficult we do at once; the impossible takes a bit longer."

    3. Anonymous Coward
      Anonymous Coward

      Re: Dear Mr. cantor

      If you think of yourself as someone who doesn't change - who does Operations, and never anything but operations, then you're probably right that your time is limited in a company moving to DevOps. The isolated Operations career is coming to an end (though it might not be during your career), unless your goal is to administer local networks, Windows PCs, and login servers. The interesting work around production environments is going.

      What DevOps provides is a means of taking your Operations knowledge, and making it accessible to everybody else. And if you think the knowledge transfer only goes one way, then you've got a lot to learn about what the rest of the IT team does. And if you think roles in Operations are limited to break-fix, enforcing standards, or ordering new hardware, there's a set of surprises coming your way which you'll either love or hate.

      Some of the things that Operations staff end up doing, once they start moving to DevOps (personal experience only, as I used to work in operations): building tools for deployment; automating pipelines; configuring self-healing systems; working on constantly improving systems; designing experiments to see which new practices are effective; bringing new technologies into the team; software development; designing new systems to be redundant, scalable, and resilient, in collaboration with development, QA, etc; figuring out how client needs and business needs map to the reality of today's technology; collaborating with other teams to ensure stability, security, and minimal bugs.

      There's a huge amount of stuff in Operations areas that most people in Operations don't have time to focus on, at the moment. The move to DevOps, rather than pushing those people out, allows them to focus on those things they've wanted to, but which they haven't had time for. Such has been my experience, in any case. There have never been any layoffs of Operations staff when I've been through DevOps migrations with companies.

  11. allthecoolshortnamesweretaken

    "Noah [Cantor] is Head of Transformation at OpenCredo, ..."

    Anyone else reminded of Colonel Sebastian Doyle, Section chief of CGI, Head of the Ministry of Alteration? He changes people...

  12. FluffyERug
    Devil

    DevOps is bollox!

  13. allthecoolshortnamesweretaken

    Holy Grail

    Grail Knight: But choose wisely, for while the true Grail will bring you life, the false Grail will take it from you.

  14. Steve Medway

    DevOps = Fire lots of needed people....

    DevOps is corporate bullsh*t for layoffs.

    It's main use is to lower staff headcount and err reduce the headcount some more.

    A developer will never see things the way operations do. Good Op's are the customers voice (Oy! Dev's sort ya crap out, this issue will piss off my customer, and hence me cos' I'll get it in the neck).

    Put a dev in front of a customer and they'll more than likely tell them to f*ck off 'My codes great, you're the one doing it wrong'. It may well be true but that's not the point, 'the customer is always right' sigh.

    What Op's do is throw away the crap customer 'issues' and forward on the real issues. Op's staff are basically the bs filter, without them most Dev's I've worked with would no doubt turn into gun toting mass customer murderers.

    As for the uptime bit of this article, I call BS. One big downtime per year is much preferred to many small outages. Just look at SLA's, most companies are hit with punitive damages based on the total number of outages not their length.

    1. Down not across

      Re: DevOps = Fire lots of needed people....

      As for the uptime bit of this article, I call BS. One big downtime per year is much preferred to many small outages. Just look at SLA's, most companies are hit with punitive damages based on the total number of outages not their length.

      I'd have to call [citation needed] here. I believe it tends to be outage minutes rather than number of outages. Having said that, that doesn't really matter.

      Even assuming the SLA is just case of percentage yielding acceptable downtime in minutes for a year, the problem is perception.

      I would hazard a guess that most people will perceive 3 10-minute outages as more unreliable than one 30-minute outage even if technically they're the same with regards to uptime.

      1. Steve Medway

        Re: DevOps = Fire lots of needed people....

        Totally agree that its the perception of availability (or lack of) that really cheeses off clients.

        A one off indicates a problem where things are not standard, where as frequent downtime indicates stability issues, that is what annoys clients far more than big one-off's.

        Constant small amounts of downtime usually result in a different supplier being found at the end of the contract, one (or ever a few over a long period) generally have much less impact when it comes to contract renewals.

        That's just from my experience in Telecoms, but YMMV dependant upon your field of work.

  15. Rooster

    Devs don't know Ops

    If left to their own, Devs will produce a system that works for now. But they may well not think to add any of the things that the Ops half of the equation are there for:

    * Backups that are reliable and tested and will work when they are needed. (321 rule)

    * Monitoring that will warn you _before_ things fail (Out of disk space? Again?)

    * Alerting for when things do fail.

    * System updates and patching - 'cause new vulnerabilities come along all the time (e.g. heartbleed, etc.)

    * Security: no, you can't just use one log-in for everything.

    * Capacity planning

    * High availability

    * Scaling

    etc

    The main benefit of DevOps is to get the Devs thinking about how their code will run in production _before_ the final deployment.

  16. Someone_Somewhere

    Architecting user-centric initiatives

    used to be the purvue of programmers/developers, but, now that Marketing bods with MBAs have long since overused TLAs they've had to get a new Hungarian vocabulary with which to bullshit impress everyone and have gone all HR on our asses to boot.

    DevOps is simply a buzzword for deploying mission-critical eyeballs to evolve interactive mindshare in ubiquitous relationships, thus disintermediating ubiquitous technologies that facilitate global deliverables, empowering rich technologies and productising bleeding-edge infrastructures.

    It's no more than the maximisation of synergistic communities to syndicate best-of-breed partnerships that envisioneer innovative networks enabling the harnesssing of global partnerships to facilitate strategic initiatives.

    Redefining strategic models and matrixing robust deliverables should have gone hand-in-hand with development all along but very few developers I have met have the least idea of how computers work, let alone understand the needs of real enterprises in the real world, so it's not /that/ surprising that this should have happened - the only surprise is how long it took HR to realise that automation was going to make them redundant and they'd better finds a new role quickly.

    This comment was facilitated by Linus Torvalds, Richard Stallman, Google and the Dack Web Economy Bullshit Generator.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like