Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Distributed Systems Reading List

dancres.github.io

Post reply on HN
Print view View original

31–40 of 77 posts

Re: Distributed Systems Reading List

#31

Post by ystad »

calcorbin wrote: post #29
shred45 wrote: post #25

I find "distributed systems" to be a huge source of imposter syndrome. Despite having worked almost exclusively with distributed applications for several years now, it is difficult to consider myself experienced. When I'm asked if I've worked with distributed systems, I don't think they are asking me if I've managed a Hadoop cluster. They are interested in building new applications using some of the primitives discus…

I'm realizing I've only worked in distributed systems as well, but I'd never feel comfortable telling potential employers I'm an expert. Being an expert in distributed systems seems almost too broad. At a high level couldn't it be expertise at integration, accessible logging, and configuration?

Yes. The area is fairly broad. In my opinion - I think the question to ask for is: Do you have the distributed systems mindset? Not Are you an expert on Distributed Systems

Re: Distributed Systems Reading List

#32

Post by ahelwer »

deepGem wrote: post #11

I'm surprised there is no mention of the Bitcoin white paper. One of the most practical consensus protocols out there. Sure there is a lot of emphasis on the currency itself but I found the consensus protocol explanation so simple and easy to understand, as opposed to the Paxos algorithm.

Murat Demirbas has an interesting analysis that Bitcoin can be viewed as a Paxos variant with very, very expensive leader election: https://muratbuffalo.blogspot.com/2018/03/anatomical-similar...

Re: Distributed Systems Reading List

#33

Post by kortex »

herodoturtle wrote: post #19
projectileboy wrote: post #13

Great list. Only thing I’d add for the other enterprise developers out there is to first default to not building a distributed system at all, but rather build a much smaller monolith. In 25 years I’ve worked for so many orgs that wanted to build The World’s Most Scalable System for what would maybe be a few hundred concurrent users. Not surprisingly, those projects tend to tank.

Hear hear. This is really important wisdom being shared. And with a single monolith you can comfortably handle several thousand concurrent users, not just several hundred. From my humble experience I've found that it is also relatively easier to migrate an established monolith to a semi-distributed system, than it is to build and scale a distributed system from the ground up whilst at the same time trying to figure o…

The trick is to find "fault lines" throughout your monolith - places where it's easy to create separation of concerns and narrow interfaces. Maintain and document these like they are external APIs. Only pass simple data through it (serialized or anything easy to serialize).

When the time comes, cleave these chunks off and wrap them in RPC/REST/graphql.

It's good form even for monoliths since it makes for an easy interface to test.

Re: Distributed Systems Reading List

#34

Post by ahelwer »

I guess I'm pretty opinionated about this, but it was odd the author talked about the necessity of changing the way you think without also including anything about TLA+. IMO the "way you think" about distributed systems - if you want to be effective - will basically end up looking exactly like you think when writing a TLA+ spec, and learning TLA+ is a fast-track method of thinking like a distributed systems engineer. This is much, much more important in day-to-day work on distributed systems than knowing how a bunch of distributed systems algorithms work.

Re: Distributed Systems Reading List

#35

Post by hawk_ »

projectileboy wrote: post #13

Great list. Only thing I’d add for the other enterprise developers out there is to first default to not building a distributed system at all, but rather build a much smaller monolith. In 25 years I’ve worked for so many orgs that wanted to build The World’s Most Scalable System for what would maybe be a few hundred concurrent users. Not surprisingly, those projects tend to tank.

But our industry has all kinds of perverse incentives to do resumé driven development. How does one get to put paxos on their resumé if they built the correct simple solution?

Re: Distributed Systems Reading List

#37

Post by tyu2 »

ahelwer wrote: post #34

I guess I'm pretty opinionated about this, but it was odd the author talked about the necessity of changing the way you think without also including anything about TLA+. IMO the "way you think" about distributed systems - if you want to be effective - will basically end up looking exactly like you think when writing a TLA+ spec, and learning TLA+ is a fast-track method of thinking like a distributed systems engineer.…

Is it though? The hard part about distributed systems is performance in our crappy real world environment with unreliable poorly performing and faulty public internet, unreliable hardware, OSes, etc. Which is directly at odds with needing TLA+, because if you do need it, it means the complexity of the algorithms is so great, that you won't be able to keep them in your head and understand every aspect of their performance to make something work well. It's similar how people think they can just peek a random consensus algorithm they've heard is correct and easy and make a decently working distributed storage, which is silly of course, it's only good for educational purposes.

EDIT: (Ah, I see you are a TLA+ promoter, that's why you made a comment like that)

Re: Distributed Systems Reading List

#38

Post by ahelwer »

tyu2 wrote: post #37
ahelwer wrote: post #34

I guess I'm pretty opinionated about this, but it was odd the author talked about the necessity of changing the way you think without also including anything about TLA+. IMO the "way you think" about distributed systems - if you want to be effective - will basically end up looking exactly like you think when writing a TLA+ spec, and learning TLA+ is a fast-track method of thinking like a distributed systems engineer.…

Is it though? The hard part about distributed systems is performance in our crappy real world environment with unreliable poorly performing and faulty public internet, unreliable hardware, OSes, etc. Which is directly at odds with needing TLA+, because if you do need it, it means the complexity of the algorithms is so great, that you won't be able to keep them in your head and understand every aspect of their perform…

I think the hard part about distributed systems is the combinatorial explosion of possible system states, which is also common to any concurrent program. Really distributed systems is just concurrency on hard mode, where failures are basically guaranteed instead of being very rare.

I wouldn't particularly say I'm a TLA+ promoter (it's a FOSS project), any more than anyone who has a great fascination with a language/framework/algorithm/viewpoint is a promoter. We're all promoters of the memes that live inside our heads!

Re: Distributed Systems Reading List

#40

Post by dasil003 »

lightlazer wrote: post #16
projectileboy wrote: post #13

Great list. Only thing I’d add for the other enterprise developers out there is to first default to not building a distributed system at all, but rather build a much smaller monolith. In 25 years I’ve worked for so many orgs that wanted to build The World’s Most Scalable System for what would maybe be a few hundred concurrent users. Not surprisingly, those projects tend to tank.

That is a great advice. However if scalability must be introduced later on, it can be really hard as there are many features that have been added to the monolith, and refactoring it to become scalable can be a huge task. The conditions where the monolith must be converted to a scalable system should be defined as early as possible.

Designing something to be “scalable” before it’s actually established is a recipe for premature optimization at best and a poorly baked SOA with service boundaries that make change incredibly difficult at worst.

It’s important to keep mind that SOA is about scaling teams first, code second and not really about throughout per se. A share-nothing web tier plus a couple judiciously applied databases and background job queues can effectively scale a huge proportion of applications without the overhead of a full SOA.

Post reply on HN