DevOps is a term coined in 2009 which has since evolved into a movement of people passionate about a set of practices that enable companies to successfully manage rapidly changing IT services by bridging the gap between Development and Operations teams.
In my experience DevOps is very rewarding, so in this blog I’m going to try to bring its practical side to life. I hope my post may help a few people connect DevOps to things they are already doing and even better, form some ideas about how to go further.
The basic premise of DevOps is that most organisations with IT functions have separate teams responsible for software Development and for IT Operations (aka Service Management.) The observation is that separation of duty can have a negative side effect of inefficiency, unresponsiveness and unhappiness.
If your company is meeting its business objectives and you don’t have any sense for this pain, you’ve probably read enough! Put the blog down, get yourself an ‘I’m rocking the DevOps’ t-shirt and leave me some comments containing your secrets so we can all learn from you!
A lot has been written that analyses the misery of Development versus Operations, so I’ll keep it brief.
The problems stem from the natural tension between Developers (who deliver changes) and Operators (who are incentivised to maximise service availability and hence prevent changes along with other such obvious threats.) Add to the mix some wholesome but local optimisation (performed independently by each team) and you may start having ‘annual budget’ loads of completed yet unreleased features and stable but stagnated live service. Periodically the Business teams mandate a ‘go live’ thus blowing up the dam and drowning live service in changes, some of which has actually gone quite toxic…
In the ideal world developers should be assured of a smooth, almost instantaneous transition of their code into production. Operations staff should be assured of receiving stable and operable applications, and of having sufficient involvement in all changes that will impact service (in particular altered hosting requirements.)
I think of DevOps as a campaign which we can all join to maximise the throughput of successful IT changes where we work. I’m personally ready to trust business teams to ensure we are choosing to deliver the right changes!
Where to Find the Fun
People and processes…, blah-dee-blah… Ok, fair enough, DevOps does revolve around people, but we all like technology, so let’s start with the fun parts and come back to people and processes later!
Typical DevOps Technical Concerns include:
- Configuration Management
- Application Lifecycle Management
- Environment Management
- Software and Infrastructure Automation.
Where I work we have a well-defined technology architecture methodology which neatly classifies these concerns Development Architecture (aka DevArch).
Q. Does taking very seriously the above concerns mean you that are doing DevOps?
It helps, it’s a good start. But it’s also key that the above concerns are consistently understood and are important priorities to both Development and Operations.
Caring about these concerns alone isn’t enough, time to tool them up!
The great news is that the popularity of DevOps has made the tooling space awash with fantastic innovators of excellent tooling. There are too many to mention but current favourites of mine include the orchestration tool Jenkins, the version control tool Git, the code quality framework and dashboard Sonar, and the automated configuration management tool Chef, and the VM manager Vagrant.
We are also now at the point where freely available open source tools (including all the above) exceed the capability of many commercial alternatives (hasta la vista ClearCase!).
Q. Does using some or all of the above types of tool mean you are doing DevOps?
Not necessarily, but they help a lot. Especially if they are equally prominent to and shared by Development and Operations.
Perhaps we need to add automation – lovely stuff like automated builds, automated deployments, automated testing, automated infrastructure.
In more good news, the understanding and appreciation of software delivery automation has gone up massively in the last few years. Gradually this has reduced fear (and denial!) and increased management support and budgets, and also raised expectations! I must thank misters Humble and Farley in particular for cementing a usable meaning of continuous delivery and creating the excellent delivery/deployment pipeline pattern for orchestrating automation.
Q. Does doing continuous integration and/or having a delivery pipeline mean you are doing DevOps?
It helps a lot. But assuming (as every pipeline I’ve worked with so far) your pipeline doesn’t implement zero touch changes from check-in to production, Operations will still be prominent in software releases. And of course their involvement continues long after deployments and throughout live service. One development team’s automated deployment orchestrator might be one Operation team’s idea of malware! Automation alone will certainly not eliminate the tension caused by the opposing relationships to change.
The Point (Don’t Miss It)
Ok technology over, let’s talk directly about people as processes. The key point is that to globally optimise your organisation’s ability to deliver successful software changes, you have to think across both Development and Operations teams. -It’s even nearly in the name DevOps.
Development teams optimising software delivery processes in a silo (for example with Agile) will not help Operations team accommodate shorter release cycles Operations teams optimising risk assessment processes (for example wit ITIL) around “black box” software releases with which they have had little involvement will draw the only logical conclusion that changes should be further inhibited.
Operations teams optimising systems administration with server virtualisation and automated configuration management (e.g. Puppet) will not help development and testing productivity if they are not understood and adopted in earlier lifecycle stages by Development teams.
Development teams optimising code deployment processes with shiny automated deployment tools achieve diminished returns and in fact increased risk if the processes are not approved for use in Production.
There is no substitution for uniting over the common goal of improving release processes. Tools and automation are a lot of fun, but doing these in silos will not achieve what DevOps really promises. Collaboration is paramount, don’t miss the point!