I recently attended DevOps Days in Santa Clara, a two-day conference/event focused on the DevOps culture and practices. Even though the conference is in its fourth year, you still get talks about what DevOps is and what it means. The term “DevOps” is relatively new movement in the software development industry. Patrick Debois, a sysadmin/developer, is credited with coining the term just a few years back. Because it is a newer concept in the development community the definition of it is still forming and coming into its own. What it really means is still discussed a lot and I’m going to add my own perspective now as well.
To get a better sense of DevOps evolution, I recently emailed Patrick and simply asked, “What did you see that inspired you to call it DevOps?” His response:
“…I was a sysadmin working a lot with agile dev teams and I was jealous of their way of working. This turned me into experimenting with Scrum and Kanban in operations teams. Then I got involved with agile infrastructure (as Andrew Shaefer called it). The first mailing list was ‘agile system administration,’ but for organizing the first conference that name was a bit long. Also, the fact that it only involved ops or sysadmins bothered me. Hence I came up with devopsdays (also a pun on dead on delivery – dod).”
“In hindsight, the name worked fine. The only thing that bothers me now, is that it is narrow when people first hear it, as my broader definition includes all company silos, also security, finance, HR, etc… but then again, it’s at the dev & ops barrier where most of the pressure builds up, so it works.”
Patrick was inspired by the way agile practices were positively affecting development and wanted to adopt them into operations. Another blog, devops.com, embraces that same idea with its tagline, “DevOps – Helping finish what Agile development started.” Thus, DevOps is fundamentally an extension of Agile into operations as it attempts to instill those values and practices into operations. At its core, Agile is about delivering value frequently so practices and technologies have been adopted in the DevOps discipline to support the rapid delivery of value. DevOps values high automation, managing infrastructure using development tools and languages (infrastructure as code), and such practices as continuous delivery.
Recently, however, broader definitions of DevOps have come onto the scene. Here is one I recently read in a Wired article covering an interview with Phoenix Project Co-Author Kevin Behr, “DevOps are really a group of folks engaged in developing critical thinking skills. Instead of viewing the world as optimizing what’s best for developers and optimizing what’s best for operations, DevOps see the world as a continuum and look at optimizing the whole system rather than sub-optimizing the parts at the expense of each other.”
What!? I like what the author is saying and I agree with the premise, but how would anyone get that out of the name “DevOps?” Whenever you say the word “DevOps” the name itself conjures up some combination of those two disciplines.s Even Patrick, the godfather of DevOps, states that he now has a “broader definition” which includes all company silos (groups), even security, finance, and HR! Hmmm, what should that be called? ManagementProductDevQASecurityFinanceHROps? Or, how about xOps? It’s just hard to make the mental leap from dev & ops to include all that other stuff!
In actuality, the broader definitions of DevOps that people are throwing around now really reflects what Lean is about and espouses. Lean values system thinking along with many other principles and practices attempt to “look at the whole.” All of that thinking is great for DevOps, but I suggest we keep the two ideas separate. DevOps can easily be integrated into an organization in which the Lean mindset exists. As a corollary, DevOps (and Agile for that matter) are effective catalysts for driving an organization into a Lean transformation.
Another clarification is in order: DevOps is not devs doing ops. It is true that a successful DevOps transform the way ops is done, but the development organization is fundamentally about building and servicing a product, while operations is about building and supporting the infrastructure for that product. Saying developers should do ops is like saying we should all be building roads or running the power company.
Some think of DevOps as dev [noun] + ops [noun], i.e. the dev and ops organizations working together and collaborating. It does embrace that notion, but DevOps goes deeper than that. Based on Patrick’s original notion of DevOps and my synthesis of ideas, I view DevOps as an adjective + noun combination, or Dev [adj.] + Ops [noun], meaning applying development principles and practices to operations.
So, what is DevOps for me? Applying the KISS principle (keep it simple, stupid) I get:
- applying agile/lean development practices and culture to the operations function (Scrum, Kanban, cross-functional teams, incremental and iterative, self-organization, etc.).
- applying the software engineering paradigm to operations (object-oriented programming, creating services, componentizing, and service oriented architecture).
- applying developer tools and practices to operations: source control, infrastructure as code, modern development languages, TDD, and continuous integration.
- creation of self-service tools and products which enhance product development and business productivity.
lastly, by applying these principles operations groups become more effective in that it transforms the nature of operations. In the DevOps model, operations groups become enablers to increased flow of value. They build the infrastructure and get out of the way!I think Patrick made a key point when he said, “it’s at the dev & ops barrier where most of the pressure builds up.” I wholeheartedly agree with that statement and find it extremely valuable to identify DevOps, representing the breaking down of that barrier, as a solution to that all-too-prevalent problem. So, Patrick, don’t lament your choice of DevOps! DevOps—applying development principles and practices to operations. If we keep the focus there DevOps will be more understandable, easier to sell, and far more successful fulfilling what it was created to solve.