Submitted via IRC for TheMightyBuzzard
In today's fiercely competitive environment for customer satisfaction and brand loyalty, agile and DevOps are driving happier customers and employees. Results from a new CA Technologies global study reveal that advanced users of agile or DevOps realized significant increases of up to 52 percent in customer satisfaction and up to 50 percent in employee productivity.
The results showed a 30 percent advantage in employee recruitment and retention for companies that used agile and DevOps together to improve the working atmosphere for their employees – a huge benefit when you consider the shortage of talent in IT and the costs associated with attracting and retaining the best employees.
I guess I can't argue against it since I've been doing it nearly everywhere I've worked since the late 90s. Having separate Dev/Ops teams in SMBs [Small and Medium Businesses] is a pretty hard sell.
Source: https://www.helpnetsecurity.com/2017/01/12/devops-adoption/
(Score: 3, Funny) by c0lo on Monday January 16 2017, @06:19PM
You (CA) mean shortage of talent that works for peanuts or on 80h/week (or both), right?
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 5, Touché) by Thexalon on Monday January 16 2017, @07:03PM
Also, more specifically addressing the claims here, "DevOps" just means "Bully your developers into doing the work of system and network administrators, and vice versa." In a properly run IT department, yes, those fields have to interact a lot, but they are different specialties: Your developers won't generally know about the nuances of data center design, nor will your admins know about the nuances of reducing algorithmic complexity. "DevOps" is not only a stupid buzzword, it's a stupid idea.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 1, Touché) by Anonymous Coward on Monday January 16 2017, @08:54PM
Whoever modded this disagree must be a manager...
(Score: 0) by Anonymous Coward on Monday January 16 2017, @08:56PM
DevOps is agile sysadminery. Don't test anything. Change production directly and hope it works. I do that all the time. I'm supposed to have brand loyalty? The fuck does that mean? I did all the SEO advertising and shit and my app is found by all the keywords. Still nobody fucking uses my app except me.
(Score: 3, Interesting) by meustrus on Monday January 16 2017, @09:42PM
I find it really unfortunate what people around here think DevOps means. Where I am, DevOps means that devs have access to infrastructure and can provision what they need. It takes good tools to give that kinds of access without worrying about whether devs understand the nuances, sure. But we have good tools, mostly based on AWS.
DevOps shouldn't mean that devs need to design the data center. It should mean that devs can develop the infrastructure scaling code as well as the code that is being scaled. It means that devs can manage their own Jenkins servers and not have to make cross-department requests to change a plugin configuration.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 2) by jelizondo on Monday January 16 2017, @10:35PM
Then you get devs who have configured their infrastructure in such a manner that is not deployable because it breaks other services or applications in the production environment.
As Thexalon [soylentnews.org] pointed out, the two fields are separate and unless you’re running a small organization, they should be separate for the same reason you wouldn’t want a general M.D. performing surgery on you.
Yep, it’s a pain in the arse having to request thru the sysadmins whatever you need, but it saves a lot of pain down the road for everyone.
(Score: 3, Interesting) by rleigh on Monday January 16 2017, @11:12PM
One thing that I think the devops way of doing things ignores is that we aren't all generalists and interchangeable cogs. While I can sit down and learn all the tools (and in fact already do know some of them well), it's not a very effective use of the time and expertise people already have.
As a developer, I don't really want to have much to do with setting up jenkins, provisioning, chef/puppet/ansible and all the rest of the glue that makes this stuff go. I already have one full time job which requires significant expertise; I don't need another two or three on top of that. It's one thing to lend a hand and create or tweak a job to test and deploy your stuff, or fiddle with a VM, install a missing packages etc, but maintaining the whole thing end to end is just too much, IMHO. You could employ a sysadmin or ops person to do this; they would likely be better at it!
(Score: 2) by Thexalon on Monday January 16 2017, @11:30PM
Then what it sounds like you are doing isn't DevOps, what you're doing is outsourcing a lot of the "Ops" side to Amazon. That can certainly work, but that's not the same thing as having nobody focused on infrastructure: Just because the people doing it aren't working for your company does not mean nobody is doing it.
I agree that devs could and quite possibly should develop the infrastructure scaling code. But the ops side should be designing the specifications of said infrastructure scaling code, as well as having input on the specifications for the code being scaled so that it does so more easily. And that still leaves ops plenty of other things to do, like hardware maintenance (if you have any of your own hardware), security management, backups / disaster recovery, and of course figuring out how to best give the devs what they need to fulfill the latest silly requirements imposed by marketing.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Tuesday January 17 2017, @01:38AM
It also means significant cost savings when the developers can get tools that automate what they need, thus eliminating the pesky and expensive people who maintain the hardware they push code to.
(Score: 5, Funny) by Rich on Monday January 16 2017, @06:21PM
- competitive environment - check
- customer satisfaction - check
- brand loyalty - check
- agile - check
- DevOps - check
- global study - check
- employee productivity - check
- recruitment - check
- retention - check
- shortage of talent in IT - check
BINGO!
(Score: 0) by Anonymous Coward on Monday January 16 2017, @07:12PM
Damn it. I just needed "synergy" too.
(Score: 0) by Anonymous Coward on Tuesday January 17 2017, @10:46AM
"A global study of customer satisfaction with employee productivity in a competitive environment with brand loyalty showed that retention of agile DevOps recruitment leads to a shortage of talent in IT."
See, I managed to get all the words in a single sentence! Since I've got a higher buzzword density, I'm clearly the better expert! :-)
(Score: 2) by bob_super on Monday January 16 2017, @06:54PM
My boss thinks he's implementing Agile ... I've sent him a detailed list of how we're clearly not doing Agile right.
He hasn't changed anything, mainly because we're too few people on too many project to do Agile properly, but he still acts as if we were doing Agile...
More than a bit painful, really.
(Score: 0) by Anonymous Coward on Monday January 16 2017, @09:07PM
My boss read about this on blog his boss made him read, so we're going to be agile.
Something about a button that sets up everything cookie cutter automatically, too. outside consultants will make the button do what the button is supposed to, and completely unskilled labor by HCL will press the button. there is a troubleshooting tab, too, which include advice about calling an Indian helpdesk.
I asked what happens if there is a custom requirement, like if switch port doesnt work or the MTU has to change sizes or what if they use iscsi or voip and there is qos instead of just an automated need for a switch wizard, and I was banished for being an obstacle.
My employer is preparing to spend millions of dollars to get rid of all of their MCSEs entirely (actually, they outsourced to compucomm just recently) and now wish to get rid of all of their CCNA level positions and replace them with scripts run by HCL.
Security, they said, was a weak spot but the cost savings were too good to just set aside the promise of a single button people can press to set up new office environments. I said OK -- but I am sure my job in the data center core is going away before long too.
(Score: 2) by rleigh on Monday January 16 2017, @11:04PM
I think this sums up pretty much every "Agile" organisation I've experienced or read about!
(Score: 0) by Anonymous Coward on Monday January 16 2017, @09:29PM
Choose your own adventure
The main problem with the agile/devops from where I sit is I don't get to see/asses the product/project against any type of security controls/compliance until its a week before it goes out and they ask for a pentest/audit when its already in prod and live to the internet (just not had its official launch).
Also they always want the prod/customer/private info floating in dev because they need it for some reason - probably because they hard code the variables in the underlying databases or something as asinine.
And done get me started on state of test (hint doesn't exist because its that full of prod data because there is only one product, that's whatever version is live)
Signed your friendly pentester.
(Score: 2) by tibman on Monday January 16 2017, @10:03PM
It seems like they should have roped you in when it was staged in QA. An issue with functionality or security would be kicked back to dev the same way.
SN won't survive on lurkers alone. Write comments.
(Score: 0) by Anonymous Coward on Monday January 16 2017, @11:06PM
Yes, agreed.
It took me a long time but I now have the business including us security team in change management/project planning meetings (not their choice, some of them still insist that because its in the "cloud" the security team is not needed because its not the business's computers). I have managed to put some pressure, mainly by nuking from orbit (decertifying projects that were already live - effectively stopping the flow of data) until their latest change was rolled back (something something self-signed instead of our PKI because the low level dev didn't have the passwords to generate and couldn't wait until we got to the ticket because of business SLA pressure)
Its already in QA, but I've come across multiple sets of paperwork with security's signature left blank but with final acceptance rolled out because the business had promised a deliverable to out clients and security was "too busy to look at it in a timely fashion". We only picked it up when there was an assessment request on a update and we requested the V1 paperwork
Speaking to my drinking mates downunder its pretty common position to be in in this (major) city.
(Score: 2) by meustrus on Monday January 16 2017, @09:45PM
I'm not surprised at all. After all, CA just in the last year bought and consumed Rally, the crappy enterprise competitor to JIRA or Trac. Now that they have an Agile ticketing tool, of course they would evangelize Agile.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 1, Interesting) by Anonymous Coward on Tuesday January 17 2017, @03:30AM
I have used both Jira and Rally. Rally is a good tool for scrum agile *IF* you use it in their specific way. If you do that it is an excellent tool. If you try to put your own process into it the whole thing becomes painful to use and becomes just a way for the PM to make you do their work instead of using better tools. Jira suffers from the opposite problem. It is very flexible. But there is no 'default' way that is any good. So you have to muddle through it and hope you can make a process out of the thing. Then the tools to do it are kind of obfuscated and it is not clear how to track things or fix a track that is going wrong.
Both suffer from the 'you need to take a class' to make it work right. They are a good way for both companies to sell you their process using your money.
(Score: 0) by Anonymous Coward on Monday January 16 2017, @09:58PM
I just came across this interesting document,
https://cstools.asme.org/csconnect/FileUpload.cfm?View=yes&ID=24816 [asme.org] (pdf download):
An Overview of the PTC 60 / V&V 10
Guide for Verification and Validation in Computational Solid Mechanics
Question: Are the sometimes lengthy and costly processes of verification & validation really necessary?
Consider the following scenario that perhaps you can relate to first hand. A project review meeting is taking place and the project manager needs to make a critical decision to accept or reject a proposed design change. A relatively new employee, freshly minted from the nearby engineering university, makes an impressive presentation full of colorful slides of deformed meshes and skillfully crafted line plots indicating the results of many CPU and labor hours of non-linear numerical analyses, ending with a recommendation to accept the design change.
Hopefully, an astute project manager, aware of the vagaries of nonlinear numerical analyses, will not accept the analysis and its conclusion at face value, especially given the inexperience of the analyst. Rather, the project manager should seek some assurance that not only are the results reasonable, but a sound procedure was followed in developing the model and documenting the numerous physical and numerical parameters required for a typical analysis. The degree of assurance sought by the project manager is directly related to the criticality of the decision to be made.
The processes of verification & validation are how evidence is collected, and documented, that help establish confidence in the results of complex numerical simulations.
This is the world I live in, are any of these new buzzword methods going to help me?
(Score: 2) by arslan on Monday January 16 2017, @10:33PM
Not sure why the OP thinks it is just a hard sell to SMBs, it applies even in large organizations especially those where the IT reporting line is parked under the CFO or COO and is not a major contributor to the profit line. Why would they bother changing their highly cost efficient model of having a pool of IT resource worked to death on multiple projects that, although delivers sub-optimal results, but workable enough applications for the corporate staff to use - even if they have some manual workarounds and tolerable quality?
The model is easier to sell when IT either is a profit center or is a critical dependency to the profit stream, i.e. a more digital driven business. For a lot of the more traditional business where IT is just an enabler for the non-IT staff. All this buzz about devops, agile, kanban, TDD, CD, etc. is really just snake oil used by the Con-sulting companies to part folks from their cash and propeller heads to pad their CVs.
(Score: 2) by c0lo on Tuesday January 17 2017, @12:11AM
FTFY
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Tuesday January 17 2017, @05:22AM
Devs: We have this great new product we're going to put in production! Because we're DevOps empowered!
*time passes*
*alarm sounds*
Devs: It's not working ... uhhhhhh, because the shitty ops environment sucks donkeydick! Make the ops fix it!
Ops: Uh, OK. So, this thing you installed, where are the packages?
Devs: No packages, we just copied our latest build across.
Ops: Oh, great. Like, not the way you're supposed to do it...
Devs: We don't have time for that! We're busy people! It works fine in the dev environment! Now fix your shitty shit!
Ops: OK, great, so, can we see the instrumentation of your app?
Devs: I don't understand anything you just said.
Ops: The production standards include instrumentation delivered by SNMP ... can we have the MIBs you set up?
Devs: We couldn't do that! Don't you know we have deadlines? Now fix your shitty shit, the customers are mad as hell and the COO is going to hear about it!
Ops: Sheesh. OK, fine. Can we see your architecture diagram? Protocol usage? Anything so that we can see how this works?
Devs: We have this powerpoint slide from six months ago ... we may have changed a few things.
Ops: Fantastic. So, while we're reverse-engineering your stuff to fix that you didn't document, instrument, or install the way you're supposed to, can you at least (pretty please) give us your testing harness so that we can use THAT for analysis?
Devs: Here's some code that is hardcoded to work in our dev environment, now go away and stop bothering us, we have a deadline to meet! And fix your shitty shit! The CEO is mad as hell at you guys!
*time passes, Ops reverse-engineering like a team of chinese industrial spies*
Eureka! Turns out that Dev's test case ran fine on a test database approximately one tenth of the size of the real customer database, and they never actually specified a database machine sized to handle the real load. Nothing actually broke, but the latency involved made the pages break because of timeouts. Something that could have been discovered in mere minutes, had the actual application been actually instrumented with actual thresholds the way it was actually supposed to.
More time passes, during which a dev-who-shall-remain-nameless gets so monumentally stupid as to go into the datacentre and "just fix something" on live production using a backdoor to root they'd left in (in a suid-bit binary), breaking things horribly, resulting in a new policy that only certain people are allowed into the production datacentre. How this is supposed to prevent devs from getting cute remotely, I don't know. Nobody bothered to explain their decisions to the rank-and-file.
More time passes. Another project with a huge high-stakes deadline comes up. (If you've been following the trade press for the last decade, you've heard of this product, I guarantee. Big money, high profile.)
The devs beaver away at this product, then produce a lovely system to offer it to the public. Classic three-tier cluster structure, LAMP stack, should be perfect. They test the bejeezus out of it in pre-production (or so I'm told; I have only their word for it, but what the hell let's believe them on this one), then come down to the ops guys because their production access has been cut off.
Devs: Install this. Chop-chop, deadline's coming up!
Ops: OK, sure. Where are the packages?
Devs: NO PACKAGES! Geez, what is with you guys?
Ops: *massaging temples* OK, fine, what is the deal? Untar, make, install? Binary files?
Devs: JUST IMAGE OUR DRIVES! NO MONKEY BUSINESS FUCKING UP OUR PERFECT CODE!
Ops: ... you're kidding. Oh, you're not kidding. Uh, guys, that won't really work because the IP addresses in the production environment don't match your pre-production...
Devs: THEN CHANGE THE DAMN ADDRESSES! Shit, do we have to think of everything for you people?
Ops: Right. Great. OK. Anything else? Are we permitted to put the production security setup on it? Like, SSH keys and stuff? We have this PCI audit coming up, and ...
Devs: JUST FUCKING DO IT! DEADLINE! Do you understand the word? DEADLINE!
Ops: OK, fine. Can we see the architecture diagram or anything?
Devs: *point at their Nike shirts* JUST. DO. IT.
Ops: OK, fine. Whatever you say, massa.
Ops goes away, does the install. Duplicates pre-production down to the production run of the CPU (no kidding). Images drives literally. Changes network config, disables root login, adds maintenance SSH keys, etc... Fires up the environment - and it works! Smiles all round, ahead of deadline.
Deadline comes, and environment goes live. For maybe twenty minutes. Environment crashes and burns like a reality TV star on a bender. VPs go ballistic. Director flips his shit.
Devs: *pointing to ops* They did it. They're all incompetent, you know.
Director drags everyone in Ops into the WAR ROOM. Orders: Nobody leaves until this is sorted, on pain of immediate termination. Fine, whatever. A dozen on-shift techies stuck there with laptops breathing each other's farts. A token dev in there, throwing shade.
First, they blame the network. Network admins point out that the network link up to their cluster's drop is practically asleep, no lost packets, no signs of trouble. They get excused, but told to keep their phones on and stay available. Fine, whatever.
Next, they blame the installation. Rack-and-stack guys had anticipated this after the last shitshow, and had chapter and verse on every purchase, serial numbers of all relevant parts, model and revision numbers of everything from the top-of-rack switch (specified by Team DevOps) through to CPU. They demonstrate their drive imaging, and they get excused, but told to keep their phones on and stay available.
Next, it must be the sysadmins! They sabotaged it somehow! They broke the config! They don't know what they're doing. A huge argument ensues as the manager/head admin goes over every damn config item with a fine-toothed comb, pointing out that they didn't even put monitoring agents on the systems because the devs wouldn't let them (they weren't there in pre-production, after all).
While all this is going on, some smart cookies are actually looking at the only instrumentation that we do have: the network, and realise that the cluster's internal bandwidth is capped at some ludicrously low number. On the low-down, the networking guys get quietly asked whether that mightn't be the total backplane bandwidth of the top-of-rack switch that the devs specified. Why yes, yes it is! And it is totally inadequate, that any REAL performance test would have shown up in a hot minute. This gets pointed out.
*uncomfortable silence*
Devs: Impossible, it worked fine in pre-production! And besides, this is just a very popular product, we need more servers! MOAR SRRVRRZ!
Ops: Uh, if you do it that way, the bottleneck will still be there. And, funnily enough, buying another switch (really, replacing the top-of-rack switch with a more highly specified one from stock, and then buying back the replacement for the stock one) is many, many dollars cheaper than bringing on so many more servers. And faster too.
Management: MAKE IT SO!
Before the end of business, everything is humming like well-oiled machinery.
Ops to management: So, listen, we can't help but feel that the OpDevOp Special Forces Operators kind of could have used our advice, and if we're going to do the DevOpDevs thing, maybe it's smart to actually involve people who understand infrastructure as well as software development? Maybe?
Management: FOAD, slugs. Don't make us fetch the salt. You just get in the way of the devs trying to do their Software Engineer Heroics! That's why we have DevOps!
Ops: Well, if they're going to dev away the ops functions (which is what is supposed to happen after all) wouldn't it make some sense to have people there with a handle on infrastructure management?
Management: HAHAHAH! As if! You guys don't understand anything devs don't! Now, you may not have heard this, poor dears, but those devs are really, really sharp cookies. They will dev it all out perfectly! Just you see! Just like that lovely Chef infrastructure we have!
Ops: You mean the Chef infrastructure we created?
Management: *shakes salt cellar menacingly*
=========================================
So, yeah. DevOps. Great for devs in a hurry who don't want Mordac the Preventer of IS screwing up their deadlines. Wonderful for pre-production where moving fast and breaking stuff is mostly going to result in a few chuckles or groans. Even OK for startups who can wave a hand and talk about how cutting-edge they are.
Not good for environments where serious stability is an utter requirement, unless your DevOps team is so full of infrastructure people that you might as well have had an ops team - and then only with a similarly skilled QA team. The little episode I sketched above? Cost millions of dollars. Millions of real-world, USA mint, Uncle Sam approved greenbacks. And that's just the lost business, not all the skilled people being yanked around by scared executives. If your downtime is counted in more than a couple of zeroes per half hour? Be very, very scared of DevOps.
If there's a federal investigative team with handcuffs on their belts, waiting for you to go down? .... sure. DevOps all you want. I'm sure you'll be frightened enough to put the checks in place that you need.
(Score: 0) by Anonymous Coward on Wednesday January 18 2017, @09:34AM
You've missed your own point. The problem with your company is the management, not Devs or Ops or any other section. Management doesn't know what they're supposed to manage nor how to manage it. Everything you mentioned should have been addressed by management before they became issues.