Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Businesses Programming IT Technology

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

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.

Most Organizations Are Not Fully Embracing DevOps

Comments Filter:
  • by Anonymous Coward on Thursday June 14, 2018 @05:33PM (#56786362)

    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.

    • In the old days devops was one person because they were simply a sort of translator between the development team and the BOFH, an almost-developer who understands system administration well enough to figure out what technologies are allowed that will meet the needs of the team, and what configuration changes can<->should be made.

  • by xmas2003 ( 739875 ) * on Thursday June 14, 2018 @05:35PM (#56786374) Homepage
    ... a developer should be modifying production code?
    • Well, not the developer per se, but the DevOps guy should have a process to promote it automagically from development to qa to production.

      If they do their job right, it shouldn't take more effort than pressing the "promote" button in their build and deploy tool of choice. For course, it never actually WORKS that way, but that's how the vendors tell me it should work.

      • For many companies it does just work that way. The problem is many companies don't realize (or don't care) you need to commit an entire team or teams to building and maintaining your deployment utilities alone.
        • by jrumney ( 197329 ) on Friday June 15, 2018 @12:22AM (#56788060)
          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.
          • by Lennie ( 16154 )

            The process and having multiple environments is much more important than everything else. Making it easier to do so should just be a time saver after that.

          • If you don't have a one-button promote, then you probably don't have a one-button rollback either.

            The one-button promote isn't the goal in itself, it's a side-effect of having a tightly managed configuration. You want a well defined process? When you find yourself capable of automating it, then you have it.

      • Not even that. In DevOps it’s not even necessary to have a DevOps “guy”, that term smells a lot like the other drivel HR people tend to stick in job requirements. Originally at least, DevOps was more about process: a way for changes to flow smoothly, quickly and safely through development, QA, and deployment, with automation being a big part of that. But those 3 tasks can still be handled by separate teams like in more traditionally organised shops (ITIL).
      • For course, it never actually WORKS that way
        Of course it works that way.

        but that's how the vendors tell me it should work
        Which vendor? Since when do you need a vendor? Typical deploy chains are all open source.

        • I guess that you don't have "That guy" working in your organization ,who makes a poorly documented code or script change that breaks the build or deploy process the day before he goes on vacation.

          I thought that every organization had one of those people working for them. I think that our "guy" is named Bill. Fuck you, Bill!

          • You can not make undocumented code changes.
            First of all: to put a code change "life" (regardless if for developers only, or for 'prelife' machines or 'test' machines or the 'production' machines) you have to commit it to a source code control system. And that is only possible if you give the ticket number from the issue tracker in the commit comment (of course you usually could give a fake one in so far that it only needs to refer to an existing ticket, or open ticket or ticket in state 'progress').
            Then dep

    • by Xest ( 935314 ) on Thursday June 14, 2018 @05:59PM (#56786510)

      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?

      • Would you agree that the Ops guys will do a better job if they better understood what Developers were delivering? Would you agree that the Developers would write better code if they had the input and advice from experienced Ops engineers?

        • by Wolfier ( 94144 )

          Even if both the answers are yes, it still does not mean individuals should be both developing applications and managing the infrastructure. Even in separate teams Ops and Dev can (and do in many organisations) communicate very well.

        • by Xest ( 935314 )

          Yes I would.

          But I'd also agree that dev and ops guys will do a better job if they understand any budget restrictions finance are under, if they understand any efforts HR are making to improve self development and staff happiness, the strategic direction the CEO wants to take the company in, the legal requirements enforced upon the company that legal regulate, and issues sales people are facing in the field, and the challenges the corporate security team face with people doing things that unwittingly cause a

      • The article is from a consulting company that sells devops solutions. Some marketing people got together and said, "What kind of article can we write to make people want to buy our product?" Then they wrote an article filled with phrases designed to make CxO types pay attention. The marketing people thought it would be worth the expense of doing a survey to get broader circulation. The point is, don't expect it to make sense, that's not it's purpose. It was written to attract attention, like a butterfly.
    • by davecb ( 6526 ) <davec-b@rogers.com> on Thursday June 14, 2018 @08:24PM (#56787274) Homepage Journal

      ... a developer should be modifying production code?

      Sarbanes-Oxley says you need two people to do a production push. One is dev, one is ops. The cooperation is called dev/ops. Whooda thunkit?

      • God SOX is PITA, understandably so, but still a PITA.

        My old job conformed to SOX, because they had to. publicly traded yada yada.

        everything was about controllership. to promote something to Prod it took a weekly group meeting, and when I left they did monthly moves, weekly and emergencies. It was becoming bogged down by meetings and schedules. Still didn't stop them from having critical systems issues, or stop me from getting daily calls at 4am.. It really affects productivity. Users ask for prod ch

        • by davecb ( 6526 )
          I was actually commenting that even something clunky like sarbanes-oxley proposed something sane like dev/ops (:-)) Mostly because they are both based on some underlying good ideas like a two-person rule.
  • by war4peace ( 1628283 ) on Thursday June 14, 2018 @05:35PM (#56786378)

    Why do they HAVE to commit to DevOps methodology?

    • Agreed. Some parts of DevOps work well for many companies, not every line-item is a sure-fit everywhere.

      • DevOps - essentially the practice of forcing your coders to also be sysadmins - works well for a situation where you have a staff of people where everyone can do a little of both but nobody can do either job completely competently.

        • by hjf ( 703092 )

          In the company I work for, we devs are very capable, but ops are extremely CYA (Cover Your Ass). They don't want to touch ANYTHING. And that means running servers from 2009 in production.

          Oh and they lost the complete SVN server one day. No RAID, and no backups.

          But somehow, if prod breaks, it's the dev's fault for "not writing good code".

    • by gweihir ( 88907 )

      Because it is the stupid "hype de jour". DevOps does not work and cannot work, except when you have the rare situation where you actually have people that are good at both aspects and you manage to prevent them from being terminally boring by it, i.e. basically never.

      • I worked often together with DevOps and also worked as DevOp myself.
        If competent people work, it works.

        Incompetent people can cause havoc in any situation.

        (And yes, it is superbly boring if you need another CI server and the "server guys" can not provide one ... hence, you set up your won, and suddenly you are a DevOp, oops. It is so easy. Where the hate for new adequate approaches come from is beyond me. Perhaps you don't like the term ... then coin your own one)

        • by hjf ( 703092 )

          This is what usually happens at our site. Ops doesn't provide us with test VMs as required ("just use the dev VM", which is already down to its knees), but they want full docs on how software should be installed.
          Gee. I have no idea what you're using to spawn services, dear ops. You haven't event told me what Windows version you're going to use. Because yeah, ops. You pull out a dirty old Win2008 VM because "licenses take time to get".

      • It seems painfully obvious to me; if you're suffering under a BOFH already, asking them to increase cooperation is not going to be productive from the development perspective, because the developers see themselves as the purpose of the whole shebang. Of course they're not going to adopt methodologies that require specific software support, that software will never make the list.

        That's what real devops is all about though; translating that divide to language acceptable on both sides, and maybe telling the de

    • by jythie ( 914043 )
      Because there is always one best way to do things, regardless of scale or domain! Everyone who is not using the blogger's specific preferred process is simply denying the inevitable. We have consulting services to sell damn it!
  • Good. (Score:5, Informative)

    by Anonymous Coward on Thursday June 14, 2018 @05:38PM (#56786394)

    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.

    • by alw53 ( 702722 )
      Why would I embrace getting paged at 2 in the morning? What an idiotic idea.
    • by dentin ( 2175 )

      I've seen it work at large scale in exactly one place.

      In order for dev/ops to work well, a lot of things have to be done correctly. Most of it is culture and design of the organizations and communications channels; social engineering in terms of how the groups are set up and their incentives. Failure to do this is generally why dev/ops fails or doesn't perform.

    • 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.
      DevOps is not Ops, it is administration and configuration.

      A guy who i snot able to administer a linux box, set up a CI system on it AND can not develop, I never would hire.

      Of course you have to know both (and many other things) to be a competent "software engineer". The question is, what will be your main work, but if you call to "support" because you have a problem with swap spac

    • Re:Good. (Score:4, Interesting)

      by sodul ( 833177 ) on Thursday June 14, 2018 @10:56PM (#56787800) Homepage

      One of the problems with DevOps is that the term has completely become an overloaded marketing Buzzword that has little to do with the original intent. I wrote a long article about DevOps [linkedin.com] last year explaining that it does not mean a new team or role, but rather a culture between the Dev and Ops groups to work more closely together. The 'toss over the fence' model that is traditional with Waterfall is not working well when doing 'Agile'. Agile itself is often a pure excuse to justify 'anything goes without planning'.

    • As someone who very very foolishly sat on his laurels and let my mediocre knowledge wane even more over the past 5 years, I appreciate your reply.

      The apparent expectations of system administrators, general support people appears to be going along the path of "if you don't know some kind of scripting, you're worthless". I continue to see things which seem to imply I need to be a goddamn programmer in order to get a job.

      I envy programmers, they're clever people, it takes a hell of a lot of work. I've been

  • by greenwow ( 3635575 ) on Thursday June 14, 2018 @05:42PM (#56786412)

    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.

    • DevOps are not on a scrum team and are not bound to sprints.
      They handle tickets as they come.

      You probably do Scrum wrong, Agile wrong, and have no clue what a DevOps does.

      Not 'You' but your organization.

    • You shouldn't need more than 1 standup a day.

      And if there's extremely high priority work that can't wait for the normal cadence, then it should be a simple matter of the Product Owner deciding an equivalent amount of unstarted work to push out of the sprint to replace it. The point is to make the person responsible for the decision holds the responsibility for that decision.

      Otherwise you end up in the classic model of "we asked for a million things at once and it's the developers' fault for not delivering"

    • 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.

      Wow, Agile is making you not agile. Good thing you are following the agile manifesto by putting people before processes [agilemanifesto.org].

    • by rossz ( 67331 )

      There have been occasions where I spent more time creating the ticket with it's description, acceptance criteria, and detailed steps than actually doing the work.

      • And that's a surprise, why? Figuring out exactly what to do should take longer than doing it. Spending lots of time doing the wrong thing because you didn't put in the time making sure that you have a complete and accurate description of what to do and how to verify that you really have done the correct thing is a dumb waste of time.

    • by Afty0r ( 263037 )

      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.

      That's not "Agile", that's Scrum - also within Scrum there are ways of providing hotfixes without terminating the sprint, and without waiting 2 weeks. Sounds like your Scrum Master needs some education. The Agile Manifesto literally contains "Responding to change over following a plan."

      Furthermore if you have lots of issues, you may wan

    • Your story highlights the problem with 'devops' and 'agile' and countless other buzzwordy programmes companies implement. Even looking down the comments here, half of slashdot doesn't understand and doesn't agree on what 'devops' actually is. We've all worked somewhere that said "oh yeah, we do agile, we do devops" and that's the example most people seem to accept as being "the correct one". Yours looks like a horrible misintepretation of what 'agile' tries to accomplish.

      For me, I'd say 'devops' is more abo

  • by mschaffer ( 97223 ) on Thursday June 14, 2018 @05:58PM (#56786506)

    The OP and article imply that this IS a problem.
    It's not.

  • by sandbagger ( 654585 ) on Thursday June 14, 2018 @06:04PM (#56786550)

    The only reason why it's not working is because you. It's your fault.
    Fortunately, we can hire consultants to help you.

  • Right. (Score:5, Informative)

    by nightfire-unique ( 253895 ) on Thursday June 14, 2018 @06:06PM (#56786560)

    Ok - so here's the thing. Developers should have a firm understanding of OS maintenance, firewalls, networking, security, and all that good stuff. Operators should know how to code. I wouldn't personally hire a developer whose workstation was a disaster area, and I wouldn't hire an prod-level operator who didn't know, at least in passing, a few languages.

    But this whole "devops" thing is kind of a joke when you get to the enterprise level. The goals of developers and operators are simply different, and the stakes are way too high to encourage those who write the code to also run the code.

    On the other hand, if you're a small team / company slapping together a simple web site, multitasking may simply be a necessity.

    • by vux984 ( 928602 )

      "Ok - so here's the thing. Developers should have a firm understanding of OS maintenance, firewalls, networking, security, and all that good stuff. Operators should know how to code. I wouldn't personally hire a developer whose workstation was a disaster area, and I wouldn't hire an prod-level operator who didn't know, at least in passing, a few languages."

      Well said.

      "But this whole "devops" thing is kind of a joke when you get to the enterprise level. The goals of developers and operators are simply differe

    • Ok - so here's the thing. Developers should have a firm understanding of OS maintenance, firewalls, networking, security, and all that good stuff.

      What is this 2003? Devops is usually used in web services/microservices/cloud type environments where you don't care about that stuff. Infra is so last decade, have you heard of AWS or Azure?

  • Is the ones who decree a switch to an agile development process, but still want waterfall style year+ schedules.

    • by hjf ( 703092 )

      Ah yes, waterfall. The rosy world of product managers where everything goes within their schedules. Where the dev is dumb, and needs a step by step use case made by the queens of the office, the analysts (all women at my company. VERY bright girls i have to admit).

      But an external consultant suggested we switch to agile. So now we devs just get told over an email what to do. Because that's how agile works right?

      Do i have to say this only lasted for a couple of months?

  • by vtcodger ( 957785 ) on Thursday June 14, 2018 @06:12PM (#56786596)

    Am I the only one to whom This whole thread seems somewhat like reading a transcript of the Mad Hatter's Tea Party?

  • Given how eager corporations are to hire the least expensive people, it would be surprising if they embraced paying for people with both developer and operator skills.

    And "buy one, get one free" just doesn't work here.
  • Devops has it's place for in house development where produciton and infrastructure are linked. There it is an effective and efficient way to go from Dev to test and into production.

    What does my head in is the number of vendors that we see that try to bring their devops mentaility in house for the applications that they provide. They expect that we have to mirror their development environment which is often an untested disaster over and over again.

  • I build the train, I drive the train. Occasionally it breaks and I fix the train.
  • I know plenty of developers, and even more operations / administration people.
    The skillset for one is not necessarily applicable to the other.

    Some of the best developers I know, I wouldn't trust them to set up a basic PC for me, I've seen the mess they made of theirs. Some of the best operations people I know can't write code that's anywhere near the quality of a full time developer, but they can definitely set up a secure firewall, or configure a bunch of servers to work reliably.

    • by rossz ( 67331 )

      That's me on the ops side. I suck at php. I know this. You do not want me working on the application. I'll fuck it up.

      On the other hand, I excel at scripting automation for servers. I live in bash and will almost always code a better automation script than the developers. I'll worry about getting the web server optimized, keeping it backed up, and simplifying the release process. Let the developers worry about optimizing their code. On occasion, we'll work together when the situation requires a look

    • Some of the best developers I know, I wouldn't trust them to set up a basic PC for me.

      In Web services land you don't need to know how to setup a PC. IaaS and Paas has eliminated the needs for these skills (unless you work at an IaaS or PaaS provider.

  • As a developer, I "get it" that writing code to roll up VMs, firewalls, and so on results in repeatable software. But honestly, it's boring. I hate writing code to create Amazon EC2 instances on the fly, etc. I wish I had an Ops staff to handle these tasks.

  • When the only tool you have is a hammer, everything looks like a nail.

    If you're a programmer, you naturally want to use programming to configure systems. But that's not always the best way to do it. There are other, better tools for general-purpose system setup.

    If you have to configure lots of systems in exactly the same, or similar ways, DevOps might be good. But for systems that are one-offs (and there are a lot of them), not so much. The benefits of automation isn't worth the cost in these cases.

    • It does seem like a pain in the butt to automate provisioning and deployment of a one-off system. Until something bad happens, and you need to rebuild that system in 5 minutes. Then you're really glad you did it.

  • I see so many people complaining about devops and I don't understand why? "Herp Derp developers writing code in production" - no dumbass, that has nothing to do with devops. Devops is just your ops guys using developer tools to streamline testing and deployment.

    Tools like Docker, where your entire platform is defined and described in a configuration file. All the required firewall ports are clearly stated, the number of replicas of each deployed service is clearly stated, the build process is clearly stated

  • DevOps is not about devs doing ops work, it's not about a dev installing a server, setting up firewall rules by hand with iptables and managing the disks on the server. It's about enabling devs to do their work without depending on ops, among other things. The whole devops movement is based on the CLAMS model, where the 'C' stands for Culture, and it is an important part, because without a change in mindset, you will mostly never succeed on implementing devops. It's also the most difficult thing to do, chan

  • Oh noes! Whatever shall we do?!

    Sounds like the marketing ramp up to a lucrative round of “DevOps and Why You Can’t Live Without It” consulting gigs.

  • Most don't need to. DevOps is this newfangled thing that happens when you've got your pipeline optimized so far that a handful of experts can code, deploy, upgrade and maintain your appstack all at the same time, while sipping lattes and playing a round of foosball inbetween. When orgs have gone "all cloud", then DevOps is a thing that basically happens automatically. But don't expect a regular old-school company going there. It's avantgarde startups doing this, and they, in the end, might end up replacing

  • Anybody who has worked in any real software company with real projects and real life infrastructure knows that you have to keep the live environment and the test environment totally separate and the development team can't have any influence on the live environment in any way. Faster and more deployments on live systems only means more chances for failures and bugs. If you need rapid changes to the live system then obviously you haven't designed and planned the project before hand. Any automatic deployment t

Research is what I'm doing when I don't know what I'm doing. -- Wernher von Braun

Working...