To sum it up...
DevOpts is NOT the answer to 'Life, the Universe and Everything'
Isn't it about time that the soothsayers (a.k.a Snake Oil Salesmen) move onto the next 'big thing' that claims to be the answer to that question?
DevOps can solve anything, can’t it? Well, no. In fact, if you don’t implement DevOps correctly, you’ll find that not only do you carry over the problems of the old world but that birth a few brand new ones, too. Application Performance Management (APM) firm Dynatrace has consulted a bunch of industry nerds and experts …
They will. As soon as somebody comes up with a new buzzword that can be easily marketed to the gullible execs out there.
No, DevOps is not a cure-all panacea any more than ITIL was. Or clouds. Or SaaS. Or any number of the recent and not-so-recent ideas. DevOps is just a set of tools for doing specific tasks and what is in this article pretty much sums it all up in that unless you know what you are doing and know what you need to do, it's just an accident waiting to happen.
The trouble is that I'm preaching to the choir here. The people making the decisions to implement DevOps won't necessarily read columns like this and won't necessarily take notice of those that warn them of the possible down sides. They see the nice, glossy brochures and the nice, large projected figures and say "yes please!"
And who can resist "8,000 times better" lead times ?
Certainly not the people who can believe that that is possible.
As far as I'm concerned, the faster you go, the less time you have to "make quality the top priority". There's something inherently in opposition between quality and speed, in my mind.
On the other hand. you'll break things a lot more, so it's a good thing DevOps makes you code like the wind.
The whole cloudy DevOps speedy demon future we're being pushed to just means that a developer's career is going to start in DevOps, constant panic and crunch time, endless releases and starting over, then migrate to legacy when the youngster is burned out and fed up with the commotion, then end with freelance consulting when old enough to enter the fray with a solid, cynical view of the whole process.
Business-impacting technology ? Why don't you ask 123-Reg how well that went for them ?
> As far as I'm concerned, the faster you go, the less time you have to "make quality the top priority".
I think that perhaps the point could have been made better. The trick is not that you're actually doing work more quickly, but you are delivering smaller packages of work to the business more rapidly so the business gets the benefit of what is in the package much earlier than it would if it was a couple of giant releases each year.
Sorry AB, but the ElReg exam on DevOps clearly stated "1000 words on DevOps" . Yesterday we had a nice 1000+ one and our punters rubbed themselves down with it....but yours is only 880 words, please amend DevOps style and get it up to 1000. Oh yes, our readers really can't get enough of it...we use it as click bait.
Well to be fair this time it did actually point out some of the problems with DevOps, although it was preaching to the choir.
Unfortunately the choir has spent month after bloody month preaching to the Reg so most of it are just going to think "yet another sodding DevOps article".
"One of the major activity elements inherent to the world of DevOps is exchange, connection and the ability to pass code and other information from one place to another."
Ever heard of having a single, shared code repository? With indentifiable complete releases?
"there’s a growing risk that teams will act independently of each other"
Erm, that's why you need development managers.
"but what happens when project number 101 is mandated or you buy a new dev and test team of five people? It’s back to the AWS contract re-negotiation board."
Can anyone explain what this means, other than that if you need more servers you have to buy more servers?
"Automated testing happens too late in the DevOps-centric software system development lifecycle "
Well then that lifecycle is total crap because you need to start automated testing and writing tests from day one of coding.
"your work teams are not building quality in at the beginning by implementing automated testing and deployment strategies."
See my previous sentence.
"chief security strategist Venafi, told The Reg: “Gartner reports that ..."
This is always a nice way of saying that you don't need to read the rest of the sentence.
"this generation’s equivalent of the earlier era’s cultural touchstone piece marketing and other businesses on "doing" community The Cluetrain Manifesto"
Nope, I didn't understand this sentence either.
"His answer: “Improving daily work is even more important than doing daily work,” Kim says in his book."
Gosh Gene Kim, DevOps Guru, thank you for letting me know that focusing on quality whilst doing my daily work is even more important than doing my daily work..... or something like that, I only wish that somebody before you had been smart enough to know that quality is important.
Anyway keep these articles coming, El Reg has always had a good eye for comical pieces on IT and we get them so regularly under the DevOps category. Unfortunately a good many pointy headed bosses don't seem to realise the laughs we're all having when we read them.
I wonder if they've already sold all the bajillion tickets to their DevOps guru-based seminar event or whatever and decided to change positions from "DevOps is the bees knees" to "DevOps sucks and you were all idiots to get on it".
This crarpticle and the other one ("white paper", no comments section) seems to point to it. Let's just see if they will repeat this trick again with whatever the new fad is (Fantacting? DevHolistic? BrainSpreading?)
I've been coming to this site everyday since 2005 (at least!), and this kind of advertising disguised as content is going to make me go away.
Mark it clearly as an ad, but don't try and shove this down my throat.
Yes, I'm just one of your readers, but this is how sites die.. one at a time. Just ask Slashdot. Or Digg.
"DevOps can solve anything, can’t it? Well, no. In fact, if you don’t implement DevOps correctly, you’ll find that not only do you carry over the problems of the old world but that birth a few brand new ones, too. (emphasis by me)
That's always the get-out-of-jail-card, isn't it? Every consultant's recommendation, every 'revolutionary new' idea of fixing things that are not broken, everything that falls under BaaS*, in short ervery bag of hot air comes with this in the small print. It didn't work? No, it wasn't a stupid idea in the first place - you did it wrong! Stupid little client... But don't despair - here's another bag of hot air we can sell you!
*Bullshit as a Service
> 30 times more frequent deployments (yes, we can believe that), twice the change success rate
err.. however you apply maths to those statistics, they imply a higher failure rate don't they?
I mean, only 2x the change success rate but 30x more frequent deployments implies a lot more unsuccessful deployments.... just saying...