4 ms·

The problem with DevOps is not really how it is practiced, but how it is named. DevOps is a bucket that a bunch of things are thrown into, and everybody thinks

The problem with DevOps is not really how it is practiced, but how it is named. DevOps is a bucket that a bunch of things are thrown into, and everybody thinks the thing they threw in is DevOps with the others being mislabelled. Is having a DevOps team wrong? No, having automation experts, infrastructure experts, integration experts, etc. all makes perfect sense. Bundling all those disciplines under a single term is what is wrong. Is aiming to do "less DevOps" using "serverless" wrong? No, aiming to reduce infrastructure maintenance and design overhead is perfectly sane. Interpreting that as entirely avoiding infrastructure, or as affecting any of the other disciplines is what is wrong. What we need is better work descriptions and team organizations. But while the buzzword DevOps is bad, it's not so bad to have a fancy term that executive management understands and can put some money behind - money that allows you to spend time or buy solutions to solve your actual process problems are.

johnnymorgan 3y ago
Interesting point and one that I feel applies equally to Product Manager, another catch all title that has a ton of stuff thrown in. IMO there are 3 distinct roles that product gets thrown into, 4 really but the technical product manager is completely different. Research/data, operations and UI/UX and then the 4th being the technical product manager. The person that maps and sets up the metrics, KPIs, product intelligence and knowing the business model is very different from the person that knows the UX flow and can inform the UI. The problem IMO lies in the middle management layer, maybe ai will be able crack that but for us ;) It seems to be a problem all over many disciplines tbh
- deleted 3y ago
  [deleted]
wouldbecouldbe 3y ago
Having an automation expert would either hint to very unsuccesfull automation, or a very very large org.
- jhot 3y ago
  I've been an automation engineer on small dev teams (5-15 devs) and felt like I had tremendous impact. There were a few larger integrations I was generally hired for and then got to tackle pain points I had seen and heard about within the dev team and on the business side. Not to mention being able to refine CI/CD and take that off developers hands. I've been at a large organization for a while now and my backlog is mostly planned out quarters ahead and I don't feel like I have nearly the same impact.
  - wouldbecouldbe 3y ago
    how many hours of dev time you think you saved for 5-15, is that justifying your salary 10-25K p/m?
    - arghwhat 3y ago
      With 15 people and 7.5 hour work days, saving each person just 30 minutes a day is cost equivalent to a permanent full time role. At 30 people, you need to save just 15 minutes. At 90 people, 5 minutes. And that is without considering that a full time role would keep doing more work than that singular time saving, or the decreased operational cost from failures in manual process execution. Just because the jobs seem menial to you does not exclude it from bringing great value to an employer. (Above numbers are subject to crude linear extrapolation, but are sufficient to make the point.)
tetha 3y ago
Yep. At work, I'm being a bit picky about the wording, but it's shifting people into a better direction. We don't have DevOps people. We have a fairly modern operations team, we have more or less modern developers and tasks or projects follow a DevOps-mindset. Like, if your DBA is attending plannings of teams working on a database heavy project. That is an action following a devops-mindset - breaking up siloed knowledge at the right places in a good way in order to save time on both sides. Weeks of planned work can disappear with the words "Oh there's a postgres extension for this. Give me a week to check it out." Or, if we work on some system so a consultant managing a customers system can roll versions forwards and backwards automatically with a simple UI. Again, something following the devops-spirit of removing yourself from the loop, putting trust into the automation and enabling people to work with less friction. But again, this isn't done by a "DevOps engineer", it would usually be done by one of our operational dudes with a focus on automation and pipelines in close cooperation with the dev-team. It may be picky and pedantic, but it steers thoughts into a better place. And it gives us an answer to "What the hell is ops doing all day?" Making your devs better, and you money, good sir.
cameronh90 3y ago
"DevOps" was never originally a team or job role, it was just a workplace culture philosophy that dev and ops should work closely together rather than in isolated, and often mutually hostile silos as was common in the 90s. It just became a buzzword that everyone had to have, then C-level leadership needed "invest in DevOps", "grow the DevOps team" (because buying is easier than fixing the culture) until we lost sight of the original point and DevOps just became... ops.
- hgsgm 3y ago
  Back when I hunted willy mammoths, "DevOps" meant that there was no "dev" and "ops"; developers did ops, to avoid the friction of throwing code over the wall. Essentially it meant more "vertical" "full stack" teams, instead of horizontal layers. You knew how to write and run your system, and probably has a narrower scope of product than someone who was dev for more features or who was ops for more apps.
  - jmholla 3y ago
    Interesting. When I started I was told the idea is you apply operations principals to your developer workflows, i.e. your developers making code is as important as getting their code to production.
  - jonhohle 3y ago
    That’s how I thought about it (and lived) as well. Developers knew how to configure operating systems and databases, deploy them, etc. Everything but racking their own hardware. And sometimes even that.
- nhumrich 3y ago
  Actually, it was a role before it was a culture. See: "COO", "SalesOps", "PeopleOps", etc.
- coffeebeqn 3y ago
  In the last few startups I’ve been at , DevOps just means Infrastructure Engineer
