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.
Most of our infrastructure/ops guys are in-house, but most of our development we send across the ocean.
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
Is the ones who decree a switch to an agile development process, but still want waterfall style year+ schedules.
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
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.
davecb@spamcop.net
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.
Specialist Mac support for creative pros, Melbourne
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.
Devops Devopping devops, only LUDDITES don't devop their devops!
> 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.
Yup. At many companies "devops" means ops/sysadmin without hardware. The old school ops guys might rack up a new server. The devops equivalent is writing some HCL and letting Terraform spin up cloud resources.
DevOps initial aim was indeed to have Dev and Ops working hand in hand using the same workflows and development techniques. The article is spot on. Unfortunately, "DevOps" engineer nowadays is more often the new name for "Sysadmin who does some automation". The "I do some Puppet, I am DevOps" syndrome.
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. The whole thing is just so fucking ops friendly it has nothing to do with developers writing production code. If you don't even know this much what the fuck are you even doing in this business anyway? Get out you archaic pieces of shit.
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, changing peoples mindset takes a long time.
On a long enough timeline, the survival rate for everyone drops to zero.
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 the classic companies - see the bets on fintech stuff as an example.
It would be silly to expect than 150 year old insurance company to get what DevOps even means without knowing the context, let alone implement it correctly (along with the move to cloud) and ditch all the heads that get lost in the transition. It's way more likely that CloudInsuranceCompany Inc. will come along and eventually replace them as a company in whole. ... Probably even funded by the same investors that made money off the classic company.
Outside of an organisation going all-cloud from the get-go, DevOps is little more than a fad and a buzzword that gets thrown around. Sort of like this "Agile" sillyness where 3000+ headcount orgs suddenly want to go "AGILE!" and implement Scrum across the board right down to the cleaning crew.
My two Eurocents.
We suffer more in our imagination than in reality. - Seneca
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 to live system without any manual supervision is a disaster waiting to happen.
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".
Because there is always one best way to do things, regardless of scale or domain!
I guess part of it comes from HR evaluating interested candidates at a job fair, wanting new graduates' skills to scale from trade school/university scale and domain to enterprise scale and domain. If some best practice can be shown to work at small and large scales, trade schools and universities ought to be teaching it.
what is ill conceive and what has that to do with my demand that developers have basic knowledge about installing/administrating a linux box?
The fact that you can't easily find a PC warranted to run GNU/Linux in North American showrooms. Buy an Android device or Chromebook, and you get Linux but no GNU (at least until Crostini becomes stable). Buy a Windows 10 PC and install WSL, and you get GNU but no Linux. Instead, one ends up playing hardware support roulette if buying a laptop or losing the ability to use it while riding transit if building a desktop from parts.
But then it wouldn't have made it onto Slashdot.
Still, I always enjoy seeing Ops guys talking in acronyms and trying to explain things.
"See, the CGR/UPX used to do the job of the BYX/KbW but now everyone uses GTFO."
It's like watching two '80s valley girls talking to each other. Fer sure!
strcat("Dev", "Ops");
I agree CONSISTENT style is more important than any specific style choice. Whether you want to coddle your braces or not, pick one and stick to it.
On our team, we have a Git hook that runs an appropriate *-tidy, so when code os committed it's automatically formatted according to our team's standard for whichever language, which is generally the same as what most people use in that language. Write code using any formatting you want - it'll be automatically be made consistent before other people need to read it.
Because the worst possible situation, for everyone, is that the file has a random mix of PascalCase, camelCase,.lowercase, and under_scores. Every time you use an identifier you have to look at which casing is used for each identifier. Choosing ANY formatting style is better than not choosing one. Better for everyone.
DevOps was coined at and the community driven through Linux conferences. Not sure how you went from that to MS certifications.
I'm out of my mind right now, but feel free to leave a message.....