DevOps: A Way of Cooperative Production

Symbiosis between clownfish and anemone

"DevOps is a human problem." -- Patrick Debois

During the 1980s and 1990s, a number of trends in software development such as Rapid-Application Development, Scrum, and Extreme Programming, led to the Agile Manifesto, a summary of the lessons learned from applying these various practices over many years. Meanwhile, similar ideas, moving over from the world of manufacturing, in particular, from the Toyota Production System, coalesced into Lean Programming, which shared so many features with Agile that they can essentially be considered variants on a theme. (If we want to be good historians of software engineering practice, we must note that these ideas have earlier antecedents, particularly to be found in the group of brilliant engineers who worked at Bell Labs in the 1960s and 1970s, and who pioneered the notion of incremental development of small tools that could be easily combined into larger systems as the need arose, an idea at the heart of the UNIX operating system.)

Producing the Toyoda automated loom

These trends, along with the increasing viability of the Web as an application delivery platform, gave rise to development groups that could deliver new software to customers at an unprecedented pace. But this pace strained the capabilities of many operations teams: operations had traditionally acted as a regulator stopping buggy, insecure software from reaching production boxes. This job often delayed new software from reaching production for a number of months. When development cycles for new releases were measured in years, adding a few months to the release date was relatively unproblematic. But once development teams were ready to release new software much more frequently, often daily, adding a couple of month delay to a one-day release cycle no longer seemed acceptable.

Thus, operations, if it was not to be the fly in the ointment, had to become lean and agile itself. Practitioners realized that this required a new approach to operations: operations had to work together with development from the very start of a project, to ensure that new software, at every step along its development path, was always "production ready." This close collaboration between development and operations was christened with a name in 2008: in a talk on "Agile Infrastructure," Andrew Shafer and Patrick Debois coined the term "DevOps."

So DevOps can be seen as an extension of Lean and Agile ideas into the realm of deploying software into production and monitoring and fixing it once it has been deployed. In order to accomodate the pace of release achieved by Lean/Agile developers, operations teams realized that operations had to shift from a way of working where they were an after-the-fact check on the work of developers to one in which they were involved in the development process from day one: operations has to swiftly provide developers with production-like environments in which to work (infra-structure as code), to enable quality assurance at every step of the development process (continuous, automated testing), to enable swift rollbacks when errors do appear in production (version control systems), and to constantly track the performance of these frequently released systems (automated monitoring).

New developments in DevOps have extended this notion of continual cooperation into the realms of security (Rugged DevOps), compliance, and even finance.

Perhaps the most important aspect of the DevOps movement, however, is the idea of continuous learning: by speeding up the pace at which software is released by orders of magnitude (Amazon releases new code into production at an average pace of one release every 11 seconds), DevOps can enable organizations to learn much more swiftly, since it is by actually using new features that the customers can best provide feedback as to what is really helping them in their jobs, what is irrelevant, and what is positively harmful. Until a feature is actually being used by the customer, it is merely specualtion as to how important it is: once the customer can use it, they will let us know!


More on This Topic