nhumrich 3y ago
Yes! Possibly relevant article on your point: https://medium.com/swlh/yes-devops-is-a-role-you-just-do-it-wrong-4db8402eb32b https://medium.com/swlh/yes-devops-is-a-role-you-just-do-it-...
samstave 3y ago
As someone who has managed teams (including devops teams, while not being a dev myself) for 26+ years... What we need is LESS HR. And what youre saying is what we just refer to as an SME (Subject Matter Expert [SUBJECT]) Its stupid to worry about labels. But if youre an SME on the sites DBs, or Network, or scaling factors etc... your the SME for [SUBJECT] and you can still be an SRE, Dev, Ops, Network guy and still be on the Devops team/ops team/ IT team.

johnnymorgan 3y ago

Interesting point and one that I feel applies equally to Product Manager, another catch all title that has a ton of stuff thrown in. IMO there are 3 distinct roles that product gets thrown into, 4 really but the technical product manager is completely different. Research/data, operations and UI/UX and then the 4th being the technical product manager. The person that maps and sets up the metrics, KPIs, product intelligence and knowing the business model is very different from the person that knows the UX flow and can inform the UI. The problem IMO lies in the middle management layer, maybe ai will be able crack that but for us ;) It seems to be a problem all over many disciplines tbh

deleted 3y ago
[deleted]

wouldbecouldbe 3y ago

Having an automation expert would either hint to very unsuccesfull automation, or a very very large org.

jhot 3y ago
I've been an automation engineer on small dev teams (5-15 devs) and felt like I had tremendous impact. There were a few larger integrations I was generally hired for and then got to tackle pain points I had seen and heard about within the dev team and on the business side. Not to mention being able to refine CI/CD and take that off developers hands. I've been at a large organization for a while now and my backlog is mostly planned out quarters ahead and I don't feel like I have nearly the same impact.
- wouldbecouldbe 3y ago
  how many hours of dev time you think you saved for 5-15, is that justifying your salary 10-25K p/m?
  - arghwhat 3y ago
    With 15 people and 7.5 hour work days, saving each person just 30 minutes a day is cost equivalent to a permanent full time role. At 30 people, you need to save just 15 minutes. At 90 people, 5 minutes. And that is without considering that a full time role would keep doing more work than that singular time saving, or the decreased operational cost from failures in manual process execution. Just because the jobs seem menial to you does not exclude it from bringing great value to an employer. (Above numbers are subject to crude linear extrapolation, but are sufficient to make the point.)

tetha 3y ago

Yep. At work, I'm being a bit picky about the wording, but it's shifting people into a better direction. We don't have DevOps people. We have a fairly modern operations team, we have more or less modern developers and tasks or projects follow a DevOps-mindset. Like, if your DBA is attending plannings of teams working on a database heavy project. That is an action following a devops-mindset - breaking up siloed knowledge at the right places in a good way in order to save time on both sides. Weeks of planned work can disappear with the words "Oh there's a postgres extension for this. Give me a week to check it out." Or, if we work on some system so a consultant managing a customers system can roll versions forwards and backwards automatically with a simple UI. Again, something following the devops-spirit of removing yourself from the loop, putting trust into the automation and enabling people to work with less friction. But again, this isn't done by a "DevOps engineer", it would usually be done by one of our operational dudes with a focus on automation and pipelines in close cooperation with the dev-team. It may be picky and pedantic, but it steers thoughts into a better place. And it gives us an answer to "What the hell is ops doing all day?" Making your devs better, and you money, good sir.

cameronh90 3y ago

"DevOps" was never originally a team or job role, it was just a workplace culture philosophy that dev and ops should work closely together rather than in isolated, and often mutually hostile silos as was common in the 90s. It just became a buzzword that everyone had to have, then C-level leadership needed "invest in DevOps", "grow the DevOps team" (because buying is easier than fixing the culture) until we lost sight of the original point and DevOps just became... ops.

hgsgm 3y ago
Back when I hunted willy mammoths, "DevOps" meant that there was no "dev" and "ops"; developers did ops, to avoid the friction of throwing code over the wall. Essentially it meant more "vertical" "full stack" teams, instead of horizontal layers. You knew how to write and run your system, and probably has a narrower scope of product than someone who was dev for more features or who was ops for more apps.
- jmholla 3y ago
  Interesting. When I started I was told the idea is you apply operations principals to your developer workflows, i.e. your developers making code is as important as getting their code to production.
- jonhohle 3y ago
  That’s how I thought about it (and lived) as well. Developers knew how to configure operating systems and databases, deploy them, etc. Everything but racking their own hardware. And sometimes even that.
nhumrich 3y ago
Actually, it was a role before it was a culture. See: "COO", "SalesOps", "PeopleOps", etc.
coffeebeqn 3y ago
In the last few startups I’ve been at , DevOps just means Infrastructure Engineer

nhumrich 3y ago

Yes! Possibly relevant article on your point: https://medium.com/swlh/yes-devops-is-a-role-you-just-do-it-wrong-4db8402eb32b https://medium.com/swlh/yes-devops-is-a-role-you-just-do-it-...

samstave 3y ago

As someone who has managed teams (including devops teams, while not being a dev myself) for 26+ years... What we need is LESS HR. And what youre saying is what we just refer to as an SME (Subject Matter Expert [SUBJECT]) Its stupid to worry about labels. But if youre an SME on the sites DBs, or Network, or scaling factors etc... your the SME for [SUBJECT] and you can still be an SRE, Dev, Ops, Network guy and still be on the Devops team/ops team/ IT team.