No doubt, there are a bazillion new buzzwords every year in technology. I’ve not personally been as excited about one in a long time, though, as I am about DevOps, a long overdue blending and alliance between developers and cloud/network engineers/systems administrators, a multi-disciplinary community movement dedicated to the practice of designing, building, evolving and deploying rapidly-changing, high-performing and resilient systems at scale.

Many organizations are moving to make DevOps the clincher buzzword within their transformation presentations and strategies but, at the same time, there are always two sides to the same story, including skepticism around how major players in the industry are addressing challenges these moves present. For example, many confuse DevOps with NetOps or Continuous Delivery (CD) or Continuous Integration (CI) tools and cultures, each which deserve their own, separate post, simply to define and discuss their role in the overall technology operations process, their value and their delineation.

This post is focused on DevOps.

What is it?

It is a common misconception that DevOps is coming from the development side of the team to eliminate the relevance (and obstacle) of the operations teams. Quite the contrary, actually. DevOps, and its antecedents in agile operations, are being initiated out of operations teams far more often. This is because operations folks (I speak for myself here) have realized that, generally speaking, the existing technology operations principles, values, processes and practices have not kept pace with what’s needed for successful outcomes based on what is now possible. Things have changed and are continuing to change. As product and development teams need more agility as business paces pick up, many operations teams are guilty of providing less as they try to solve problems with more rigidity and as a result need a fundamental reimagining of what is possible in providing systems infrastructure in an effective, efficient and resilient manner. Not to mention, as processes and methodologies improve, who doesn’t want to stay relevant in the industry? Exciting times ahead!

History
The genesis of DevOps comes from an increasing need for innovation on the systems engineering side of building and delivering technology products and services, which is why it would make sense that the movement inherits traits from both the Agile System Administration movement and the Enterprise Systems Management (ESM) movement.

ESM, which arose in the mid-2000’s, provided the original impetus of “Hey, why is our methodology of running systems still so primitive? Let’s start talking about doing it better.” Where some of the initial ideas were far too complicated to be viable, adding additional complexity rather than simplicity, some saw the need to simplify and make these processes more focused on people rather than process and tools.

Initially, enchantment with ITIL as a governance framework was largely overthrown for the “ITIL Lite” Visible Ops approach, as well as a shift from being so enterprise focused. Makes sense, as the way it used to be was that only big players like HP and IBM had any solutions for end-to-end systems management. Besides, being cost-prohibitive, complex and kludgy (meaning not friendly for administrators to use), more open source and smaller vendor solutions emerged, like Spiceworks, Hyperic and Zenoss, among others.

Then, in 2008, the first Velocity conference was held by O’Reilly. Web performance and operations were the focus, which provided one of the very first venues for teams to begin sharing insights around technology operations cultures, specifically about what was working and what wasn’t.

In 2009 and 2010, more and more presentations emerged about how developers and operations teams were beginning to collaborate successfully, at least at some of the enterprise-sized shops and how that helped promote fast, yet predictable, change in web environments. Provisioning tools like Puppet, which emerged in 2005, and Chef, shortly after, had strong showings there. More people began to think about the prospect of these concepts and wonder how they might implement them into their production cultures.

Meanwhile, as agile’s growth in the development space was reaching its most fevered pitch and beginning to become common practice, this turned into thinking about “Agile Systems Administration.” Especially in Europe, where the focus was on process, and the analogies from kanban applied to lean manufacturing processes were presented in comparison to IT systems administration.

During this same time, Patrick Debois from Belgium and Andrew Clay Shafer from the US connected and coined the term DevOps. Then, Patrick held the first DevOpsDays event in Ghent that blew it all up – big time. In Patrick’s view, DevOps emerged as pushback against cultural obstacles, such as silos, rigidity and inefficiency, that were resulting from existing “best practices”in the field. There were other major efforts that brought it to life, including those of John Willis, Jez Humble and Gene Kim, who collectively wrote the definitive book on the subject: The DevOps Handbook: How to Create World Class Agility, Reliability and Security in Technology Organizations.

Now that DevOps had a name and a framework, it started to be talked about elsewhere as a legitimate practice here in the US, too. Alex Honor wrote a nice piece back in 2010 that resonated, focusing on People over Process over Tools. There are many to choose from. Google it!

DevOps emerged from a “perfect storm” of these things coming together: the growing automation and toolchain approach fed by more good monitoring and provisioning tools, the need for agile processes and dev/ops collaboration along with the failure of big/heavy implementations of ITSM/ITIL – they collided and unconsciously brought together all three layers of what you need for the agile movement (principles, process, and practices) and caught fire. Since then it has developed further, most notably by the inclusion of Lean principles by many of the thought leaders.

Defining DevOps

Defining DevOps rigidly is an agreeably elusive task because it means different things to different people and working cultures. Discussions around it range from “developer and operations collaboration,” to “treating code as infrastructure,” to “all about automation,” to “all about kanban,” to “strictly cultural,” along with a variety of seemingly related conversations about tools and strategies that empower various disciplines committed to the same goal (product and service delivery) to work together better.

Like Agile, DevOps is not easy to define. But it’s worth doing within each culture committed to making it a part of how things are done. Left at a purely philosophical level, both can become abstractions and suffer from lack of support or buy-in. To build a successful Agile or DevOps culture is to understand all the layers of complexity involved in the current culture and how a specific design of DevOps implementation may or may not add value. DevOps should bring to Agile better understanding and wholistic practice that software isn’t done until it’s successfully delivered to a user astride infrastructure that is highly-available, high-performaing, resilient and as future-proof as it can be.

