8 ms·

As a developer I don't want to touch ops. So "we" does not exist.

by Dev_2019 7y ago

klodolph 7y ago
Like… you don’t want to talk to the ops team at all? You don’t want them to talk to you? (Also… in English, “we” does not always include the listener. Whether the listener is included is unspecified.)
- byte1918 7y ago
  From experience, I think he just means he doesn't want to work on operations tasks. I don't think he has anything against people doing ops.
ownagefool 7y ago
I think the idea that a Ops needs to wake up in the middle of the night to deal with shit outages because a developer is unwilling to stand behind their code is probably outdated. Build & Run is becoming very popular.
- mrweasel 7y ago
  We're reaching a point where two groups of people, rather than one, is required to wake up in the middle of the night. Previously just the operations people needed to get up, now developers need to be on-call as well. Operations teams are scaling down their monitoring to just infrastructure, because the applications are more opaque than ever. Incidents at the application level are no longer fixable by Ops, because they have no idea what the developers deployed or how it's configured. Developers now need to take responsibility for application monitoring, patch management and incident management. Meaning that we're shifting more work to a group of people that where already in short supply. I don't think we're necessarily moving in the right direction. There's certainly benefits to development and operations working in tandem, but currently we're just moving operations to developers without much consideration for the people that needs to do the actual work. In my opinion your company/solution needs to be somewhat limited for "DevOps" to make sense. For everyone else, it's two separate roles.
  - klodolph 7y ago
    I would say that the problem in this situation is hard to avoid. If you can have an operations team who are experts on the application as well, and have the team more closely integrated with the development team, then you generally don’t need to wake up developers at night. I spent a few years on a team set up like this and it worked very well. If your project isn’t big enough for its own operation team you can share a team between a few different projects. But I don’t think it’s necessarily that much harder to hire developers than it is to hire devops. Some managers have told me that hiring for devops is harder. And developers should feel some of the pain—I’m not saying page them in the middle of the night, but they should be doing daytime on-call rotations. This helps align incentives and makes developers aware of reliability issues in the systems that they create. > In my opinion your company/solution needs to be somewhat limited for "DevOps" to make sense. For everyone else, it's two separate roles. When I think DevOps, I already think of it as a role separate from development. You have devs, and then you have devops. You can combine both roles into one, and that makes sense for smaller / earlier stage projects, but otherwise I think of devops as a separate role. Kind of a mess because devops varies so much between companies and isn’t even consistently named. But my experience is that it’s not necessary to wake up two groups of people—it’s either a developer that gets woken up because the project is too small or too early to be supported by operations, or it’s someone in devops/SRE/production engineer who gets woken up. There’s a lot of practices that need to be put into place to make this work, but it’s doable.
    - aairey 7y ago
      DevOps is not a role. You arebtalking about a modern ops role in this dialogue. Merging the two as you said, is DevOps.
    - SideburnsOfDoom 7y ago
      > You have devs, and then you have devops. Better call the second role "Ops" then, and wait for someone to propose merging it with "Dev" again. There's so much mental confusion and meaningless use of language now, about the term "DevOps" that was a fairly simple suggestion about bringing DEVelopment and OPerationS together. That sentiment is literally in the word, I don't know how it could be plainer.
mweibel 7y ago
"we" doesn't necessarily include all. Anyway, that's a bit sad IMHO. In my opinion, running what you build is great to discover ways to improve your software. Regardless if you want to or don't want to touch ops: You still might want to talk to ops or vice-versa. Even if you have strict roles for devs and ops (and no mixed roles), you might be in a team where both are present and hopefully talk to each other.
SideburnsOfDoom 7y ago
The truth of what the code that you develop actually does, is in production; often buried in log stores and timing stats and other "ops" places. It's better if that data is unearthed and fed back into the development process, it's better if that feedback loop is closed, it's better if that separation is removed. That's one of the reasons for "DevOps" as originally formulated.
skywhopper 7y ago
Well, as an ops person, I don't want to touch your code, then.
gabrtv 7y ago
Gabe from the Azure team here. We built OAM for you, and for your counterparts in ops who want to help you innovate faster. :)

