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.
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.
... a developer should be modifying production code?
Hulk SMASH Celiac Disease
Why do they HAVE to commit to DevOps methodology?
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
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.
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.
The OP and article imply that this IS a problem.
It's not.
The only reason why it's not working is because you. It's your fault.
Fortunately, we can hire consultants to help you.
---- The above post was generated by the Turing Institute. Maybe.
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.
A government is a body of people notably ungoverned - AC
Am I the only one to whom This whole thread seems somewhat like reading a transcript of the Mad Hatter's Tea Party?
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
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 from both perspectives.
DevOps is a middle managers wet dream to eliminate a bunch of jobs. Unfortunately, the job ads all tout DevOps. True sysadmin positions are becoming rarer each day.
-- Will program for bandwidth
> Automagically usually means no peer review
We used the setting in GitHub to automatically require peer review before a change can be merged. That's the only reason we now have peer review consistently. It was spotty until we made it an automatic requirement.
Handling outage on production caused by code defect:
2 support people @ 0.5 hour
2 ops people @ 1 hour
1 developer @ 1 hour
1 mid-manager @ 0.5 hour
1 exec @ 0.5 hour (to keep asking what's going on)
Total: 5 man hours during the incident.
The after incident review is roughly the same, including preparation time.
Grand total: 10 man hours
Peer review: 1 developer @ 0.25 hours
Where I'm from, 0.25 is less than 10.
Peer review is one of the best ways of "gaining speed and reduce people needed".