6 ms·

Just remember that what google writes in these kind of things is not universal. It's written from their very unusual circumstances. You can certainly pick nugge

Just remember that what google writes in these kind of things is not universal. It's written from their very unusual circumstances. You can certainly pick nuggets that are more universal than others but, like in many other instances, too much unnecessary work is spent trying to imitate Google and others when it's not really needed. And no, you won't turn into Google over night, you will have time to adapt if fortune hits you. Some things are not even necessarily good advice at all, but rather a product of incentives within Google (and perhaps most tech corps) rewarding the aesthetics of "innovation".

fmbb 2y ago
I read the whole text (granted, a bit quickly) looking for weird or unnecessary advice but I cannot see any. This is a great text about considerations everyone operating software services should take to heart. It applies regardless of if you deploy a monolith or several smaller servers. If you are only one developer, it might apply in a smaller context.
- elktown 2y ago
  "If you are only one developer" suggests zero interests in being nuanced. To be clear, this linked specifically to simplicity which I'm certainly in favor of emphasizing the importance of. But IME the exact opposite happens when people try to imitate Google overall in a smaller setting, where instead too much resources are spent on meta-issues instead of the product being developed.
  - zbentley 2y ago
    I think you’re arguing with someone who isn’t here. Nobody is endorsing the practices in TFA “because it’s Google”/in order to be like Google. Sure, people elsewhere make those claims all the time, and they’re wrong, but that’s not in evidence here that I can see. The article does seem to come pretty close to universally applicable good ideas. Not because of where its author works, but because of the content.
    - elktown 2y ago
      > Nobody is endorsing the practices in TFA “because it’s Google”/in order to be like Google. Sure, people elsewhere make those claims all the time, and they’re wrong, but that’s not in evidence here that I can see. I disagree, I think we can see this time and time a again. YMMV I guess. It's an encouragement to be vigilant for over-engineering when you don't need it because you're not google. I'm not saying that the content is bad, it's a worthy read. Just don't get overeager like the OOP craze phase where would attempt to bend everything into a maze of design pattern because people took whatever books they read way too far. Most of the chapters have YAGNI parts for smaller settings, but it's still worth knowing about what the next steps are.
nvarsj 2y ago
Even within Google, this is not universal. I doubt the majority of SREs at Google have even read the "Google SRE book". On the other hand, the book has some nuggets that make it worth reading. But it should be treated as a collection of essays from some very senior SREs rather than a manual.
- elktown 2y ago
  > On the other hand, the book has some nuggets that make it worth reading Definitely! Mostly just a word of caution to not get overeager hoping to apply this everywhere, because "here be dragons".
- fl0ki 2y ago
  > I doubt the majority of SREs at Google have even read the "Google SRE book". That's absolutely true, but by design. SRE already had exceptional horizontal knowledge transfer before any book. The book was published (specifically, published) to extend that knowledge transfer outside of Google's own walls so the rest of the industry could also benefit. I was a SWE-SRE for several years and absorbed a lot just through talks and postmortems. I left Google and joined another big org that was a ... bit ... less far along in its SRE ambitions. I couldn't convince a single person to read the book, even after linking to specific sections to explain why e.g. jitter is important to have in tandem with backoff. Nobody cares, they have boxes to tick and janky bullshit to ship. Most people are not interested in learning from books these days, inside or outside Google, but at least inside Google you can learn from an unbroken lineage of experienced SREs. If you're trying to build out an SRE org in your own company, you're better off hiring one ex-Google Senior SRE than you would be if you bought everyone a copy of the book and two weeks of formal training. Actually embedding real-world experience into your teams is the most effective form of knowledge transfer available.

fmbb 2y ago

I read the whole text (granted, a bit quickly) looking for weird or unnecessary advice but I cannot see any. This is a great text about considerations everyone operating software services should take to heart. It applies regardless of if you deploy a monolith or several smaller servers. If you are only one developer, it might apply in a smaller context.

elktown 2y ago
"If you are only one developer" suggests zero interests in being nuanced. To be clear, this linked specifically to simplicity which I'm certainly in favor of emphasizing the importance of. But IME the exact opposite happens when people try to imitate Google overall in a smaller setting, where instead too much resources are spent on meta-issues instead of the product being developed.
- zbentley 2y ago
  I think you’re arguing with someone who isn’t here. Nobody is endorsing the practices in TFA “because it’s Google”/in order to be like Google. Sure, people elsewhere make those claims all the time, and they’re wrong, but that’s not in evidence here that I can see. The article does seem to come pretty close to universally applicable good ideas. Not because of where its author works, but because of the content.
  - elktown 2y ago
    > Nobody is endorsing the practices in TFA “because it’s Google”/in order to be like Google. Sure, people elsewhere make those claims all the time, and they’re wrong, but that’s not in evidence here that I can see. I disagree, I think we can see this time and time a again. YMMV I guess. It's an encouragement to be vigilant for over-engineering when you don't need it because you're not google. I'm not saying that the content is bad, it's a worthy read. Just don't get overeager like the OOP craze phase where would attempt to bend everything into a maze of design pattern because people took whatever books they read way too far. Most of the chapters have YAGNI parts for smaller settings, but it's still worth knowing about what the next steps are.

nvarsj 2y ago

Even within Google, this is not universal. I doubt the majority of SREs at Google have even read the "Google SRE book". On the other hand, the book has some nuggets that make it worth reading. But it should be treated as a collection of essays from some very senior SREs rather than a manual.

elktown 2y ago
> On the other hand, the book has some nuggets that make it worth reading Definitely! Mostly just a word of caution to not get overeager hoping to apply this everywhere, because "here be dragons".
fl0ki 2y ago
> I doubt the majority of SREs at Google have even read the "Google SRE book". That's absolutely true, but by design. SRE already had exceptional horizontal knowledge transfer before any book. The book was published (specifically, published) to extend that knowledge transfer outside of Google's own walls so the rest of the industry could also benefit. I was a SWE-SRE for several years and absorbed a lot just through talks and postmortems. I left Google and joined another big org that was a ... bit ... less far along in its SRE ambitions. I couldn't convince a single person to read the book, even after linking to specific sections to explain why e.g. jitter is important to have in tandem with backoff. Nobody cares, they have boxes to tick and janky bullshit to ship. Most people are not interested in learning from books these days, inside or outside Google, but at least inside Google you can learn from an unbroken lineage of experienced SREs. If you're trying to build out an SRE org in your own company, you're better off hiring one ex-Google Senior SRE than you would be if you bought everyone a copy of the book and two weeks of formal training. Actually embedding real-world experience into your teams is the most effective form of knowledge transfer available.