'We already do that, we’re just OG* enough to not call it DevOps' At this point in the innovation curve for something like DevOps it’s fashionable to start asking “Where's the Return On Investment?” Answering that question is always tedious. For the hopeful, starry-eyed practitioner, spitting up the ROI figures is akin to the irrelevant water-carrying and wood-chopping trials imposed by a …
While there’s no end of success stories when it comes to DevOps, rather than sending an email full of links that’ll never be read, arrange actual meetings between your doubters and outsiders who’ve been successful with DevOps.
An all expenses-paid trip to a meeting in Cancun might convince the commentariat. Does this mean El Reg is paying?
Step 1) Avoid CVs/Resumes of people with DevOps on it
Step 2) Avoid technologies and products claiming to do DevOps
Step 3) Stop trying to teach IT guys how to code. They have more than enough to do just figuring out what should be coded
Step 4) There is no such thing as a DevOps degree. You're looking for computer science grads.
Step 5) Stop letting vendors try and tell you how to do DevOps
Step 6) Plan a project, build a high level design. Perform a PoC and document in detail step by step how to verify the system works.
Step 7) Write code to roll back the system when it fails
Step 8) On a whiteboard, make a REALLY clear plan of what changes are to be made and in what order
Step 9) Make the plan reflect zero downtime
Step 10) Write a script which can make the changes.
Step 11) Prepare for rollback, run the changes, verify the changes worked, verify the rest of the system didn't die, roll back when it screws up. Repeat until the change works without screwing everything up.
This is not complex. Any university comp-science grad can do this all day and night. We call it test driven development. Use Powershell to avoid stupid shit like 500 language syndrome. No don't use Python, Puppet, Chef, etc. You'll spend 99% of your time trying to figure out how to make Powershell work from inside them.
"first establish the baseline cost of following the “old” way, like staff’s pay, tooling, and the expected cost of fixing screw-ups"
...and then give the work to Developers who don't have years of experience in Ops, and only spend a very small percentage of their time focused on Ops resulting in way more screw ups to fix?
OpsDev would be a better idea because Ops deal with real production issues and know how it needs to work in the real world. In fact... I'm off to patent OpsDev. Or is it copyright.. Or should I release it under GPL?
How about the author arranges actual comment from organisations that have used DevOps successfully, noting IT estate size, number of staff involved etc... Because all I'm seeing in this rag is marketing bullshit, although given it's written by a "marketer" it's hardly surprising.
"OpsDev would be a better idea because Ops deal with real production issues and know how it needs to work in the real world."
Been saying that for the past 10 months or so... But feel free to copyright it or whatever, just send a couple of [see icon] my way, mmmkay?
I got as far as fewer code releases reducing cost before crashing and burning on "weekly releases"... HTF is that fewer releases?
In my organ, we used to have weekly releases to the mainframe. The developers did all the paperwork. Smooth it was. You could fix last week's bugs this week and put next week's bugs in. Now we have DevOps Sir! We have a team that charges 2% of everything and monthly releases... hooge complex multi-change releases. No idea which bit breaks what... still, at least with DevOps we don't need maintenance teams anymore, apparently :(
This post has been deleted by its author
Alternatively, we could all keep doing what we're doing because any notion of structure goes out the window in the event of shit hitting the fan in favour of I don't care how you do it, just fix it.
I'm going to start my own buzzword driven revolution called WR. I'll think of an appropriate bacronym later, but at the moment it stands for "Wheel Reinvention". Might need to get cloud and agile in there somewhere too though....
If Agile is Plan, Code, Build...
CI is Plan, Code, Build, Test...
CD is Plan, Code, Build, Test, Release...
DevOps is Plan, Code, Build, Test, Release, Deploy, Operate
As I understand it it's an extension of Agile principles further along the development lifecycle. People give a shit about it because it enables cross-functional teams, you can imbed quality control and security earlier in the process instead of an afterthought at the end - it should allow for better software to be developed quicker.
Of course for the embittered tech veteran its just another fad...
The problem is that someone has a bunch of good ideas and it gets a catchy name.
Maybe even before the catchy name, early adopters give the ideas a try-out and get good results. The problem is - these are almost always clever & highly-motivated people doing their tryout out of sight of management.
Where things start going pear shaped is that PHBs latche onto the catchy name, and to avoid embarrassment ask their management consultants to explain it all to them.
A new gold-mine is born. Suddenly the methodologies that said management consultants were pushing fo years are "out of date" and Must Be Replaced - because Money.
Personally I'm quite happy with the ideas behind devops (which is what we did in a small IT deparment a long long way away, before the management consultants arrived).
But the fetid tide of One True Path religious propaganda surrounding genuinely useful concepts gets a bit too much sometimes.
/me thankful to have bosses who are smart & competent enough to feel no need for management consultants.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
