What Is DevOps?

Patrick Debois coined the term DevOps in 2009. He took his inspiration from a presentation by John Allspaw titled 10+ Deploys Per Day: Dev and Ops Cooperation. 

From its start, DevOps has mixed the culture, practices, and tools that improve the teamwork required to deliver working software and infrastructure. DevOps can be explained as a cluster of patterns that align Development and Operation capabilities with business goals. In the end, DevOps recognizes that software only provides value if it’s running in production.

So, the fundamental question is… how do we efficiently get working software on production infrastructure in support of expressed business outcomes?

Since 2009, DevOps has gained practitioner acceptance and momentum. In March 2011, Cameron Haight, Research VP at Gartner, said, “By 2015, DevOps will evolve from a niche strategy employed by large cloud providers, into a mainstream strategy employed by 20% of Global 2000 organizations.”

In the yearly State of DevOps Report by Puppet and DORA, DevOps teams increased to 19% of respondents. In 2017, that percent grew to 27% of respondents. 

Grass roots DevOps is many times more common than Enterprise-focused programs. We call Enterprise programs, DevOps 2.0. At the grass roots, practitioners implement DevOps to improve their daily lives.

Most practitioners despise the mundane or the bureaucratic. To put this in context, developers may automate tasks they view as repetitive, distracting or of low value for them to complete. A good example of this is building source code. 

Automation triggers a source code build event as well as the additional tasks that should occur if the build is successful.  This type of DevOps pattern is called Continuous Integration. The automation allows the developer to focus more time on learning, analysis and feature development.  The practice of Continuous Integration can drive positive cultural change. Over time, culture makes it unacceptable for a developer to break the build. 

The developer’s behavior changes as they recognize that frequent code check-ins will keep their names out of the broken-build spotlight. Other patterns and practices can be integrated with a Continuous Integration pattern.  These may include unit testing, code review, instant messaging between groups based on pass or fail results, and information dashboards with key practice metrics. 

It’s important to remember that tools are not culture. Culture is a shared pattern of behavior and interaction that is learned. The statement; Culture eats DevOps for breakfast is quite true. In our Continuous Integration example, when build failures remain high over time, then cultural issues are at play. At that point leaders must lead and if incapable, leaders should be replaced.

DevOps is not in the business of propagating unreliable practices or culture. Astadia estimates that unplanned activities, re-work and low value tasks can account for as much as 65 percent of the Application Development Lifecycle budget. This is why DevOps is such a hot topic, and incredibly important for the Enterprise to get right.