As a developer I don't want to touch ops. So "we" does not exist.

Like… you don’t want to talk to the ops team at all? You don’t want them to talk to you? (Also… in English, “we” does not always include the listener. Whether the listener is included is unspecified.)

byte1918 7y ago
From experience, I think he just means he doesn't want to work on operations tasks. I don't think he has anything against people doing ops.

ownagefool 7y ago

I think the idea that a Ops needs to wake up in the middle of the night to deal with shit outages because a developer is unwilling to stand behind their code is probably outdated. Build & Run is becoming very popular.

mrweasel 7y ago
We're reaching a point where two groups of people, rather than one, is required to wake up in the middle of the night. Previously just the operations people needed to get up, now developers need to be on-call as well. Operations teams are scaling down their monitoring to just infrastructure, because the applications are more opaque than ever. Incidents at the application level are no longer fixable by Ops, because they have no idea what the developers deployed or how it's configured. Developers now need to take responsibility for application monitoring, patch management and incident management. Meaning that we're shifting more work to a group of people that where already in short supply. I don't think we're necessarily moving in the right direction. There's certainly benefits to development and operations working in tandem, but currently we're just moving operations to developers without much consideration for the people that needs to do the actual work. In my opinion your company/solution needs to be somewhat limited for "DevOps" to make sense. For everyone else, it's two separate roles.
- klodolph 7y ago
  I would say that the problem in this situation is hard to avoid. If you can have an operations team who are experts on the application as well, and have the team more closely integrated with the development team, then you generally don’t need to wake up developers at night. I spent a few years on a team set up like this and it worked very well. If your project isn’t big enough for its own operation team you can share a team between a few different projects. But I don’t think it’s necessarily that much harder to hire developers than it is to hire devops. Some managers have told me that hiring for devops is harder. And developers should feel some of the pain—I’m not saying page them in the middle of the night, but they should be doing daytime on-call rotations. This helps align incentives and makes developers aware of reliability issues in the systems that they create. > In my opinion your company/solution needs to be somewhat limited for "DevOps" to make sense. For everyone else, it's two separate roles. When I think DevOps, I already think of it as a role separate from development. You have devs, and then you have devops. You can combine both roles into one, and that makes sense for smaller / earlier stage projects, but otherwise I think of devops as a separate role. Kind of a mess because devops varies so much between companies and isn’t even consistently named. But my experience is that it’s not necessary to wake up two groups of people—it’s either a developer that gets woken up because the project is too small or too early to be supported by operations, or it’s someone in devops/SRE/production engineer who gets woken up. There’s a lot of practices that need to be put into place to make this work, but it’s doable.
  - aairey 7y ago
    DevOps is not a role. You arebtalking about a modern ops role in this dialogue. Merging the two as you said, is DevOps.
  - SideburnsOfDoom 7y ago
    > You have devs, and then you have devops. Better call the second role "Ops" then, and wait for someone to propose merging it with "Dev" again. There's so much mental confusion and meaningless use of language now, about the term "DevOps" that was a fairly simple suggestion about bringing DEVelopment and OPerationS together. That sentiment is literally in the word, I don't know how it could be plainer.

mweibel 7y ago

"we" doesn't necessarily include all. Anyway, that's a bit sad IMHO. In my opinion, running what you build is great to discover ways to improve your software. Regardless if you want to or don't want to touch ops: You still might want to talk to ops or vice-versa. Even if you have strict roles for devs and ops (and no mixed roles), you might be in a team where both are present and hopefully talk to each other.

SideburnsOfDoom 7y ago

The truth of what the code that you develop actually does, is in production; often buried in log stores and timing stats and other "ops" places. It's better if that data is unearthed and fed back into the development process, it's better if that feedback loop is closed, it's better if that separation is removed. That's one of the reasons for "DevOps" as originally formulated.

skywhopper 7y ago

Well, as an ops person, I don't want to touch your code, then.

gabrtv 7y ago

Gabe from the Azure team here. We built OAM for you, and for your counterparts in ops who want to help you innovate faster. :)