Why do DevOps?
According to the Puppet’s 2016 State of DevOps Report DevOps is no longer a mere fad or buzz word but an understood set of practices and cultural patterns.
DevOps was originally coined by Patrick Debois and Andrew Shafer in 2008. The velocity conference community made DevOps a known term with the famous 10+ deploys per day: Dev and Ops cooperation at Flickr in 2009.
What is DevOps?:
Daniel Greene in techcrunch defines DevOps as a set of practices, tool and policies that lead to improved quality and automated delivery. But I really like Gene Kim’s definition in his book the phoenix project where he refers to DevOps as the outcome of applying Lean principles to the IT value stream. These principles are age old but are now used to accelerate flow of work in software development through product management, development, test, operations and Information Security. Adapting lean principles and shift left, Toyota’s mantra is to stop and fix quality issues before they manifest at the end and also deliver just in time parts and support.
Source: Toyota website
Imagine applying these principles to a software development lifecycle and while coding and running automated testing, checking for known vulnerabilities, testing for security, continuously integrating code and deploying several times a day in various environments including production. This is shifting left the activities that were performed at the very end, which caused problems to be discovered late and teams could never build in quality. This lead to developers spending less time reworking their code while Ops spending time in late nights and weekends to deploy code into production. In fact according to the phoenix project, DevOps has benefited from an astounding convergence of philosophical movements such as Lean Startup, Innovation Culture, Toyota Kata, Rugged Computing and the Velocity community.
What do the development and operations typically see?:
|What Operations sees?||What development sees?|
|Fragile applications are prone to failure||More urgent, date-driven projects put into the queue|
|Long time required to figure out “which bit got flipped”||Even more fragile code put into production|
|Detective control is a salesperson||More releases have increasingly “turbulent installs”|
|Too much time required to restore service||Release cycles lengthen to amortize “cost of deployments”|
|Too much firefighting and unplanned work||Failing bigger deployments more difficult to diagnose|
|Planned project work cannot complete||Most senior and constrained IT ops resources have less time to fix underlying process problems|
|Frustrated customers leave||Ever increasing backlog of infrastructure projects that could fix root cause and reduce costs|
|Market share goes down||Ever increasing amount of tension between IT Ops and Development|
The above leads to a mindset that eventually breeds mistrust and a not so healthy competition between these teams.
Lets see how DevOps changes this:
Looking at some statistics of companies showed high performers delivered on faster time to market, increased customer satisfaction and market share, team and employee productivity and happiness as well as allowing organizations to win in the marketplace.
Amazon in 2011 deployed code every 11.6 seconds, Netflix several times a day and Google several time a week. Gary Gruver’s description of their transformation of HP’s laserjet division where 400 people distributed across 300 continents is able to integrate around 150 changes or 100,000 lines of code into the trunk on their 10m lines of code base every day.
We know our quality within 24 hours of any fix going into the system and we can broadly test for even last minute fixes to ensure that a bug fix does not cause unexpected failures
Check out Guy Gruver’s talk in 2013 on how they did it.
DevOps transformation at scale is hard and needs changes in both organization and technology bringing together teams that have been in the past operated separately and introduces innovation that automates end to end software development pipeline.