In the tech industry it has been long accepted that Developers and IT/Ops professionals within the same organisation have separate key performance indicators by which they are judged. This has resulted in a “complicated” relationship between Development and Operations; team silos are created as the two departments are not working together, leading to disconnect within an organisation and often unhappy customers. The complication arises as the development side of processes is moving at a much faster rate than the operations team creating a bottleneck.
DevOps is the attempt to harmonise the split between developers and operators, and to improve business performance. There are a few divergent ideas on how exactly DevOps came about, but credit is given to both Andrew Clay Shafer and Patrick Dubois. In 2008, Shafer organised a group discussion titled “Agile Infrastructure”. Only one person attended this group discussion, interestingly it was not Shafer, but Patrick Dubois. Dubois’ grievance was with the pervasive strife between developers and operators while working on a data centre migration for the Belgium government. He realised that specific views such as the constant switching back and forth by the development side and the existence of silos on the operational side was gravely time consuming and a hindrance to any project. He was in desperate search of a solution. Dubois later tracked down Shafer in the hallway, where their conversation inspired the formation of a Google group “Agile Systems Administration”.
The following year, although Shafer coined the term DevOps in a tweet, Dubois organised the first DevOps conference in Belgium. Soon after the first use of #DevOps there was an increased rapid adoption of cloud technology. Cloud technology is a fast advancing technology, aligning well with DevOps applications. Its characteristics confer elasticity and scaling, automation, measurement and repeatability, which is rudimentary in DevOps.
There was a movement. There was a surge in businesses opting to improve software deployments within their organisations; opting for small, recurring and low risk deployments. In 2010, Jez Harley and Dave Farley wrote a definitive text on “Continuous Delivery”, which was a detailed description on how to automate a build, deployment and testing pipeline so that release changes could be made within minutes and hours, in comparison to the weeks and months it was taking before. Automation technology tools progressed as cloud technology became more mainstream.
Gene Kim, Kevin Behr and George Spafford, wrote a novel called the “The Phoenix Project” in 2012. This novel was widely referred to as the DevOps “bible”, illustrating the importance of organisations prioritising security and removing the silos that have traditionally existed between development and operations teams. The Phoenix Project, focused on practical ways to improve performance of an IT company such as effective change control, effective testing, reducing WIP and unplanned work, and avoiding letting anyone become the bottleneck for processes. The Phoenix project also initiates one of the first attempts to codify DevOps by centring on flow, feedback loops and continuous improvement. These three steps was the basis for the subsequent book released in 2016 that goes deeper into the applications of these steps, titled “The DevOps Handbook”. This book demonstrates what should be important to businesses and implementation of technical processes such as Continuous Integration and Continuous Delivery. The DevOps Handbook also showed the presence of another problematic silo; security. It was realised that security should be built into code as it is developed rather than added later on by a different team. This idea became known as DevSecOps.
Putting into practice what DevOps is about, in 2012, Puppet began surveying people working in technology to understand the adoption and development of DevOps practices and published in “State of DevOps” reports. The writing of these reports has now been taken over by DORA (DevOps Research and Assessment) and is being improved annually. These reports have built deep and a wide reference body of DevOps research available (Alanna Brown, Puppet).
One of the founders of DORA, Nicole Forsgren, wrote an enlightening book “Accelerate” explaining which metrics correspond to organisational production, and what should be measured in order to decipher where and how to improve.
The scope of DevOps has potential to broaden, and is continuously evolving and improving.
