Slashdot Mirror


Most Organizations Are Not Fully Embracing DevOps (betanews.com)

An anonymous reader shares a report: Although many businesses have begun moving to DevOps-style processes, eight out of 10 respondents to a new survey say they still have separate teams for managing infrastructure/operations and development. The study by managed cloud specialist 2nd Watch of more than 1,000 IT professionals indicates that a majority of companies have yet to fully commit to the DevOps process. 78 percent of respondents say that separate teams are still managing infrastructure/operations and application development. Some organizations surveyed are using infrastructure-as-code tools, automation or even CI/CD pipelines, but those techniques alone do not define DevOps.

6 of 301 comments (clear)

  1. Marketing and operations not embracing MarkOps by Anonymous Coward · · Score: 5, Insightful

    Equivalent of saying marketing and business operations need to embrace each other as one. Yes there should be synergy and commonality, however they are different fundamental areas of expertise. Dev Ops should favor cooperation and collaboration not one person to do it all.

  2. And this is a "problem" because ... by xmas2003 · · Score: 5, Insightful

    ... a developer should be modifying production code?

    --
    Hulk SMASH Celiac Disease
    1. Re:And this is a "problem" because ... by Xest · · Score: 5, Insightful

      I'm not really sure what the summary/article is on about. It says:

      "Although many businesses have begun moving to DevOps-style processes, eight out of 10 respondents to a new survey say they still have separate teams for managing infrastructure/operations and development."

      But DevOps processes doesn't preclude dev and ops being separate teams, it just means that they should work together and use the countless bits of DevOps tooling out there to help support things like CI. It just about smoothing the path from dev to ops and automating it as much as possible.

      If the suggestion is that to to DevOps "properly" which seems to be the implication of the summary then it does indeed suggest that what they're saying is that there should be crossover between developers and ops.

      I work for a well regulated financial services organisation and that frankly just wouldn't fly. It's all fun and games if you're running shit that doesn't matter but for us, good luck explaining to the FCA that the reason you leaked a whole bunch of sensitive personal financial data was because Bob the dev configured the hardware firewall himself via Octopus incorrectly, or Jim the ops guy just did a small update that involved temporarily storing an admin password in a plaintext string internally in some application which got subsequently output in a memory dump on error on the public internet.

      There are ample good reasons why DevOps does not and should not inherently mean merging the two departments, and frankly those suggesting otherwise should get the fuck out the industry in case someone accidentally employs them to work on something that matter and we end up with yet another complete fuckup of a software project.

      It's sufficient to simply build bridges between and increase efficiency of the work dev and ops do together. Anything more than that is frankly nothing more than utter retardation. Let professionals do what they're professionals at - you wouldn't get the fucking cleaner to do their own payroll, so why the fuck would you get ops to do their own dev or vice versa?

    2. Re:And this is a "problem" because ... by jrumney · · Score: 5, Insightful

      For many companies it needs to be harder, not easier to push into production. The emphasis should not be on the "one button" to promote from development to production, it should be on the well defined process that leads to that button.

  3. Good. by Anonymous Coward · · Score: 5, Informative

    I've literally never seen DevOps implemented in a way that's actually beneficial.

    It's consistently just a way for bad management to cut budgets by getting devs to do ops work badly, or ops to do dev work badly.

    Even where that's not the case, it usually just ends up being a way for ops to fob their work off onto dev whilst not giving them the tools to actually do it like giving them the admin access they need to install/configure something wasting everyone's time.

    I've even seen agile work and be beneficial more times than I've ever seen devops to be a beneficial thing. Like agile, it's just another fucking cult of nonsense most of the time.

    Devs and Ops already have way too much to learn, that's why they're specialists in their fields. If you get devs having to learn how to manage networks and servers it just means that's a whole bunch less framework they're able to learn away from being able to do full stack. Similarly ops have way too much to learn in terms of software and hardware configuration to be able to learn to program properly. If both fields were simple jobs with fuck all to learn then maybe there'd be benefit to it, but forcing each other to learn more than they already have to in their respective fields is a guaranteed path to failure.

  4. I'm the architect on our DevOps team... by greenwow · · Score: 5, Interesting

    and this story is correct in that we haven't completely embraced DevOps. Our dev and DevOps teams use Agile so there's a ridiculous two week minimum delay for any fix since you have to add the JIRA issue to a new sprint before you can fix it. Agile doesn't work well with things that must be fixed for customers. Even worse is since most of our developers are on four scrum teams, they have four stand-ups per day where they need to talk about what they've accomplished and what they commit to doing before the next stand-up. Actually getting work done has suffered since you need to do something superficial each day for four times each day.