3 ms·

I am a DevOps Engineer by trade and title. Here is my take on this: It is a role - not something that can be done by OPS or DEV or SEC or what have you. Allo

I am a DevOps Engineer by trade and title. Here is my take on this: It is a role - not something that can be done by OPS or DEV or SEC or what have you. Allow me to explain my 2 cents worth: - With the amounts of tooling (CI/CD pipeline, infrastructure monitoring, infra. provisioning, config. management, etc.), you do not want your DEVs or your full-time admins focusing on this bit at-all. It is good if they have some know-how (or even if they do the initial groundwork) but if your DEVs or sys admins are focusing on what 'entails' as DevOps -- then Houston, we got a problem. Because this means that DEV or sys admin or what have you is not focusing 100% on their role. - Why is 'DevOps' getting so much flak?? How about titles/roles such as 'scrum master' or 'Agile Practitioner' or 'Product Owner'? - I am not a noob by any means (~10 yr IT experience) and I am past the stage of getting excited by a job title. However, the 'DevOps' title given to a 'DevOps' guy is a correct move. AND, believe-it-or-not, it is a IT specialization -- just like 'cloud' is. Just because everything is a code doesn't mean you don't need a dedicated person who will not only preach DevOps -- but will also 'implement' DevOps -- and that fella should be called 'DevOps' -- just like 'Agile Coach' ;-)

ErrantX 9y ago
I'd have a contrary view which is that yes you DO want your engineers to understand dev and ops (and sec and change etc etc) and actively be able to own a service through its lifecycle. Those engineers might have different focuses; so maybe building a data store, or an api, or a Jenkins system, or an artefact store.... If you leave your cicd tooling and toolchains to a team then you create a dependency, and for me a key part of devops is reducing dependencies. The suggestion in your post is that by blurring the traditional roles you make those people less productive. And therefore the solution is to create a new role. That's fine: but that's the old thinking (IMO) hanging around. The original intent of devops would definitely run counter to that :)
lmickh 9y ago
Would argue that you have a tools/service team. The fact that you failed to mention changing what devs and sysadmins consider when "focusing 100%" on their role indicates that what you are talking about isn't the concept of DevOps in the article. Saying you have a DevOps team is like saying you have Lean team, a Theory of Constraints team, or a Just-in-time manufacturing team. DevOps doesn't say that devs shouldn't write code any more then Theory of Constraints says a guy that paints car hoods should be building brake pads. It is about the fact that they should work together to ensure the organization as a whole meets the goals. Not as isolated units that only prioritize their own goals. I've seen the same flak about Agile and scrum roles for the same reason. People think they can buy the DevOps/Agile/whatever. Only difference with DevOps is rest is that it is getting more noise.

ErrantX 9y ago

I'd have a contrary view which is that yes you DO want your engineers to understand dev and ops (and sec and change etc etc) and actively be able to own a service through its lifecycle. Those engineers might have different focuses; so maybe building a data store, or an api, or a Jenkins system, or an artefact store.... If you leave your cicd tooling and toolchains to a team then you create a dependency, and for me a key part of devops is reducing dependencies. The suggestion in your post is that by blurring the traditional roles you make those people less productive. And therefore the solution is to create a new role. That's fine: but that's the old thinking (IMO) hanging around. The original intent of devops would definitely run counter to that :)

lmickh 9y ago

Would argue that you have a tools/service team. The fact that you failed to mention changing what devs and sysadmins consider when "focusing 100%" on their role indicates that what you are talking about isn't the concept of DevOps in the article. Saying you have a DevOps team is like saying you have Lean team, a Theory of Constraints team, or a Just-in-time manufacturing team. DevOps doesn't say that devs shouldn't write code any more then Theory of Constraints says a guy that paints car hoods should be building brake pads. It is about the fact that they should work together to ensure the organization as a whole meets the goals. Not as isolated units that only prioritize their own goals. I've seen the same flak about Agile and scrum roles for the same reason. People think they can buy the DevOps/Agile/whatever. Only difference with DevOps is rest is that it is getting more noise.