4 ms·

My read on the article was that much more was related to each team being on their own to set up & drive their pipelines, operate their own services, and there b

My read on the article was that much more was related to each team being on their own to set up & drive their pipelines, operate their own services, and there being a lack of commonality/shared experience. A vast number of the software engineers don't get the ops (running software) stuff hardly at all & half of them can sort of play along, hack stuff into place. The engineers on product teams who do know how to do things meanwhile don't get all the constraints, best practices, ideas that other various DevOps folk have done & have their own wants/desires/expected ways of doing things, so they end up creating their own very unique sub-ways of doing things within the org. None of these practices converge on regularity or consistency with what DevOps machinery ends up being built. What we do have often is just a random pile of containers and scripts that a couple people sort of know decently & everyone else suffers through & survives within. Almost never does it look like any other company's devops kitchen. SRE doesn't scale because it's an every now and then thing, and few people notice or care about the difference between a well-built corporate citizen that runs well & is monitored & operated according to whatever the in-power SRE cabal wants. People start to care only if things are going bad, either via services not building/integrating/deploying/running as well as they should, or from too much confoundedness/general head scratching by either the SRE or regular engineers. SRE is not a priority, it's not practiced regular, it's only an every-now-and-then thing, so we don't have the chance to get good, to institutionalize the right ways of doing things. That's what the articles is discussing. Not the rest of the everyday normal software development rushing-bedlam you describe.

klodolph 5y ago
> SRE doesn't scale because it's an every now and then thing, ... That's the part that doesn't scale... tacking on SRE at the end, or doing it every now and then. The reason people don't care about the software being a "well-built corporate citizen" is because they care more about shipping features. If you have an SRE team that will say "no" to you when you try to ship new stuff, you'll eventually figure out a way to build new things in a way that the SRE team will say "yes". When I say "no", that could be a hard pushback like "no, that's not getting shipped" or it could be an answer like, "no, the SRE team will not support that, yet." These kind of decisions need to be made at a high level, because everyone in the institution is typically operating with the wrong incentives. That's why you end up with a random pile of containers and scripts. It doesn't have to end up that way, even when you have microservices. > That's what the articles is discussing. Not the rest of the everyday normal software development rushing-bedlam you describe. I disagree with the article, so necessarily there are going to be differences between what I'm saying and what the article is saying.
rhizome 5y ago
Everything in your second paragraph points to companies that either through hiring, firing, or attrition have successfully excised all real systems expertise from the entire company. This isn't the fault of any ops methodology, so let's maybe call it "shrug-ops." >few people notice or care about the difference between a well-built corporate citizen that runs well & is monitored & operated according to whatever the in-power SRE cabal wants QED
- rektide 5y ago
  this is a good insight but i think it overattributes to malice that which i see as defined by unseeability. most of the company lacks the techical appreciation to understand & grasp the tech ecosystem challenges they face. a sizable amount of the techies also help make up this group of people lacking the ability to discern. i like your post generally & think it's a good contribution. shrug-ops is a great name too, one with real value & that describes. but also i sympathize with how hard it is to acquire, gain, develop, & nurture this only-sometimes-rarely called upon skillset of nurturing & advancing systems competencies. it's not that people dont care. it's that this is a rarely practiced, harder to discern the success/quality of competency.

klodolph 5y ago

> SRE doesn't scale because it's an every now and then thing, ... That's the part that doesn't scale... tacking on SRE at the end, or doing it every now and then. The reason people don't care about the software being a "well-built corporate citizen" is because they care more about shipping features. If you have an SRE team that will say "no" to you when you try to ship new stuff, you'll eventually figure out a way to build new things in a way that the SRE team will say "yes". When I say "no", that could be a hard pushback like "no, that's not getting shipped" or it could be an answer like, "no, the SRE team will not support that, yet." These kind of decisions need to be made at a high level, because everyone in the institution is typically operating with the wrong incentives. That's why you end up with a random pile of containers and scripts. It doesn't have to end up that way, even when you have microservices. > That's what the articles is discussing. Not the rest of the everyday normal software development rushing-bedlam you describe. I disagree with the article, so necessarily there are going to be differences between what I'm saying and what the article is saying.

rhizome 5y ago

Everything in your second paragraph points to companies that either through hiring, firing, or attrition have successfully excised all real systems expertise from the entire company. This isn't the fault of any ops methodology, so let's maybe call it "shrug-ops." >few people notice or care about the difference between a well-built corporate citizen that runs well & is monitored & operated according to whatever the in-power SRE cabal wants QED

rektide 5y ago
this is a good insight but i think it overattributes to malice that which i see as defined by unseeability. most of the company lacks the techical appreciation to understand & grasp the tech ecosystem challenges they face. a sizable amount of the techies also help make up this group of people lacking the ability to discern. i like your post generally & think it's a good contribution. shrug-ops is a great name too, one with real value & that describes. but also i sympathize with how hard it is to acquire, gain, develop, & nurture this only-sometimes-rarely called upon skillset of nurturing & advancing systems competencies. it's not that people dont care. it's that this is a rarely practiced, harder to discern the success/quality of competency.