4 ms·

Am I the only one who remembers when DevOps meant "developers are responsible for dealing with the operational part of their software too, so that they don't ju

Am I the only one who remembers when DevOps meant "developers are responsible for dealing with the operational part of their software too, so that they don't just throw stuff over the wall for another team to deal with the 3AM pages"? It seems to have become: "we turned ops into coding too, so now the ops team needs to be good at software engineering"

prmoustache 9mo ago
I am with you. DevOps is a methodology. DevOps as a role or team name is a fantasy from people who do not understand the methodology. If you want DevOps to work, your Ops must be member of the development team, take part in the sprints, etc. But many company do not want to do that because they want to separate ops and dev budget/accounting and do not want to hire enough people with ops skills.
- verdverm 9mo ago
  This is not true, you can make it work well either way. It's about people and processes, not about some specific setup or way of grouping people
vee-kay 9mo ago
DevOps was (and is) merely an excuse for companies to replace Developers with cheaper Ops resources, and yet expecting better services and better products from them. My personal experience says that the best way is that Ops team shouldn not be repurposed as Developers, rather put the experienced Developers into Production Support (incident management, that's intense Ops, working in shifts and weekends, etc.). And rotate them whenever needed. Over a period of time, you'll invariably see less defects and issues percolating down from the Devs, and then after both sides are stable and working well together with less friction and open tickets, then some more tech savvy Ops members can be rotated into Development teams as rookie devs to help reduce costs a bit (as there'll invariably be some natural attrition among the Devs and Ops, so this gives an alternative career path to the Ops team (who are usually less paid, and more stressed), and pushes the Devs not to become complacent). Such an approach is doable and productive.
- Uvix 9mo ago
  We tried this, but we just got more defects, because the Devs lost what little Ops knowledge they had. Where previously Ops would have to involve Devs, now that Production Support has some Dev knowledge, suddenly they get the blame for everything. Devs no longer have interest in things like "reading log files"; they just ship any problems over to Production Support.
  - verdverm 9mo ago
    You can find examples that go both ways for both endeavors, anecdata... The problem in your case is not the dev vs ops split, it's a company culture thing which I'm sure you see play out in more places than this current focus
  - vee-kay 9mo ago
    Any day, I (as a manager) would prefer to have an experienced Developer do a Production Support role, rather than a cheaply obtained non-engineering campus graduate hired as "Tech Ops" resource to do Production Support on complex, mission-critical systems. It is a bad idea for a company to give shoddy after-sales support to customers, because they would then lose the customer's trust and relationship in the long run. No customer wants to see their production systems have frequent incidents caused hours or days of outages. Vendor companies ignoring investment and support for Production Support on their Products/Services, do so at their own peril. In fact, canny companies have realised the real money is not in upfront cost, but in volume billing (billing/invoicing, based on monthly transactions counts, number of users/licenses and tiered rate card), so they need to have adequate Production Support teams This is why companies are trying their level best to move existing customers to subscription services (e.g., Office 365 by Micro$oft).
- chanux 9mo ago
  > DevOps was (and is) merely an excuse for companies to replace Developers with cheaper Ops resources [..]. Like everything, the original intentions must have been noble. But as we can see, looking back, it got popular and popular enough to get to the enterprise types. Nothing really survives that. PS: I have witnessed a sysadmin team being renamed DevOps and then SRE with not much other meaningful changes. I couldn't believe it at the time.
verdverm 9mo ago
That was an ambition of devops at one point, it has not born the fruit it promised. Dev teams are not positioned to do ops well. We have specializations for a reason
- anonymars 9mo ago
  Indeed. Another comment brought up the comparison with the idea of "full stack" (https://news.ycombinator.com/item?id=46662777 https://news.ycombinator.com/item?id=46662777). Management would sure love it if we could all be interchangeable widgets, wouldn't they (with no pesky tribal knowledge either)

prmoustache 9mo ago

I am with you. DevOps is a methodology. DevOps as a role or team name is a fantasy from people who do not understand the methodology. If you want DevOps to work, your Ops must be member of the development team, take part in the sprints, etc. But many company do not want to do that because they want to separate ops and dev budget/accounting and do not want to hire enough people with ops skills.

verdverm 9mo ago
This is not true, you can make it work well either way. It's about people and processes, not about some specific setup or way of grouping people

vee-kay 9mo ago

DevOps was (and is) merely an excuse for companies to replace Developers with cheaper Ops resources, and yet expecting better services and better products from them. My personal experience says that the best way is that Ops team shouldn not be repurposed as Developers, rather put the experienced Developers into Production Support (incident management, that's intense Ops, working in shifts and weekends, etc.). And rotate them whenever needed. Over a period of time, you'll invariably see less defects and issues percolating down from the Devs, and then after both sides are stable and working well together with less friction and open tickets, then some more tech savvy Ops members can be rotated into Development teams as rookie devs to help reduce costs a bit (as there'll invariably be some natural attrition among the Devs and Ops, so this gives an alternative career path to the Ops team (who are usually less paid, and more stressed), and pushes the Devs not to become complacent). Such an approach is doable and productive.

Uvix 9mo ago
We tried this, but we just got more defects, because the Devs lost what little Ops knowledge they had. Where previously Ops would have to involve Devs, now that Production Support has some Dev knowledge, suddenly they get the blame for everything. Devs no longer have interest in things like "reading log files"; they just ship any problems over to Production Support.
- verdverm 9mo ago
  You can find examples that go both ways for both endeavors, anecdata... The problem in your case is not the dev vs ops split, it's a company culture thing which I'm sure you see play out in more places than this current focus
- vee-kay 9mo ago
  Any day, I (as a manager) would prefer to have an experienced Developer do a Production Support role, rather than a cheaply obtained non-engineering campus graduate hired as "Tech Ops" resource to do Production Support on complex, mission-critical systems. It is a bad idea for a company to give shoddy after-sales support to customers, because they would then lose the customer's trust and relationship in the long run. No customer wants to see their production systems have frequent incidents caused hours or days of outages. Vendor companies ignoring investment and support for Production Support on their Products/Services, do so at their own peril. In fact, canny companies have realised the real money is not in upfront cost, but in volume billing (billing/invoicing, based on monthly transactions counts, number of users/licenses and tiered rate card), so they need to have adequate Production Support teams This is why companies are trying their level best to move existing customers to subscription services (e.g., Office 365 by Micro$oft).
chanux 9mo ago
> DevOps was (and is) merely an excuse for companies to replace Developers with cheaper Ops resources [..]. Like everything, the original intentions must have been noble. But as we can see, looking back, it got popular and popular enough to get to the enterprise types. Nothing really survives that. PS: I have witnessed a sysadmin team being renamed DevOps and then SRE with not much other meaningful changes. I couldn't believe it at the time.

verdverm 9mo ago

That was an ambition of devops at one point, it has not born the fruit it promised. Dev teams are not positioned to do ops well. We have specializations for a reason

anonymars 9mo ago
Indeed. Another comment brought up the comparison with the idea of "full stack" (https://news.ycombinator.com/item?id=46662777 https://news.ycombinator.com/item?id=46662777). Management would sure love it if we could all be interchangeable widgets, wouldn't they (with no pesky tribal knowledge either)