'Do the DevOps?' No thanks! Not until a 'blameless post-mortem' really is one What drives organisations to change their ways? What's the match that lights the powder keg of actually doing something new and different in IT? That's the question I usually get from organisations that want their approach to software to be more "agile", who want to go through "digital transformation", and, yes, "do DevOps". …
senior management is unable to let go of, budgets are another. You can't be agile if you have to fight for a discreet budget for every change, if your time recording system demands that budget code, and if senior management response to the markets is to cut expensive devs to meet quarterly profit numbers.
Confusing ITIL/ITSM with either agile or devops is another huge mistake. Put ITIL/ITSM in charge and you drown in paper and process, for little tangible gain.
And still blame trickles down...
One problem I’ve encountered with “doing the DevOps” is that it is perceived as a new way to do IT. All of IT. Everything agile.
The article hints at it, it works really well for software development and release. Being agile delivering hardware is not so easy. You can be agile if you’ve delivered a capability to be that way, hardware sitting waiting to be used. And cloud can help. But in this austere world, who is really going to pay.
DevOps is NOT a panacea, a cure all. It is simply another tool in the box to potentially bring benefits. Done well, you save. Done badly, you go out of business.
I was talking about this with a friend yesterday evening - businesses with enormous risk potential (i.e. banks) are incredibly risk averse and this generates IT practices that favour disconnected, non-converged silos of systems with high levels of technical debt. But at the same time, this, at least on the surface, prevents broad systemic problems from affecting the entire business' IT when something goes wrong. Since devops is so often 'sold' as realising various business efficiencies from converging these silos together, that's anathema to that way of thinking and so things stay the same.
It means do what I want, start now, deploy next week.
It does not mean find all the stakeholders, how t can be deployed, worry about long term TCO, or the failing cloud SaaS parner he got lunch from, data security or any other governance or quality distractions.
They will not even realise its the name of a methodology.
When things go wrong, it will be down to someone delivering what was asked for against their principles of doing anything to a reasonable standard. they will be scapegoated regardless of being forced to skip quality gates in the name of "Agile".
Toss in devops and associated infrastructure and things can get even more confused - can't you just spin up a new mainframe tomorrow and speed up light so our offshore developers can get reduced latency...
As far as I am concerned the whole principle of the methodology has been tainted by its title and its exec interpretations. Its a method that should have been kept in the secret dungeons of people that know what services they are trying to deliver and what tools are needed to deliver them...
only 37 per cent said their organisation was proactively investing in "digital transformation"
Shockingly enough, not everyone actually needs to "transform" their cutlery drawer with <a href="https://en.wikipedia.org/wiki/Spork>Sporks</a>. Some people get along optimally with the separate knife, fork and spoon they've been using for a couple of centuries. Eating food is a solved problem for them, so not only do they ignore sporks today, they'll probably still be ignoring them decades from now.
It's a question of reliability and efficieny you see. Cutting a steak with a knife, using the fork to stabilise the process carries a much lower risk of showering your dinner guests with garden peas when compared to hacking away with the blunt edge of spork. As with most multitasking tools, the spork manages to do three jobs at once only by being significantly worse at all of them than the specialist tools it replaces. Many people aren't going to buy into that proposition for the same reason no professional mechanic is going to trade in his socket set for an adjustable spanner.
As a sys admin my biggest problem with devops is getting forced into supporting some convoluted buzzword-based crap that some devs have come up with, that pretty much ignores any conventional wisdom.
So we have Docker containers that are mimicing a proper server (when a virtual machine would be a better and easier option) using 2GB+ images. Pretty much the complete opposite of what a container should be...
@ Jay2:
And hauling in GIT repositories that were put in place 3 years ago by someone with a leetspeek handle that have never been updated as 'core code components'.
Or python modules with 275 dependencies hitting 55 repos that update once a month on different days of the month. Or RoR based on code written by "B0hrrr44T$9000"
I had to quite literally stab a Sdir in the back to get a QA department involved.
"[...] and the so called "frozen middle" who keep existing processes in place. "
Paraphrased quote: "Middle management is like a blancmange - any proposed change makes it wobble - then it settles back into its old shape".
IIRC attributed to a frustrated new CEO after being in the job for a while.
I had a CEO who made that sort of complaint. Along with things like "When I was developing, I used to work 100 hour weeks. Why are none of the staff doing that now?"
To which the answer was obviously, you were founding a company and you own a substantial fraction of it. Of course you care deeply about it working as well as it possibly could. The rest of us are just here to do our job and collect a pay cheque. If you want us to care, give us stock options.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
