What is DevOps?
The question of the century. It’s not quite dev, but it’s not quite ops. I frequently get asked the question “are you DevOps?” I never quite know how to answer that question. I consider myself a developer first and foremost. My title is Software Engineer. I am not necessarily “a DevOps.” I’m a developer and my approach to solving problems, even systems related problems such as provisioning infrastructure, is a developer’s approach.
In the beginning (I know what you are thinking, one of those kinds of posts), we had programmers writing code and systems administrators managing the runtime of those systems, both the applications and their underlying environments. Almost every operational task was performed by hand. Over the years these lines have blurred: operations is using frameworks to support automating their work and developers are becoming more involved in the implementation of their products. However, the job titles haven’t budged.
We Need Operations and Development
A trend I have been seeing is to list job postings for hiring “DevOps Engineers.” I think this is a bit of a misnomer. Neither position has gone away, and will not go away any time soon. Initially there was hesitation in the industry on operations automating their jobs as there were fears that operations would be replaced. At the same time there was a big push for developers to start owning infrastructure. We still see companies attempting this approach today. However, developers are not systems administrators. I have a quite balanced approach to development and operations, but I will readily admit when systems is over my head. Even systems skills I had once before have atrophied. It is impossible to be an expert at anything, you are either deeply knowledgeable on a specific role or broadly knowledged on many roles. We need operations. We need developers. Attempting to consolidate the two is an exercise in futility.
So What is DevOps?
I would like to propose a definition once and for all for DevOps:
DevOps is everything between pushing a commit and the final execution of the code.
DevOps responsibilities include:
- automated testing
- code delivery
- application monitoring
- logging
- managing data integrity
There are a lot more responsibilities not listed. What it boils down to, is that DevOps is a set of skills and disciplines to fill in the gaps betwee operations and development. There is often bleed over between the two departments. DevOps helps facilitate coordination between development and operations. It breaks down the walls that previously stood, where developers would lob applications over to operations to run and fend for themselves. A developer knows the paramters an application needs to run, they know what logging needs to be setup and what metrics need to be collected. On the flip side, operations knows how to better tune the environment to accommodate such needs. They know how to keep the environment stable and performant.
Who does devops?
You! Everybody has a stake in the software development lifecycle (SDLC) and owns that process. Everybody has a stake in production, and owns production. Does that mean that every person in an organization must be always actively involved? To a degree, yes. Does it mean having one person focused on devops is bad? Absolutely not, in fact it should be encouraged. This is a pretty natural pattern that teams fall into, individuals tend to specialize on one part of their product at a time, however just like how we approach subject matter experts (SMEs) for any other responsibility, the person focused on DevOps should continuously share knowledge and engage in peer review of their activities. The position may rotate periodically as well, which would depend on team structures.
Development benefits from having the peripheral and input into production. Operations benefits from having visibility into the development of the applications. Both benefit from a SDLC for the infrastructure automation. DevOps isn’t a position, it is a set of skills to fill in the gaps between the Dev and the Ops.
So who is a DevOps? Me. And you. And everybody else.