WARNING: This post may be misleading. What I call “devops” below is not what the canonical description of the term seems to be. Please make sure to read comments after this post to get a better picture.
Why do you consider DevOps a standalone discipline? Isn't what yo described just the characteristics of state of the art systems administration?In other words, is devops a standalone thing or is it just a fancy new name for a sysadmin. I couldn’t answer the question back then, but now, having thought about it for a bit, I am at least in a position to offer an opinion.
Most IT organizations consist of 2 groups of people: developers and non-developers. Whether these two groups work together or hate each others’ guts, doesn’t really matter for the purposes of this post. Non-developers group is traditionally subdivided into facilities, systems, network, storage, applications and security. In smaller teams, an individual could be a part of several functions from this list (people call it “wearing many ops hats”); in bigger teams each function could be its own department; in extra large teams, each function may even have its own director. Developers write and maintain code that powers the business, non-developers assure whatever is needed for the code above to work properly, is there and works as it should.
But there is another hidden taxonomy for non-developers group. If we look at it with the focus on individual activities instead of on people’s job descriptions, you will see this group consisting of:
- activities around hardware purchased from vendors
- activities around software purchased from vendors (excluding software delivered as a service)
- activities around software and infrastructure delivered from vendors as a service
- activities around open-source and/or freely downloadable software
- activities around software developed in-house
I believe that the first 2 types of activities are mostly SYSTEMS ADMINISTRATION - common theme here is MANAGE or ADAPT. One needs to perform day-to-day tasks like user account management and troubleshooting; identify, prepare, test, perform and validate changes; analyze utilization and plan capacity expansion. Because items under management in this category are purchased from vendors, the expectation is that vendor provides everything necessary to run their stuff successfully, and sysadmin’s main goal here is to adapt it to run optimally in this company’s environment. Analogy here is you mold something into shape. To excel in this category, one needs a lot of knowledge about a particular system, its gotchas and peculiarities. Such knowledge is usually obtained through experience through trial and error, vendor trainings and user group meetings. One can totally do this without software development background.
The other 3 types of activities, on the other hand, are mostly DEVOPS (infrastructure as code) - in contrast to MANAGE and ADAPT, main themes here are CREATE or ASSEMBLE. It’s not taking something that already exists in some form and molding it into the shape you need - it’s taking a lot of standalone pieces and getting them to work together (like building with Lego). There is no way this can be done successfully at scale without software development background - devops is dominated by developers who turned into ops, or ops who have been doing a lot of serious scripting all along.
Interestingly, startups are more likely to lean towards hiring devops-minded engineers, because these days a lot of startups don’t need to manage their own hardware anymore and often can build their products on software stacks which do not include any proprietary software (that would need to be purchased from vendors). There might not be a need in sysadmin at startups anymore, but it doesn’t mean the sysadmin skills are no longer needed anywhere else in IT - just look at all the big IT companies on NASDAQ and NYSE selling big iron or complex software systems.
It’s also worth noting that separation could be not as clear-cut - for example, controlling hardware devices programmatically, using published or unpublished APIs or telnet & expect voodoo, definitely fits under devops.
Therefore, in my opinion, devops is indeed a standalone discipline, but it doesn’t mean that a given person’s role in organization could be devops. We are all engineers, and difference is what kind of activities one performs during a given day - when you perform a firmware upgrade on a piece of hardware, it’s sysadmin; when you put together a cluster management system for your nodes in EC2 - it’s devops.
P.S. Yes, I know that what I keep calling “devops” is not about what others call “devops” - culture of collaboration between developers and ops. I just don’t know what else to call this.