alt Hacker NewsDevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions, and require two different life styles.
Doing ops also means entering the on-call rotations, being in the war room when a data center goes under and being on the hook when a DDOS brings down the service.
Very few people want that in their life, money be damned. Same way in an ideal world devs should also participate in customer support, but very few could really do it or handle that for years.
Replies
Last team I was on was repsonsible for supporting and maintaining their product, with help from the SRE team. It means after-hours support for issues and (maybe) releases but I think this was the right way. You became the backstop and support resource for things like data center outages and DDOS attacks that were largely the responsiblity of the (much smaller than many places) SRE team. We also put devs very closely behind front-line customer facing staff where it made sense (ex: reporting & analytics - yes, platform - probably not). It made the devs better and they might try and deny it but I think most of them actually appreciated it. #YMMV
> being in the war room when a data center goes under
When doesn't this involve devs? If you have ops separate and isolated from the development effort, a devs representation will have to get involved at some point.
>DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions
That's why they have to be the same team. Your dev team needs to: 1. understand how to write code that can be debugged and recovered in a crisis, 2. learn to write code that doesn't cause the crisis in the first place, 3. have the motivation to do so because they will be the ones paged.
Anything else produces are far worse experience for everyone involved, especially customers.
The problem I've seen with DevOps is that some fief-builder sets up a "DevOps Organization", which is literally the opposite of what DevOps means.
> DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions, and require two different life styles. Doing ops also means entering the on-call rotations, being in the war room when a data center goes under and being on the hook when a DDOS brings down the service.
That's exactly the issue that DevOps aims to solve, though. When you have developers who have no ownership or responsibility once the software is running on production, it becomes a "throw it over the fence" situation, and devs don't care about the operational side.
Logging? Who needs that, if there's a bug report I'll reproduce it on my local machine (and if I can't, CLOSE-WONTFIX!) Performance monitoring? That's an ops problem, tell 'em to buy better hardware. Application crashes? Works on my machine, probably a bug in the server config; ops problem. Tell them to set up a scheduled restart every hour.
You still need dedicated operations staff who deal with the overall system health and design, but yes, a developer needs to be involved when a DDOS brings down the service, because how should the system behave under heavy traffic? Can it serve up cached read-only pages? Did someone find a very CPU-intensive public endpoint that is being exploited and needs to be fixed? Only your developers can answer this question, not the ops team.
Any developer who doesn't at least *understand* the ops side of the fence and has never spent time actually *doing* it, will make bad decisions along the way from an ops perspective. These are bad developers.