DevOps is a Strategy

What is DevOps strategy?

There are dozens of definitions, of course, but sometimes you need to go beyond definitions and look at how people really use a word. What do people in the industry really mean when they talk about DevOps? Is it simply a way of moving developers into operations, of making them full participants in the operations team and in management of infrastructure?

If you look at DevOps that way, you'll have plenty of company, and you won't really be wrong. Functionally, operations and the demands of infrastructure are the main drivers of DevOps. DevOps brings development into the operations tent and applies development practices to infrastructure, but it doesn't move operations out of the tent.

DevOps strategy is more than a framework

But DevOps is far more than just a functional framework. If that's all it were, both its supporters and its critics would treat it as a package of technical and temporary fixes for slow and inefficient development/release cycles, and not much else. While technical remedies are part of DevOps, and improving the speed and efficiency of the the development/release cycle is one of its major goals, a definition based strictly on those factors hardly seems adequate. Just a glance at the online discussion of DevOps would be enough to convince even a casual observer that there is far more to the subject.

In fact, the specific tools and practices which are currently associated with DevOps are largely incidental, and not intrinsic to it. Some scripting languages may be superior to others, but in a pinch, most (and maybe any) of them will be adequate. Virtualization and containerization matter, but the methods used to wrap an application and insulate it from its environment may not really be that important in the long run. The only thing that you can really count on is that today's tools are likely to be obsolete in a few years.

DevOps strategy is more than tools and practices

So what is DevOps, if it isn't a clearly defined set of tools or practices? Is it anything at all, besides a grab-bag collection of contemporary software management products and catchphrases?

Yes, it is; above all else, DevOps is a strategy. More accurately, it is a strategic framework for transforming both development and operations into something new and not yet entirely defined. This can be translated into branching, implementation, testing, deployment, and other strategies. Basic to this transformation is the fundamental redefinition not only of development and operations, but of their underlying context. What are we developing, and what are we operating, and for what base of users? If today we are producing a stream of services aimed at a mass-market user base, can we afford to define what we are doing in terms more appropriate to an era when software consisted of clearly-defined packages running on corporate networks, and when waterfall development was an adequate methodology?

In many ways, the basic problem that gave rise to DevOps is the mere fact that software development has a history. Like any other human institution or endeavor, its history has become a kind of cage, trapping it in the definitions, categories, and practices of the past. So much that we take for granted -- from the names and formats of low-level code commands to the institutional environments in which development and operations are embedded -- are artifacts of that history, and not fundamental to the practice of producing, deploying, and maintaining software.

If a group of intelligent people with access to current hardware and basic programming tools, but with absolutely no knowledge of software history or of past or current development and operations practices, were to devise a set of tools and practices for creating, deploying, and maintaining web-based services, what would they come up with? Would they define what they were doing or producing in terms and categories that bore any relation at all to those which exist now?

DevOps Strategy

DevOps can be seen as a strategic framework for finding answers to these questions without actually resorting to Ren and Stimpy's History Eraser button. It starts by redefining the basic task at hand as "providing a stream of web-based services to the general public," as opposed to the more traditional "developing computer/network-based applications for a set of end-users, with both the applications and end-users defined by a set of functional requirements." Theoretically, everything else in DevOps could flow from that redefinition. 

DevOps Strategy Definition: In practice, DevOps is a strategy for discovering and implementing the practices that naturally arise from the "stream of web-based services" approach.

As a strategy, its focus is necessarily going to be on people even more than it is on tools or methods, because it is people who actually carry out strategies; a hammer is a good tool, but the hand that holds the hammer is what determines where and when it is used. The core of the DevOps strategy must be to form a single team in which members take on a variety of roles, depending on what needs to be done. Developers who write infrastructure code should ideally not feel as if they are crossing some kind of boundary or temporarily working in "the other silo", but rather as if they are working as part of an integrated team. IT staff should see deployment as part of the continuous stream that includes development and testing.

And as a strategy, DevOps' use of tools and methods is necessarily going to be focused on two goals: supporting continuous release and the associated processes, and making it possible for team members to do their jobs in a manner that is as efficient and painless as possible.

How do you develop a DevOps strategy?

As mentioned, DevOps strategies focus more on people and communication than they do on tools, best practices, and frameworks. Here are best practices for developing a DevOps strategy.

1. Develop a culture that supports DevOps and collaboration
2. Get leadership buy-in
3. Develop trust within departments and across them
4. Define and control responsibilities, permissions, and more
5. Embrace a DevOps mindset that supports results rather than compliance
6. Define, set, and develop a metrics driven culture
7. Understand the unique needs within the organization and across departments

DevOps strategies are not end-products, and they are not mature, stable processes. They are by nature interim solutions on the way to the next plateau of semi-stability (because in the software industry, there is no true stability). DevOps is no different; it is a strategy for developing what will become the mature and universally recognized process for managing continuous delivery, but it is not that process, because we have not yet arrived at the plateau where continuous delivery will be as ubiquitous, as stable (and as boring) as waterfall once was. DevOps is the journey, and not the destination.