DevOps is now more than a decade old, and the concepts, practices and strategies associated with the model have evolved significantly during the past 10 years. Indeed, when people talk about DevOps today, they often mean something very different from DevOps in an earlier era.
To understand what DevOps has become, it’s worth surveying the evolutionary phases through which DevOps has passed since folks began speaking of the model in 2009. Keep reading for an overview of how the meaning of “DevOps” has shifted over the past decade, and what all of those changes mean for DevOps today.
DevOps’ Early Days: Uniting Dev and Ops
Early-on, DevOps was pretty simple and straightforward. The message that came out of the first DevOps conferences and blog posts was that software deployment would be smoother if developers (the people who write applications) and IT operations engineers (the people responsible for deploying and managing applications) communicated better, saw each others’ points of view and stopped blaming each other whenever something went wrong.
During this period, DevOps involved few specific tools or methods. Most of the tools that the DevOps crowd championed, like CI servers, were part and parcel of the agile movement, which predated DevOps by several years.
Thus, at first, DevOps prescribed a goal--better communication between dev and IT Ops--but offered virtually nothing in the way of tools or processes to help achieve that goal. Figuring out how to "do DevOps" was up to the user.
Containers and DevOps
This remained the case until 2013, when Docker containers became publicly available.
Docker wasn’t the first containerization platform out there; in fact, container technology dates back decades. But, arguably, Docker was lucky in that it appeared right at a time when DevOps advocates were looking for a technology that would allow them to put their philosophy into practice.
That’s what Docker (and other container platforms that appeared in its wake, like Kubernetes) did by providing an application deployment format that could be used in both development and production environments. In this way, Docker containers simplified collaboration between developers and IT engineers, facilitating the core goal of DevOps.
This isn’t to say that containers have become the singular technological solution for doing DevOps. Then, and now, it’s possible to achieve cooperation between development and IT without containers. And there are lots of other reasons to use containers beyond advancing the goals of DevOps.
Still, DevOps containers played an important role in the first half of the 2010s in helping to build out an actual toolset for DevOps practitioners, and to turn DevOps into more than just a philosophy.
Beyond DevOps: The Rise of “Everything Ops”
By the mid-2010s, another significant shift occurred in the evolution of DevOps: Instead of just developers and IT engineers, other stakeholders in the software delivery process--such as software testers and security experts--were incorporated into the DevOps fold.
In other words, the goal of DevOps became seamless collaboration not just between dev and IT, but also among testing teams, security teams and more.
By 2016, this expansion was complete enough for New Relic to proclaim the rise of “everything Ops” and to identify more than a dozen offshoots of DevOps, most of which aimed to extend the principles to other realms--ranging from data and security to marketing. Other definitions dubbed this trend of extending DevOps across the organization “DevOps 2.0.”
The Age of Continuous Everything
In the past few years, every process that relates to DevOps is also supposed to be “continuous.”
Continuous is a pretty ambiguous term, and it’s not always defined exactly the same way. But, in general, when people talk about processes being continuous in the context of DevOps, they are referring to the idea that processes should occur at all stages of the software delivery pipeline. For example, you shouldn’t test your software only at one point in the pipeline; you should start testing as soon as you can, and keep testing all the way through production. Likewise, instead of doing security scanning just once, you do it continuously.
This obsession with “continuousness” has led some to call this the age of “continuous everything.” Sometimes, I think this mantra goes too far--not every process actually needs to be fully continuous. Plus, few processes are literally continuous in the sense that they are active constantly, with no delays.
I think the real goal is to make processes comprehensive and predictable, if not literally continuous. And when all processes (not just development and IT work) that have to do with software delivery are comprehensive and predictable, you get a better result.
DevOps Going Forward
Where is DevOps headed next? What will be the next major evolution in the way we think about DevOps, or what DevOps is intended to mean?
A full answer to those questions is beyond the scope of this article, but let me speculate a bit on what is in store for DevOps going forward. I suspect that one shift will involve more incorporation of machine learning and AI into DevOps practices. After all, DevOps is all about seamless processes, and AI-powered decision making can help to make processes smoother by removing the need for human intervention. (It can also make them riskier, but teams may find that tradeoff to be worth it.)
I also imagine that DevOps and the cloud will intersect to a greater degree. Surprisingly, there hasn’t been a super strong focus on the cloud (or on so-called cloud-native technology) within the DevOps community. Sure, plenty of DevOps practitioners use the cloud. But many DevOps-oriented tools (like CI servers and containers) are not bound to the cloud; they can run on-premise or in the cloud. But I’d be surprised if the DevOps community is able to resist being swept up by the cloud-native tide for much longer. I suspect that, in a few years, DevOps will be centered primarily on cloud-based tooling.
Conclusion
DevOps was originally a relatively simplistic idea, which revolved around making developers and IT engineers talk more effectively with each other. It was only over time that specific types of tools--like containers--became closely associated with DevOps. And it took longer for the DevOps concept to be extended to all parts of the organization, rather than just development and IT. Whatever comes next for DevOps, it’s clear that DevOps circa 2020 will be markedly different than DevOps circa 2010.
