While I officially have the title of DevOps Engineer, I virtually always introduce myself as only as Engineer---not in the least because part of my job is interacting with clients and I'm not excited to explain to them what DevOps means. I have a somewhat unusual background in that I came to DevOps from a background in traditional systems administration (e.g. Windows MSP, network engineering, Linux sysadmin), and a later career background in security. As a result I tend towards old-school. For flavor, I once held a title in "Compilation Engineering," not meaning engineering the compilers, but managing the clusters that ran them. My concerns tend to be radically different from those with a software engineering background, even within a "DevOps team". I have occasionally said that there are many "DEVops," a few "devOPS," and almost nothing in between.
I think there's some good content in this article but also a certain amount of, I'm not sure what to call it. Inexperience?
I can agree that in an ideal world having people with the title of DevOps Engineer or especially a DevOps team is an antipattern. However, in most organizations I have worked in there has been a clear need to hire people specifically for DevOps and a good component of the work has been, at least initially, limited to those individuals. The basic reason is that most software engineers, even very experienced ones, are generally quite weak in the areas of operations, network engineering, conventional system administration, and compliance. I don't necessarily blame them as these are areas that are addressed poorly or not at all in most academic programs, and are not generally viewed as skills which are behooving of a software engineer. The result is that individuals need to be hired specifically for DevOps roles in order to get that skillset.
Further, except in perhaps some of the most fortunate startups, DevOps is virtually always transformational---that is, it is being put in place to either replace a previous process (e.g. development in one division and operations in another) or to create process for the first time (e.g. a startup which has had testing and deployments done manually by developers). This is another factor that makes designed DevOps contributors valuable, because the bottom line is that DevOps needs to be forced on the organization to some extent. It can often take an outsider to drive significant change in business processes.
Finally, as much as DevOps is bandied about, I am not convinced that most developers are actually interested in working in an "ideal" DevOps environment. I have spent most of my career as an IT person supporting developers, whether that was called DevOps or just being the person in IT the developers emailed. In most of these roles I have done a lot of things that the developers just weren't willing to, and even as a "DevOps Engineer" I continue to view "keeping out of the developer's way" as a primary goal. This means, for example, that I usually handle most of the tool development around local (developer workstation) and automated build and test because the developers just don't want to---ironically, in the eyes of many developers, I think DevOps means the developers being as uninvolved in operations as possible.
They're turning to DevOps because they want to get rid of the workload associated with herding a traditional IT organization, not because they want to do it all themselves! I don't really blame them either as, as I said, not many developers really have the skillset to excel with this kind of thing, nor (and this is more opinion) the inclination to obtain that skillset. There just aren't that many people out there who care about getting the Kubernetes cluster to self-heal right or finding the weird performance/stability problem in the software-defined network, which is why DevOps tends to be split-brained between "automating operations" and "paying someone else so we don't have to think about it," which is the general goal to which most cloud providers aspire.
Ultimately, the goal of all DevOps organizations ought to be to eliminate themselves by getting things to be so painless and automated that developers will do it all themselves. But basically no organization signs up for DevOps with the idea that they are adding workload to the developers, and so at least initially a dedicated DevOps capacity needs to exist from a practical perspective. The issues of skillset and desired work characteristics mean that that capacity tends to stick around. As much as DevOps is bandied about as two great tastes that taste great together, the reality may very well be that all DevOps really means is getting the IT resources and the development resources to talk to each other more often and do enough cross-training to be able to understand the other's problems, and honestly I think that's fine.
But then I say that as someone who intentionally does not describe myself as a software engineer because I frankly don't enjoy writing software that much... and yet part of my job always ends up being troubleshooting the product, adding tracing and monitoring integrations, etc. I can't complain too much because I do need the familiarity with the code base to be able to address developer requests well. Similarly, the developers need the familiarity with my work to be able to understand how it impacts them and how to engineer for effective deployment and management, but I wouldn't wish my configuration management and network diagrams on them.
Or I could sum up the entire thing more shortly: DevOps as an ideal is founded on the concept that there exists a set of people who want to be evenly responsible for both the development and the operations. I have not so far met more than one or two of these people, certainly not enough to staff a company with. Barring such miraculous hiring, viewing DevOps as getting your development people and operations people to work effectively together is just fine.
Wasn’t the idea of DevOps to put Dev and Ops engineers (two distinct roles) in one team?
So instead of the Dev team working on code and testing it, and then throwing it over a silo wal to the Ops team to run it in production, now they collaborated from the start to in the end ship good quality code?
When was it decided this meant one person had to know two jobs?
I applied for an architecture role once. It sounded interesting in email. Once I got to the phone screen part, they gave me a huge sales pitch, then told me I'd be working in Word and Powerpoint all day. "This is not a hands on position."
> Are they hiring for a single role or a whole team?
YES.
That's right, while the teams might have different responsibilities, but some remain constant. like provisioning infrastructure, going oncall and solving tickets, writing your actual software and think about and design the next iteration.
The expectation for team members is that one should be able to do all that, not at once obviously, but when needed will rise to the task.
This is a great article. It is really sad how "DevOps" has become just another way to label the Ops team, or the developer tools team, or the release managers, without trying to break any silos between the teams...
Get good enough at any role and the expectations should and will be broad. That would be the "crossing" part of "crossing the T." Why exactly does this article keep saying "DevOps?"
I think there's some good content in this article but also a certain amount of, I'm not sure what to call it. Inexperience?
I can agree that in an ideal world having people with the title of DevOps Engineer or especially a DevOps team is an antipattern. However, in most organizations I have worked in there has been a clear need to hire people specifically for DevOps and a good component of the work has been, at least initially, limited to those individuals. The basic reason is that most software engineers, even very experienced ones, are generally quite weak in the areas of operations, network engineering, conventional system administration, and compliance. I don't necessarily blame them as these are areas that are addressed poorly or not at all in most academic programs, and are not generally viewed as skills which are behooving of a software engineer. The result is that individuals need to be hired specifically for DevOps roles in order to get that skillset.
Further, except in perhaps some of the most fortunate startups, DevOps is virtually always transformational---that is, it is being put in place to either replace a previous process (e.g. development in one division and operations in another) or to create process for the first time (e.g. a startup which has had testing and deployments done manually by developers). This is another factor that makes designed DevOps contributors valuable, because the bottom line is that DevOps needs to be forced on the organization to some extent. It can often take an outsider to drive significant change in business processes.
Finally, as much as DevOps is bandied about, I am not convinced that most developers are actually interested in working in an "ideal" DevOps environment. I have spent most of my career as an IT person supporting developers, whether that was called DevOps or just being the person in IT the developers emailed. In most of these roles I have done a lot of things that the developers just weren't willing to, and even as a "DevOps Engineer" I continue to view "keeping out of the developer's way" as a primary goal. This means, for example, that I usually handle most of the tool development around local (developer workstation) and automated build and test because the developers just don't want to---ironically, in the eyes of many developers, I think DevOps means the developers being as uninvolved in operations as possible.
They're turning to DevOps because they want to get rid of the workload associated with herding a traditional IT organization, not because they want to do it all themselves! I don't really blame them either as, as I said, not many developers really have the skillset to excel with this kind of thing, nor (and this is more opinion) the inclination to obtain that skillset. There just aren't that many people out there who care about getting the Kubernetes cluster to self-heal right or finding the weird performance/stability problem in the software-defined network, which is why DevOps tends to be split-brained between "automating operations" and "paying someone else so we don't have to think about it," which is the general goal to which most cloud providers aspire.
Ultimately, the goal of all DevOps organizations ought to be to eliminate themselves by getting things to be so painless and automated that developers will do it all themselves. But basically no organization signs up for DevOps with the idea that they are adding workload to the developers, and so at least initially a dedicated DevOps capacity needs to exist from a practical perspective. The issues of skillset and desired work characteristics mean that that capacity tends to stick around. As much as DevOps is bandied about as two great tastes that taste great together, the reality may very well be that all DevOps really means is getting the IT resources and the development resources to talk to each other more often and do enough cross-training to be able to understand the other's problems, and honestly I think that's fine.
But then I say that as someone who intentionally does not describe myself as a software engineer because I frankly don't enjoy writing software that much... and yet part of my job always ends up being troubleshooting the product, adding tracing and monitoring integrations, etc. I can't complain too much because I do need the familiarity with the code base to be able to address developer requests well. Similarly, the developers need the familiarity with my work to be able to understand how it impacts them and how to engineer for effective deployment and management, but I wouldn't wish my configuration management and network diagrams on them.
Or I could sum up the entire thing more shortly: DevOps as an ideal is founded on the concept that there exists a set of people who want to be evenly responsible for both the development and the operations. I have not so far met more than one or two of these people, certainly not enough to staff a company with. Barring such miraculous hiring, viewing DevOps as getting your development people and operations people to work effectively together is just fine.