4 ms·

Can you expand on what you mean by this? Specifically: "you can't move the responsibility of operations away from the application teams without seriously compro

Can you expand on what you mean by this? Specifically: "you can't move the responsibility of operations away from the application teams without seriously compromising incentives that effect quality, throughput and reliability"

groestl 3y ago
I guess it's: You change the way you think about those metrics if you're the one being called at 2AM Saturday night.
Etheryte 3y ago
Your application architecture dictates how it should be deployed and the other way around, if you try to decouple the two you're bound to run into issues. Depending on what your application does, high throughput with some loss might be ideal, or you might need at least once delivery instead while sacrificing throughput, or any other dynamic. If your deployment is done by an entirely different team from the team that builds the product itself you have little hope of predictable positive outcomes without a lot of pain.
formercoder 3y ago
SRE needs authority to hand back the pagers. That’s a key aspect.
ddaaeugzzgg444 3y ago
[dead]
jen20 3y ago
To be more blunt about it: if the person writing the code is not the one on the pager at 3am, they have no serious incentive to make it correct or resilient. This is why "you write it, you run it" is so important - the most reliable software is the software never written, but if something must be written, it's important that all incentives are aligned for it to work right. Of course, this is only at the operational end - lack of incentive alignment is rampant in "product" organisations too.
- convolvatron 3y ago
  as a software developer, every place I've tried to work that's "you write it, you run it" turns into me just spending all my time running the code as it already existed, with actually trying to improve reliability as kind of a bonus 10% task that no one ever talks about or asks after.
  - ElectricalUnion 3y ago
    It always depends on aligned incentives, for some very specific lines of work and very specific people, they will totally intentionally upkeep known bad software without improving it too much because it's somewhat a guarantee of very profitable overtime pay.
- mschuster91 3y ago
  > To be more blunt about it: if the person writing the code is not the one on the pager at 3am, they have no serious incentive to make it correct or resilient. The problem is in 99% not that the developers don't want to do correct code. The problem is that product/project management doesn't allocate the time and budget for clean development practices, proper QA, and refactoring because their metrics are revenue, releases/timeframe, or similarly useless/unsustainable.
  - whstl 3y ago
    Can 100% confirm. Last place that had that pager duty tried to throw this shit on me. Product Owner was constantly denying time to build monitoring. Everything in this loop was misaligned and rigged against devs. The only power I had as was to quit. Now that this is over and traditional Ops is back and called SRE, it is Product Owners, Support, Managers, Developers and CTOs screaming all at once at their team. Let's see where this will lead us.

groestl 3y ago

I guess it's: You change the way you think about those metrics if you're the one being called at 2AM Saturday night.

Etheryte 3y ago

Your application architecture dictates how it should be deployed and the other way around, if you try to decouple the two you're bound to run into issues. Depending on what your application does, high throughput with some loss might be ideal, or you might need at least once delivery instead while sacrificing throughput, or any other dynamic. If your deployment is done by an entirely different team from the team that builds the product itself you have little hope of predictable positive outcomes without a lot of pain.

formercoder 3y ago

SRE needs authority to hand back the pagers. That’s a key aspect.

ddaaeugzzgg444 3y ago

[dead]

jen20 3y ago

To be more blunt about it: if the person writing the code is not the one on the pager at 3am, they have no serious incentive to make it correct or resilient. This is why "you write it, you run it" is so important - the most reliable software is the software never written, but if something must be written, it's important that all incentives are aligned for it to work right. Of course, this is only at the operational end - lack of incentive alignment is rampant in "product" organisations too.

convolvatron 3y ago
as a software developer, every place I've tried to work that's "you write it, you run it" turns into me just spending all my time running the code as it already existed, with actually trying to improve reliability as kind of a bonus 10% task that no one ever talks about or asks after.
- ElectricalUnion 3y ago
  It always depends on aligned incentives, for some very specific lines of work and very specific people, they will totally intentionally upkeep known bad software without improving it too much because it's somewhat a guarantee of very profitable overtime pay.
mschuster91 3y ago
> To be more blunt about it: if the person writing the code is not the one on the pager at 3am, they have no serious incentive to make it correct or resilient. The problem is in 99% not that the developers don't want to do correct code. The problem is that product/project management doesn't allocate the time and budget for clean development practices, proper QA, and refactoring because their metrics are revenue, releases/timeframe, or similarly useless/unsustainable.
- whstl 3y ago
  Can 100% confirm. Last place that had that pager duty tried to throw this shit on me. Product Owner was constantly denying time to build monitoring. Everything in this loop was misaligned and rigged against devs. The only power I had as was to quit. Now that this is over and traditional Ops is back and called SRE, it is Product Owners, Support, Managers, Developers and CTOs screaming all at once at their team. Let's see where this will lead us.