April 26, 2018
The topic of what “DevOps” is has been a source of contention since the term first arose. This post is my take on what it means, based on about five years of experience in the field at this point.
DevOps, literally speaking, is development operations. In the broadest of terms, it means “operations in support of development.” This is in contrast to the popular technical meaning of DevOps, which is “a culture of breaking down silos, especially between development and operations.”
Recruiters would have you believe that DevOps is a kind of glorified system administrator who also can write application code. This is both true and false. True, in the sense that “DevOps engineers” have both an understanding of how to write application code and also their relationship to the systems they run in. False, in the sense that the code that DevOps folk write is not exactly application code, but rather system logic geared towards a few key concepts that have more to do with systems than with isolated programs.
It would be more accurate to say that modern DevOps engineers are an evolution of systems engineers. Even that, though, is doing both professional disciplines an injustice.
As I see it, you are a “DevOps engineer” if your focus is on improving the developer experience of creating software and having that software operate predictably at scale. Automating manual processes, drawing attention to performance gain opportunities, and securing systems against malicious actors are all core practices of this discipline.
If I were to describe the various related disciplines, I would do it like this:
To put it another way: DevOps engineers are either high-demand generalists with a lot of experience, or miscategorized practitioners of one of the other three roles. There is some crossover between all four regardless, but the focus differs.