One way to help is taking a look at how Agile Development is defined. Agile Development generally includes four considerations. If we add one for tools, that makes five:

Values
The values are clearly defined in the Agile Manifesto.

These are the core values and look like this:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Principles
The Agile Manifesto cites twelve agreed upon principles to support these values. If you’re calling what you do an “Agile culture”, but you’re not following many or most of these, you’re probably not really Agile.

Methods
Specific process implementations of these agreed upon principles, such as Extreme Programming (XP), Scrum, Dual-Track Scrum and/or processes unique to your own culture. Custom playbooks can override strict philosophical considerations within the team, based on operational needs of how things are done in real life. These are only possible implementations more than mandates.

Practices
Specific and tactical approaches and techniques aren’t so much required to be Agile but there certainly is value in adopting them. Standups, for example, are key and more or less essential. Others, such as planning poker, backlogs, continuous integration and other culture-specific components are parts of the whole that make teams function as more of a whole, yet are interchangeable and not requirements.

Tools
Specifics. Methods and tools that help teams accomplish their work. JIRA Agile and Capture, for example, or Google Sheets, or Slack or a combination of things that work well for the culture. It’s important these are well defined for many reasons, least of which is not clarity and simplicity so the team is united in how they approach, gather, synthesize and hold discourse on information about a product or service they are designing and building.

Ideally, these decisions would be made by the team as a collective, rather than by higher-ups who may or may not have fluency regarding the value of each tool and how quickly adding tools adds complexity and overhead to processes and the overall value of them.

—

Now, let’s apply a similar approach to DevOps:

Values
We might be able to agree the Agile Manifesto outlines the same values required by DevOps with perhaps one small modification related to the service or software being fully and more or less optimally delivered in a quality state, as opposed to simply “working software.” There are also existing definitions of DevOps, like Alex Honor’s “People over Process over Tools,” which reiterates Agile Manifesto statements through the lens of DevOps collaboration, which values people first, process second and tools (automation) last. This is a unique approach among technical people, who generally tend to start to imagine solutions to challenges from a tool-oriented perspective.

Principles
While there are no concrete or agreed-upon lists, we can generally subscribe to Patrick DeBois‘ eloquent proposition that inspired others to follow, such as John Willis and Jez Humble to coin “CALMS”, which stands for:

• Culture
• Automation
• Lean
• Measurement
• Sharing

“Infrastructure as code” is a commonly cited principle worth mentioning. As already stated, broadening Agile’s principles to include systems and operations instead of stopping at code checkin is a pretty good framework for most any culture.

Methods
Methods are much the same, too. We can use Scrum for operations, kanban with operations, although with more focus on integrating operations into dev, QA, and product on the product teams. There are some more distinct methods, like Visible Ops-style change control and using the Incident Command System for incident reponse. The set of these methodologies are growing; a more thoughtful approach to monitoring is an area where common methodologies haven’t been well defined, for example.

Practices
Specific techniques used as part of implementing the above concepts and processes. Continuous integration and continuous deployment, “Give your developers a pager and put them on call,” using configuration management, metrics and monitoring schemes, a toolchain approach to tooling… Even using virtualization and cloud computing is a common practice used to accelerate change in the modern infrastructure world.

Tools
Tools you’d use in the commission of these principles. In the DevOps world there’s been an explosion of tools in release (jenkins, travis, teamcity), configuration management (puppet, chef, ansible, cfengine), orchestration (zookeeper, noah, mesos), monitoring and virtualization (AWS, OpenStack, vagrant) and many more to come, no doubt. While, as with Agile, it’s incorrect to say a tool is “a DevOps tool” in the sense that it will magically bring you DevOps, there are certainly specific tools being developed with the express goal of facilitating the above principles, methods, and practices, and a holistic understanding of DevOps should integrate these.

—

Where to begin
There isn’t a right way to implement DevOps into your culture. Like so many other anthropological considerations, there’s only what works in your specific organizational culture. It starts with learning about the values, principles, methods and practices of DevOps and collaborating closely with leadership in ways other popular things in your organization have arisen and gained currency and try those same channels. And –> always keep learning.

Think holistic, not only across IT. Transformation isn’t only about IT but the entire organization’s value stream from marketing to sales to development to operations. How can the team fire on all 16 cylinders most of the time?

Moving on to the Future

While we might agree that some parts of operations need to be automated, that means there are some decisions to be made:

1. Do operations teams engage in automation development, or
2. Do developers engage in writing “operations” code, or
3. Both?

While these propositions might sound scary to some, it is part of the value of the overall collaborative approach. Each of the successful teams I’ve led using this approach have added value to both kinds of people: those with deep development skill sets work better beside those with deep operations skill sets and together create a better overall product delivery process, while broadening the team’s value as learners and contributors that each play a role is shaping the organization’s culture. Buy-in is valued more than salary and other incentives, too, which helps retain talent and grow a team that has chemistry and respect for the work they do and each contributor’s role in it.

I have yet to see anyone automate themselves out of a job in pursuing this cultural shift. It is counter-inuitive, actually. The team is required to make strategic decisions about working with leadership to shape the overall culture. As lower level concerns, the tactical stuff, becomes more automated, teams collectively start thinking more strategically, moving higher value problems up on their lists of challenges to solve. That is a valuable shift in the way everyone works, how they achieve satisfaction, the collective’s capacity to deliver great products and services and all of this is long, long, long overdue.