For the purposes of this article, we propose the following definition:
DevOps is the streamlining of the activities surrounding IT solution development (dev) and IT operations (ops).
In organizations that have not yet adopted a DevOps mindset we say that there is a “DevOps gap”, as we depict in Figure 1 below, between solution delivery teams and IT operations. This gap results in lengthy solution deployments and hence higher costs to deploy; a long mean time between deployments (MTBD) which is often measured in terms of months; reduced market competitiveness; and reduced ability to govern your IT efforts due to lack of real-time intelligence.
Figure 1. The DevOps gap
When organizations address these challenges by removing the barriers that inhibit effective collaboration, they close the DevOps gap. A common depiction of this strategy, sometimes called the “DevOps loop” is shown in Figure 2. Organizations do this by: adopting a mindset that promotes collaborative; learning-centric ways of working that are supported by agile practices; and very often investing significantly in automation. On the development side they tend to adopt a continuous delivery (CD) approach and their operations efforts become streamlined and more automated.
Figure 2. A closed DevOps gap
1 Defining Disciplined DevOps
What does it mean to take a disciplined approach to DevOps? It requires discipline to do the things that are good for you that you may not normally choose to do. Given this, we propose the following definition:
Disciplined DevOps is the streamlining of IT solution development and IT operations activities, along with supporting enterprise-IT activities such as Security and Data Management, to provide more effective outcomes to an organization.
2 Why is it Difficult to Come to a Common Definition of DevOps?
- Specialized IT practitioners. Many IT professionals still tend to specialize — someone will choose to focus on being a programmer, an operations engineer, an enterprise architect, a database administrator (DBA) and so on. As a result they tend to see the world through the lens of their specialty. Programmers will focus on the software development aspects of DevOps, operations engineers the operations aspects of DevOps, enterprise architects on the long-term planning and modelling aspects, and DBAs on the data management aspects. Few people are looking at the overall “big picture.”
- Agilists are focused on continuous delivery. Right now agile and lean developers are investing a lot of effort to figure out continuous delivery practices so as to streamline the regular deployment of value into production. Advanced teams are releasing daily if not several times a day due to adoption of practices such as automated regression testing, continuous integration (CI), and continuous delivery (CD). As a result most of the DevOps discussion in these communities focuses on these topics, sometimes straying into other practices such as canary testing, feature toggles, and production monitoring frameworks. Clearly important techniques, but still not covering the full potential range of DevOps. These practices and more are described later.
- Operations professionals are often frustrated. Many operations groups are overwhelmed already with the rate of updates being foisted upon them by development teams. This is often exacerbated by the inconsistent use of technologies — the impact of the lack of enterprise awareness within undisciplined development teams is largely felt by the operations group who needs to support the plethora of technology platforms used by the full range of development teams. Worse yet, the internal operations processes are often based on heavy implementations of ITIL or ITSM and have yet to be streamlined so that operations engineers are in a better position to collaborate with development teams.
- Tool vendors have limited offerings. As a result of this the DevOps messaging from tool vendors will focus on just the aspects of DevOps supported by their tools, narrowing the discussion to what they have on offer. Yes, tools are important, but they are only part of the DevOps picture. Even if there was a vendor with a full range of tools, and if they actually interoperated smoothly (yes ALM vendors, we’re referring to you), you would still need to understand how to use those tools effectively. To paraphrase an old saying — A fool with a DevOps tool is still a fool.
- Service vendors have limited offerings. Similar to the issues surrounding tool vendors, service vendors are also making great claims about their deep expertise in DevOps. Upon examination you will often find, like the tool vendors, their definition of DevOps will focus on whatever they can currently support.
- Tool vendors treat DevOps as a marketing buzzword. To be blunt, many vendors have taken their existing products, and started marketing them as DevOps products (regardless of how well those products actually support DevOps practices). Granted, these products may have been very good at supporting traditional ways of working, but when it comes to supporting DevOps they prove to be rather clunky even though they may have added a few new features.
- The DevOps=Cloud vision. There is a lot of rhetoric, particularly coming from Cloud vendors, about how cloud-based tooling and deployment environments are critical to success in DevOps. Yes, having a cloud-based infrastructure clearly enables many DevOps practices and given the choice we prefer to work in an environment which leverages cloud-based technologies whenever appropriate. But, that doesn’t mean that the cloud is a prerequisite for doing DevOps.
The point is that there are several contributing factors to the lack of agreement within our industry as to what DevOps means in practice. The implication is that when someone is giving you advice about DevOps that you need to understand the scope of what they’re actually discussing. Another way to understand what DevOps is and how it may apply to your organization is to explore the various DevOps strategies and practices available to you.