DevOps: Another IT industry buzzword that does the rounds, especially when someone is trying to sell you something (no surprise there), but what problem is it trying to solve?
For me there are too many conflicting definitions as to what DevOps is and isn’t and in my opinion all of them could be right or could be wrong depending on your specific circumstances. Ultimately I would suggest that whilst in the area of development there have been big shifts towards the agile methodology and away from things such as waterfall, the barrier for this being successful can be the operations team.
So your development teams are charged with writing software that is adaptable with changing client/user feedback during the release cycle, with smaller releases, more often and more streamlined. This is partly where the whole agile concept comes from, if you can adapt to changing customer needs or business requirements quicker then this makes you more agile.
(BTW, I’m sure some will insist that this is distilling down agile too much and not recognising all its benefits, but as per everything, there are those who are sticklers for doing things to the letter, and those who treat things as guidelines and not absolutes. Note, I generally try to follow the latter category.)
Now where were we? That’s right, so traditionally the development team hands over the release to the operations team to deploy who are basically charged with exceeding metrics such as SLAs, RTOs, RPOs and all sorts of other super happy fun time acronyms. Remember this is the team that gets ignored for the most part when things run perfectly (that is just expected as the baseline), but cop heavy scrutiny any time there is customer impact caused by a fault condition.
These teams are consequently subject to at times really onerous change management processes, which only get worse when knee jerk reactions to faults occur. This knee jerk reaction dictates that there must be an improvement (aka an addition) to the change management process to prevent that fault from ever occurring again. Of course there is no analysis actually done on what implementing yet another check and balance to the never ending list of checks and balances will cost the business.
So you end up with a situation where development are making frequent releases and operations don’t want to deploy them because frequent change is contrary to the way in which they are expected to operate. This is where DevOps is meant to enter the fray and save the day, which is typically done using an assortment of tools such as puppet, chef, ansible, docker, kubernetes etc. etc.
Now ultimately what the aim should be is to break down the barriers to getting these new releases out there for your customers to start getting the benefit of. You need to empower your operations staff to adapt the way they work to meet the requirement of having more frequent releases. Does this mean that both your developers and operations staff need to be adaptable and will need to learn new skills? Sure, but that is just the status quo in IT as far as I’m concerned, if you want to stay relevant then you need to be constantly changing, adapting and reinventing yourself with new skills. There will of course always be people who are resistant to change, but sometimes you need to drag people along for the ride, or if it really comes to that – leave them behind.
Of course the easy way out is to hire another complete team to try and bridge the gap. This won’t do anyone any favours, you’ll just create yet another silo – which is the crux of the whole problem to begin with. People need to be adaptable, they need to be open to change – but for any change to be effective you also need to allow people to contribute and feel empowered. Remembering that these people in your organisation contain some very valuable intellectual property of yours, so if you marginalise or sideline them, when they decide to walk or you push them they also take that intellectual property with them.
Do I agree that DevOps is a valid thing? Yes, but I think its all part of the evolution that should be part of your operations and development teams seeking constant and continuous improvement together, instead of separated off and almost pitted against each other which has traditionally been the case. A top down approach may be required to kick start the process – and whether this is the way it is initiated or not, you will need to have top level buy in for this to be successful. The detail shouldn’t be dictated by the top level though, you need to give your staff the bandwidth to take an active role in deciding what and how to best implement these changes.