4 ms·
If you think distributed systems are somehow, some way are simpler, need less coordination, and can have less latency, I don't know what to tell you. It seems
by kissgyorgy 2y ago
If you think distributed systems are somehow, some way are simpler, need less coordination, and can have less latency, I don't know what to tell you.
It seems to me that author is convinced about distributed systems or it's their whole identity and try to come up with reasons to feel better or something.
It's not that you don't ever need distributed systems, but that's the exception when you do, not very frequent.
- hugofirth 2y agoWhat specific example or point from the blog post do you disagree with?
- kissgyorgy 2y agoLiterally all of them. Availability might have been a good point, but their other blog post somehow reaches 100% so I don't believe that either. Also not every business needs 99.9999 availability and can give up for good reasons (like cost and complexity).
- cherioo 2y agoThe author is an engineer at AWS so he has an obvious bridge to sell. That said, I do agree with the general point of needing more than one computer. But most people probably just need two, one for backup, far from “distributed system” in the traditional sense.
- kissgyorgy 2y agoOkay, that explains the whole post.
- DanielHB 2y agoI agree with all arguments made in the article from a certain point of view. And that is of a large org with several teams, his point about reducing coordination between the teams is crucial in the trade-off calculation. If you have a small org with small number of teams then you are right, but still what qualifies as "small" or "large" is not really clear and people seem to jump into the distributed systems architecture way too soon.
- p_l 2y agoI think biggest issue with the post is the use of the term "distributed systems". It makes the whole thing murkier, because it's unclear to me what exactly they advocate for. Multiple servers? Microservices? Just running multiple services but don't go too crazy on the micro? (Many "focused" small monoliths handling cross cutting concerns might be considered microservices but are not as micro as some people do, etc). Maybe running multiple servers with some distributed systems technology but not actually messing with distributed systems as product part (k8s, some easy to distribute clustering databases, etc)? All of that simply doesn't fire for me when I see "distributed systems". One could just as well read it as arguing for actually going deep into distributed systems theory and practice, integrating those ideas in your product, designing your software to use distributed persistence systems instead of single "coherent view" SQL or other database, etc.
- sam_bristow 2y agoOne point from the author that i wholeheartedly agree with is: "Simplicity is a property of systems, not components. Systems include people and processes." How you achieve that simpicity is at the heart of what I consider 'software engineering' vs just 'programming'.
- deleted 2y ago[deleted]