The elusiveness of DevOps

 An interview with John Arundel, originally published on the ActiveState blog.

The Elusiveness of DevOps

At ActiveState, we have always been focused on software developers, especially those that use dynamic languages such as Perl, Python, Ruby, and Tcl. The past few years building Stackato, our private Platform-as-a-Service (PaaS), has led us to deal more with IT departments, while maintaining a close relationship with developers.

We are seeing a common pattern. Those people who really get PaaS bridge the gap between development and IT. They care deeply about the whole system of creating code, deploying it, and scaling it. This mindset is often referred to as "DevOps."

Software development is a creation, and IT is the deployment and distribution of that creation. These have historically been seen as separate roles. However treating these work centres as silos can lead to problems. Instead of a simple production line, where department A passes completed work onto department B who then passes it onto department C, it is considered better practice to look at these things as a whole system, with strong feedback loops between departments, so that work can move through the system efficiently.

A simple example of a feedback loop would be: "Does it fail in production?" The earlier, quicker, and low-cost way that the software development team can get this answer from IT, then the quicker the developers can take action on it. Otherwise, the compound interest that this production-unfriendly code generates will cause show-stopping issues when the application finally reaches IT for deployment.

In this simple example, the solution could be this: The IT department agrees that if its staff can give the development team a quick answer on whether the code is production-ready at any time during the development process, then the development team will always give them production-ready code. Optimally this is done with automated QA and deployment tests that run each time a developer commits new code. The fact that the code will scale in production is something that should be known on day one of development, not after development has handed the software to IT.

This example only covers a small portion of the kind of solutions that a DevOps person might implement. DevOps is more than inter-departmental hugging, feedback loops, and automated testing. To get a succinct definition, I asked John Arundel, from Bitfield Consulting, what his definition of DevOps is.

A Definition of DevOps

John knows his DevOps, is well respected in the community, and writes about it in his blog. He also champions Puppet, which is used for IT automation. He's actually written two books on Puppet: The Puppet Cookbook and The Puppet Beginner’s Guide.

I ask John to limit his definition to just a few words, and this is how he defined DevOps: 

"Devops is like obscenity: you know it when you see it. It's an attitude, a set of priorities, a mutual understanding. It's also (still) extremely rare."

That is short enough that it's tweetable, but let's break it down...

You Know It When You See It

The "obscenity: you know it when you see it" is adapted from one of the most famous quotes from the Supreme Court of the United States.

"I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description ["hard-core pornography"]; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the motion picture involved in this case is not that."

(Justice Potter Stewart, concurring opinion in Jacobellis v. Ohio 378 U.S. 184 (1964), regarding possible obscenity in The Lovers)

Maybe it is because DevOps is rare that it is not well defined.It is also possibly due to the complexity of IT operations, software development, and the relation between the two.

DevOps is about solving problems, getting things done, working smarter, and not necessarily harder. Where are the pain points, the bottlenecks, the recurring issues? Since "solving any problems that come up" is just part of DevOps and the definition of that problem is vague, it's hard to understand exactly which tasks are needed to be performed. Although, as John states, when someone is doing that thing and you see them deeply involved with both the Development team and the IT department, then you know that what you are seeing is DevOps.

An Attitude

In order to think out of the box, across departmental boundaries, and with a continuous sense of "there is still a better way to do this", a DevOps person needs a certain type of attitude.

Openness to new ideas is one, but openness to new developer communities is another. Just as a DevOps person holds his or her arms out open to all departments, breaking down walls, building alliances, listening to all sides of the problem, and seeking consensus on solutions, a great DevOps will also do this outside of the organization.

This is why DevOps is not necessarily something that enterprises need to advertise and hire for. In fact, it might not be a specific person at all. In many ways, it is a process that can be embedded within and across the enterprise's departments, and it can reach even beyond just IT and development.

A Set of Priorities

When your house is on fire, where do you throw the water first? Do you even need the house?

As mentioned above, a DevOps person will bridge the gap between the Development team and the IT department, but the entrepreneurial qualities that DevOps person brings to an organization often have a much further reach.

Priorities are often at the business level. How important is it that updates get pushed out quickly? Is downtime an option? How will the customers perceive the enterprise? What is the business impact of not pushing this security fix in the next 24 hours? How will this affect the financial department and the enterprise's revenue for this quarter? Is the enterprise building for the short-term or the long-term?

A DevOps person does not need to have the answers to all these questions, but the attitude and openness a DevOps person has towards the whole company enables these questions to surface and be part of the discussion.

A Mutual Understanding

Communication is a two-way street. For DevOps to work, the IT department should better understand what Development needs to move things quickly to testing and to production. But for the feedback loop to close, Development also needs to equally understand what IT require. Systems should be created to make this feedback loop as efficient as possible. Again, this goes beyond these two departments.

(Still) Extremely Rare

John stated that DevOps is extremely rare, still. Is this because DevOps involves a cultural change within large organizations? The Phoenix Project clearly demonstrates that it sometimes takes an organization to be on its knees before a significant shake-up can happen and there is enough of a pause to say "hey, what are we actually doing here?"

Conclusion

Every organization is different. Some will say "DevOps" makes no sense to their organization, but if the definition is as elusive as DevOps itself, then it is likely that the meaning has been lost on some people. For me, DevOps is about improvement that crosses departmental boundaries and brings efficiency to workflow.

What is your definition of DevOps?

You can find both Phil Whelan @philwhln and John Arundel @bitfield on Twitter.