I Dream of DevOps, but What is DevOps?

This Calm.io blog recap was originally written and posted by me on September 23, 2015 at http://calm.io/2015/09/23/i-dream-of-devops-but-what-is-devops/, and slightly enhanced on February 18, 2018, be sure to see the Postscript for significant developments!

Let me share what I’ve learned on my journey to DevOps: it is a culturally rendered term and it has a different meaning for everyone. My definition has stood for years with slight reductions and I have arrived at:

DevOps is the process of removing friction between the developer and customer value.

Over the years, the more words I removed from my DevOps definition, the closer it encompassed all of the nuances I had experienced. DevOps could be called an art, practice, movement, or value system and I think all apply. I am happy to contribute my understanding to advance our community.

Working backwards to expand on the terms used for my DevOps definition:

• Value: typically, the products and services customers use,
  • e.g.: software or web site.
• Customer: a value consumer,
  • e.g.: target audience or end-user (internal or exteral).
• Developer: value creator and contributor.
• Friction: anything that blocks, slows, diminishes, or reduces value delivery,
  • e.g.: manual hand-offs, separation of duties, silos of responsibility, or isolation from the entire value system.
• Process: the methodology to accomplish work.

Putting all of the above together implies that DevOps is a dynamic system which expands or shrinks to the capacity of the people who practice it. This is what makes a universal, static DevOps definition so hard to create while also giving the DevOps movement increasing power: it is a process that will change and grow over time as we pursue the state of the art!

The term DevOps is about six years old 1, it represents an approach to span the traditional organizational gaps to measure and deliver value to customers. When we realize customers are both internal and external, any portion of the entire value chain can be examined and improved. By measuring customer impact, we can observe bi-directional value flow and identify or create feedback loops to drive improvements. DevOps works to remove division of responsibility and to enable collaboration and automation, thereby achieving both agility and scalability for any organization.

Benefits of DevOps

DevOps value is immediately realized in engineering organizations and will grow to encompass more in the future. Traditional engineering team silos and tools allow counter-productive practices to exist.

For example, every utterance of these phrases:

• “It worked on my laptop.”
• “That’s not my problem!”
• “I don’t do that, somebody else does."

… are cultural indicators that a DevOps approach is needed. The DevOps goal to remove friction will identify cultural and technical debt, artificial separation of responsibilities, and barriers to automation in the organization.

The relentless pursuit of DevOps results in tangible and essential benefits for improving customer value:

• Rapid release: automated testing and release of product all the way from the developer source code check-in to the customer in production.
• Fail fast and fix fast: understanding the health and business impact of a release for customer interactions allows automated deployment (and revert) strategies to reduce risk while increasing tempo.
• Close loop design and testing: every change is an opportunity to learn and experiment, every gap or mistake an opportunity to improve testing, instrumentation, and automation. Automated operations allows monitoring systems to trigger healing.
• Democratized access and self-service: full service, ephemeral environments and stacks exercising the entire value chain can be created ad hoc by developers, testers, operations or build and test systems.

Agility and scalability of infrastructure, architecture, operations, and culture via governance and best practices are the key accomplishments of the DevOps process.

Opportunity for Cultural Disruption

When a term represents a cultural shift, a knowledge rift can occur between the have and have nots. It may be easier to define what DevOps is not so that you can assert what DevOps is for your journey. Human nature and confusion fill gaps in understanding DevOps, so we can see religious and political motifs appear in fervor, fundamentalism, rebellion, gorilla warfare, skunk work projects, martyrdom, and staunch conservatism both for and against DevOps.

How can such emotional turmoil exist in an engineering and IT organizations, by people who are employed for their rational and technical skills? These are all good questions to start with:

• What is, why do I want, and how do I get DevOps?
• Who authorized DevOps?
• You can’t get DevOps certification, so how can this be a legitimate thing?

DevOps needs to be discussed, goals set, and an approach must be defined. But any cultural initiative or large project requires a stake holder who must identify the need for DevOps, champion the cause, and sponsor the resources to explore, implement, and measure DevOps success in a top-down fashion. Smaller organizations can forego most of that structure by allowing a bottoms-up approach to experiment and adopt DevOps benefits.

Fortunately, the DevOps community is decentralized and welcoming: new adopters should seek out the nearest DevOpsDays, DevOps Meetup groups, and related conferences to find local practitioners. By doing so, you can drink directly from the fountain of knowledge and profit from the experience of your community.

DevOps Best Practices

While the field of DevOps is evolving rapidly, we have crystallized many practices into these topics which enable automation, collaboration, and closed loop feedback:

• Infrastructure as Code: configuration management tools to make infrastructure reproducible.
• Continuous Integration, Delivery, and Deployment: insures all contributed code can build, test, and deploy together.
• Immutable Infrastructure: allows simplicity and consistency in deployment.
• Microservices and Containers: communication patterns and application packaging enables architectural and deployment benefits.
• Instrumentation: allows understanding of the micro and macro trends, forensics, and health of systems.

I will explore these topics in future blog posts, some are already linked, above.

Beware Exploitation!

Because we do not have a universal, citable definition of DevOps1, abuse of the term is rampant. Search on DevOps and you will find the advertisements of everyone extending everything to add DevOps as a buzzword. Ask yourself: “Does it meet our DevOps definition?” then you may ask, “Why is DevOps So Hard?”

About the Author

Mark Lavi is Calm’s Technology Evangelist, see his brief biography.

Postscript February 18, 2018: DevOps Definition

1In The DevOps Handbook by Gene Kim, Jez Humble, Jon Willis, and Patrick Dubois published by IT Revolution in 2017, the authors lay out a DevOps definition! Since Patrick (the co-author) and Andrew Schaefer created the term DevOps in 2009, this is as close as we can get to an official definition.

From page 4:

DevOps is the outcome of applying the most trusted principles from the domain of physical manufacturing and leadership to the IT value stream.

While I believe my definition is sufficiently abstract and succinct, I think the definitions are complimentary! This article was written years before the DevOps Handbook was published.

In August, 2016 Nutanix acquired my employer, Calm.io. I constantly struggled to succinctly explain the benefits of DevOps to my new colleagues, because my “elevator pitch” failed more often than succeeded in under a minute. After nearly a year of working with my Nutanix colleagues, partners, and customers, learning and experiencing the Nutanix platform benefits, I arrived at the DevOps Maturity Diagram and it accomplishes more in less time than my best elevator pitch!