Ready for DevOps? Time to brush up on The Office and practise 'culture' DevOps is the Holy Grail that could save your IT architecture – or so we’re being told. Do DevOps properly, and the IT department can deliver software continuously and fix complaints more quickly. This makes line of business managers happier, which is lovely. It also gives you more time to listen to their requests for new …
DevOps - A real "thing" or just more management wankery?
It reads like nothing more than a wish-list of all the "mission statements" and "core principles" that middle management aspire to, all chucked into a bucket, stirred a bit, then rebottled with a nrw name as if it's some Holy Elixir.
Polish a turd and you end up with a shiny* turd.
I think boatloads of us elder duffers have seen all sorts of nonsense come and go over the years. Same crap, different wrappers.
*Actually, you end up with an utter mess, but Management Wonks would have you believe in the shiny outcome.
Bugger me ... just noticed I'm 5 days late to this party! Seems NY's eve was better than expected!
If the company culture is up to maggots, and if management is clueless, well, you can toss any label/system/methodology/whatever about and still be guaranteed to spend n times as much for 1/n of the desired result ... and a solution which isn't.
/returning to my vat of CH2O now/
(subscripting lost, "2" not subscripted as it ought to be!)
Good for hotel room management,
IT operations (and even development?) Not so much.
Even if quality gurus affirm otherwise (they wouldn't be gurus if they actually spent the time doing the stuff they are talking about though, they would just be another trash compactor maintenance person)
Another week, another DevOps article.
And yet, no one can seem to make it work.
Like Little Mouse said, its just more management mumbo jumbo. And the fact that there is now a coined term to highlight "How to do it!" should tell you something...
I've espoused my experience and distaste for the idea here many times. The only way it could possibly ever work is if you had a CTO who was proficient in both development and infrastructure and was able to view things objectively. Such people are rare to say the least.
One size never fits all. In some environments (and applications), pushing changes continuously can work. In other, it can just create havoc - and it's not because of "culture" - it's because of the needs and complexity of the environment itself, and no technology will help.
>he who builds shall not run, he who runs, shall not fix.
For we shall silo our expertise into different outsourcerers on the grounds of cost-cutting, in honour of the mighty god Mordac, Preventer of Information Services. Our fixers shall fix in the Philippines, our runners shall run in India and our builders shall build locally. For lo, MultiNational Enterprises are a Success by Definition, are they not? And the explicit cost savings shall be half my bonus for achieving them, while the hidden costs shall be identified and moved around by a new incarnation of Mordac, who shall appear after the opening of my parachute of gold.
We have taken the holy words of Scientific Management and repackaged them, for we know that McDonalds and Foxconn practises are great in the eyes of Industry.
One developer working on a new site/application which is not live yet - easy.
One developer working on a site/application which is now live with transactions/articles etc flooding in - not so easy.
(Remember folks - the days of static websites are pretty much behind us).
Many developers working on a live site/application simultaneously - very hard. Devops needed.
Get it right and the stakeholders can be extremely happy - a team (which, ahem, I set up the Devops for) received (expensive) champagne for a project delivered ahead of schedule.
Most of the time there are two main problems.
The first is developers who have no idea about Devops and have no inclination to work as part of a team. If you have developers like this then the only way Devops can be implemented is with CTO backing.
This brings us to the second problem. Most management do not understand the need for Devops. They think that their genius developers can all work together on the same systems without any management/devops - as if by magic. Then they are puzzled why nothing gets fixed anything like quickly.
The good news - the kidz who know their stuff are trying to sort it out. Github/Bitbucket, Pull requests, CI tools like Shippable/CircleCI, automated testing, Heroku, hosted MySQL/CDN's, Javascript apps sitting on REST API's, Slack, Basecamp, Ticket systems, etc, etc. But unless there is CTO buy-in to get someone to implement this properly then most projects will turn to mush after they go live.
And this is a key point - before a project goes live it's easy - any part can safely be bodged around with - progress seems to be good. As soon as it's live the development grinds to a near halt.
One of the answers is that the whole development and deployment to live needs to be sorted out at the very beginning of the project - before any meaningful development has taken place. So,as an extreme example - a live site could be initially set up with a single 'Hello World' HTML page (behind HTTP AUTH etc) and the developers are set up to deploy their changes safely to live during the development process. Site editors can also be adding content to the new 'live' site. Then, 'going live' means simply removing the HTTP AUTH - and - crucially - further development is carried out in exactly the same way that development was carried out during the site build.
The final part of this is missing from most places where I've worked - and it is key - difficult - but key. Automated testing - primarily BDD testing I would say over unit testing. Imagine your site/application having every single aspect built with a test implemented at the same time. I've worked somewhere where websites could have a few thousand tests each. So a developer makes a change - large or small - and after they submit their change three thousand tests run (on dev/QA/staging etc) to check everything else on the site/application still works. Beautiful - and the way it should be done.
And I agree with the article - this Devops needs to be maintained/enhanced throughout the project development cycle - and even into the maintenance cycle.
@Bailey86
Congratulations. What you have described is what I call Dev Dev. Not once in your comment did you mention systems. For Dev-Ops (emphasis on Ops) to work, both parties need to be involved. That's the goal, right? Rapid, collaborative development and deployment of applications to production, involving all required teams to meet customer needs.
If your development team uses the Agile method or scrum or whatever, welcome to 2010+. That isn't Dev-Ops. It's just you doing your job. :) Sorry if it comes off snarky, but this is the problem with "Dev-Ops". Developers are all over it, but have no idea what it really is supposed to mean. Then they deliver a product to engineering and wonder why it won't get released to production or why there isn't capacity for it. Dev Dev.
'Congratulations. What you have described is what I call Dev Dev. Not once in your comment did you mention systems.'
Of course (live) systems are involved in what I wrote. That's why I put the example of the live hosting being implemented from the very beginning of a project. And that would obviously include how those live systems are maintained etc. It was a main point of what I wrote.
As an extreme example, too often this is only thought of after a developer has built a site on their laptop. Some live hosting is arranged, the site is now copied to that hosting - and only now does anyone think of how to deploy changes to the live site in a managed, tested and safe way.
I thought I'd made it clear. And automated testing should mean that deployment to live is trivial. In fact, I worked in one place where devops was done well and deployment to live was carried out by junior devs.
And also, it is why you need CTO backing. To implement Devops you need be able to organise both development and systems - and CTO backing will be needed because very often those two groups will dig their heels in.
If you have managers in place who rule through fear, humiliation and threats, it might be time to rethink your team before you start.
Like many other things that seemed to be a good thing in their time, this ^^^ will guarantee failure. I don't know of any company that doesn't have management in place like that. Maybe not at every level and every department but enough are around that they will sabotage anything that involves changes in thinking and action.
I've only been exposed to the "DevOps" movement for about a year as the company I work for is looking into doing it, but I've been reading up, listening to podcasts, webinars etc and from what I see is that the origins are in Lean, which in itself comes from the Toyota Production System. If you drill down the the base philosophy of continuous improvement, eliminating waste (wasted time, resources etc) and ignore all the hype, tools and BS, then I think DevOps can work.
I'm reminded of a story in one of the books I read about TPS, where the auto industry said it won't work. They would go to Toyota, record and copy everything they did and replicate it. It didn't work. They would go back and find that Toyota did everything different again, because they way they work continuously evolves. I think that is the point, continuous evolving to try to get better. I think the failures to implement come when you ignore the "evolve" part and just expect it work aka a silver bullet eg. you have CI/CD in place, automated testing etc, you're doing DevOps. That is what I'm seeing in the company I work for at the moment.
Anyway, that is my opinion given I have no practical experience, only what I can work on in my own time. So take with the appropriate grain of salt.
Any company that builds and runs and maintains a web site with no help from design agency and minimal resources from the hosting service, have been doing devops.
Any company that has built an application in Google App Engine or Amazon Web Services has been doing devops.
Devops ; development, and operations. Normally two silos in many companies that run their own Tin. In my company it is three because we also have Application Management. Or is it four because of our global help desk service?
But you get the point. Small companies that wanted to use WWW and Cloud have been doing devops because it was the only way they afford to get into it.
Devops according to this acronym (CAMS) is about trying to scale the essential feedback loops to big systems, currently tended by hundreds of people managed by possibly more people across multiple departments using mostly broken administration services from the last century.
... living within a small company. As an IT superhero, that kind of person will actually be able to create a service, run that service properly and keep adapting/improving it at the same time.
Don't expect to find many superheros of that kind, don't expect them not to realize how precious they are, and don't expect to have them very long - you will lose them either to higher paying companies or due to burnout.
And don't expect that DevOps could be a suitable working model for large organizations.
DevOps potential has received a great deal of attention because of its advantages. Software change requests are quite common and are most expected during the software development phase. Project managers need to consider change requests for a successful project delivery because responsiveness to change requests is key to customer satisfaction and an important ingredient of project success
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
