2021 is coming to a close, and as 2022 quickly approaches, I thought this would be a great time to level-set on something important to many of us. This blog is my attempt at explaining and defining DevOps in a straightforward manner. It’s not perfect, and it’s just the way I see DevOps. What DevOps means to me may be completely different from what DevOps means to you, so take this with a grain of salt (although, if you agree with me, it will be so much easier to be friends).
If you ask ten people to define DevOps, you will get eleven different answers. On the other hand, if you ask ten DevOps Engineers to define their role, you may only get two to three different answers. In general, we all have difficulty agreeing on broad concepts, which is why the trend over the last five years has been to simplify what DevOps is by assigning a set of roles and responsibilities to it.
The Roots of DevOps
The traditional definition for DevOps has its roots in agile software development methodologies, and quality engineering approaches. It also draws inspiration from lean manufacturing/production principles, which are mainly concerned with eliminating waste by streamlining processes and encouraging continuous improvement. The hidden team in all of this is the business. Releasing quality software quickly is great, but if that software is not in-line with the company’s goals, all of the fine work the dev and ops teams are doing loses much of its value. [Disclaimer: I am NOT advocating for adding more letters to the term DevOps. Let’s all agree that the business needs to have a seat at the DevOps table]
As the DevOps methodology became more popular, and as vendors started branding their tools as “DevOps tools,” many started to associate DevOps with the automation of production and infrastructure operations. That’s not entirely true (though most DevOps practitioners are involved in applying various forms of automation). DevOps has to do with changing how people think about producing software, releasing software, provisioning, monitoring, and maintaining services. It emphasizes communication between all members of an organization to ensure that everyone understands their role within the entire process flow. So, that makes everyone (at least partially) a DevOps engineer (yes, even the business teams).
DevOps Through My Eyes
When I think of DevOps, I think of the improved collaboration between development and operations disciplines: putting dev and ops people into the same room (ideally a room filled with pizza and beer…or something healthier if you must) and asking them to communicate with each other. This is not always an easy task since dev and ops people can have vastly different vocabularies.
For DevOps to work, everyone needs to be able or at least willing to learn and speak each other’s language, which means ops needs to know development practices (like source control) and production operations (like monitoring). For the dev team, you may want to read up on some of the ops shorthand related to servers, databases, containers, etc.
If the dev team decides it needs a new server, they should be able to get one without asking anyone. If the dev team breaks something in production, they are responsible for fixing it. There is no “throw over the wall” from dev to ops. Dev should constantly be asking if they’re impacting production reliability with what they’re working on now. There are also no hand-offs between people or organizations in DevOps; everyone works together towards a common goal of making great products quickly and securely.
To summarize DevOps in two sentences: DevOps is a software engineering practice that encourages dev and ops to work closely together on building great software aligned with the goals of the business. An organization that embraces a DevOps practice can deploy quickly, in a repeatable and continuously verifiable manner, and can reliably release into production at pretty much any point in time.
What did I miss? How would you define DevOps in a sentence (or two)? Share your comments below.