Building DevOps
Born worlds apart, development and operations have typically had separate management, separate metrics and separate incentives. This is unsurprising when you consider the completely different goals of the two functions. Historically, developers were there to build functionality and the operations team were there to keep systems running reliably. I’ve witnessed many clashes between these two worlds, all of them unnecessary.
If you believe operations used to have tight control of deployment and now get to force developers to work their way, then you should be concerned. If you believe that developers used to be the underdogs and have finally fought their way to control of IT by getting operations to work their way, then you should worry. If you allow the polarized world of Kane and Abel to dominate your organisation you are doomed, just as they were in Archer’s sad novel.
User Sam: “The system is running slow”
Chris@Ops: “The server is running fine, it must be the software”
Alex@Dev: “I’ve not deployed anything new it must be the hardware”
User Sam: “I don’t care – just fix it!”
DevOps, as a method, is now about 5 years old and is building more support. Is it the answer? Does it make this all go away?
The short answer is Yes, but you have to build the A-Team.
Six key challenges
These are often your key challenges in implementing DevOps successfully:
- Everything 24x7
Globalisation and Internet based sales have driven everything to 24x7 availability, leaving technical teams working long hours and still get shouted at if they aren't there at 3am. - Zero downtime
Today, users expect zero downtime even for maintenance. Few development or operations teams have a history of solving this successfully. - Challenging business expectations
Users and management expect faster delivery with no mistakes and perfect reliability. - Complexity of IT
IT systems are more complex and more inter-dependent than ever making testing more challenging and fuelling the law of unintended consequences. - Developer background
Developers often come from backgrounds with no understanding of infrastructure. In the past applications have (typically) been developed for functionality, not for reliability. Only really ‘switched-on’ developers managed to do both. - Operations background
Operations teams haven’t had the transformational experience of 'agile operations' and are sceptical of the impact on performance and reliability.
One change to ensure success
Build a single team with all the skills you need, seat them together and manage them as a unit. One vision of success. One plan. One reward structure.
The team should have end-to-end ownership for defining, designing, implementing and running the systems the business needs. Just like the A-team, they need to feel confident and be challenged to win despite lack of resource and time. Why shoot people with real guns when you can build a bazooka from a pile of cabbages and some old tubing? (If you have no idea what I'm talking about watch this short clip)
I am not advocating “bodge IT and scarper”, I am applauding the A-Team’s agile and results driven approach to tight deadlines and using limited resources.
Chris@DevOps: “We’ve noticed the system looks slower than normal”
User Sam: “Now you mention it… it does seem slower than yesterday”
Chris@DevOps: “I’m checking the servers and Alex is rolling back yesterday’s deployment”
Alex@DevOps: “Yes, that will fix it now and give me time to run more test cases for a permanent fix”
User Sam: “Thanks folks!”
The DevOps philosophy is a great approach in many situations. It offers a utopia of more accurate requirements & designs, faster delivery and lower cost. However, in most organisations the cultural change needed won’t just happen by itself. It needs to be driven. Sure there are a bunch of organisational structure changes, process changes and new metrics that you should implement, but the single most important success factor is to win the hearts and minds to create an A-Team culture.