[HN Gopher] Notes on Distributed Systems for Young Bloods
       ___________________________________________________________________
        
       Notes on Distributed Systems for Young Bloods
        
       Author : doesntmeananyth
       Score  : 70 points
       Date   : 2024-09-02 17:23 UTC (5 hours ago)
        
 (HTM) web link (www.somethingsimilar.com)
 (TXT) w3m dump (www.somethingsimilar.com)
        
       | sillywalk wrote:
       | Previous discussions from way back:
       | 
       | https://news.ycombinator.com/item?id=5055371
       | 
       | 346 points|jcdavis|12 years ago|42 comments
       | 
       | https://news.ycombinator.com/item?id=12245909
       | 
       | 386 points|kiyanwang|8 years ago|133 comments
        
       | turtledragonfly wrote:
       | Excellent list; I like the pragmatic and down-to-earth
       | explanations. No buzzwords, no "microservices" (:
       | 
       | I'd say that a good amount of this advice _also_ applies to one-
       | box systems. There can be lots of kinda /sorta distributed sub-
       | components to consider -- could be IPC between programs, or even
       | coordination amongst threads in one process. Even the notion of
       | unified memory on one box is a bit of a lie, but at least the
       | hardware can provide some better guarantees than you get in
       | "real" distributed cases.
       | 
       | A lot of the advice where they compare "distributed" to "single-
       | machine" could pretty well apply to "multi-threaded" vs "single-
       | threaded," too.
       | 
       | And on another axis, once you make a program and give it to
       | various people to run, it becomes sort of a "distributed"
       | situation, too -- now you have to worry about different versions
       | of that program existing in the wild, compatibility between them
       | and upgrade issues, etc. So things like feature flags, mentioned
       | in the article, can be relevant there, as well.
       | 
       | It's perhaps more of a spectrum of distributedness: from single-
       | CPU to multi-CPU, to multi-computer-tightly-connected, to multi-
       | computer-globally-distributed, with various points in between.
       | And multiple dimensions.
        
       | sulam wrote:
       | One that is not mentioned here but that I like as a general
       | principle is that you cannot have exactly once delivery. At most
       | once or at least once are both possible, but you have to pick
       | your failure poison and architect for it.
        
         | Spivak wrote:
         | Yes but in practice this is not a problem because the bits that
         | are impossible are so narrow that turning at-least-once into
         | exactly-once is so easy it's a service offered by cloud vendors
         | https://cloud.google.com/pubsub/docs/exactly-once-delivery
        
           | sulam wrote:
           | Those only work because they have retries built in at a layer
           | that runs inside your service. You should understand this
           | because it can have implications for the performance of your
           | system during failures.
        
           | jclulow wrote:
           | "Redelivery versus duplicate" is doing quite a lot of work in
           | there. This is an "at least once" delivery system providing
           | building blocks that you can use to cope with the fact that
           | it's physically impossible to prevent redelivery under some
           | circumstances, which are not actually that rare because some
           | of those circumstances are your fault, not Google's, etc.
        
       | languagehacker wrote:
       | I share this doc with the most promising people I get to work
       | with.
       | 
       | When I worked at Lookout, Jeff Hodges shared this essay as a
       | presentation, and ended it with a corollary: don't pretend that
       | engineering isn't political. People that think that the code
       | speaks for itself are missing out on important aspects of how to
       | influence the way things are built and how to truly get results.
       | 
       | Ten years later, and there are few people who still so concisely
       | understand the intersection of engineering leadership and those
       | table-stakes capabilities we normally associate with SRE /
       | DevOps.
        
       | abatilo wrote:
       | I had the pleasure to briefly work with the author of this post
       | within the last few years. Jeff was one of the most enlightening
       | and positive people I've ever learned from. He was refreshingly
       | honest about what challenges he was having, and delightfully
       | accessible for mentorship and advice.
        
       ___________________________________________________________________
       (page generated 2024-09-02 23:00 UTC)