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

21–30 of 77 posts

Re: Distributed Systems Reading List

#21

Post by herodoturtle »

amelius wrote: post #20
herodoturtle wrote: post #19

Earlier quoted context omitted.

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…

> And with a single monolith you can comfortably handle several thousand concurrent users, not just several hundred. That depends on what kind of service you offer, of course.

Haha yes, good point - nothing with video ^_^

Re: Distributed Systems Reading List

#22

Post by herodoturtle »

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.

This too is excellent advice.

Start off with a monolith if it makes most sense (in terms of simplicity / MVP) but from the start keep future scalability in mind and plan for it.

I like this.

Re: Distributed Systems Reading List

#24

Post by deepGem »

amelius wrote: post #18
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.

The problem with scaling is that visitor count often goes exponentially. So while in the beginning everything seems calm and quiet, suddenly you can see a massive spike in interest. And if you didn't take the right measures, you might lose all that interest.

Yep, it is still a matter of abandoning the monolith and building a new scalable system in whatever fashion you choose at that time, micro services or whatever.

In today's cloud deployments where cost is not a mega concern (as compared to having physical servers in a DC), this approach is very much feasible.

You could run two systems in parallel (monolith v/s scalable) and ditch the monolith once you have the necessary cutover logistics in place.

Of course, the sooner you do this, the better and it is non trivial to figure out the 'when'

Re: Distributed Systems Reading List

#25

Post by shred45 »

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 discussed in this post. All of these links are great, but the fact is that building and operating tools like this is hard. In addition to consensus primitives, your system may need very precise error handling, structured logging, distributed tracing, resource monitoring, schema evolution, etc. In the end, I probably pause for a second too long when answering that question, but I don't think its because of a lack of experience, quite the opposite!

Re: Distributed Systems Reading List

#26

Post by iamvnraju »

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.

And most of the time a distributed system just ends up being a distributed monolith.

Re: Distributed Systems Reading List

#27

Post by atleta »

amelius wrote: post #18
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.

The problem with scaling is that visitor count often goes exponentially. So while in the beginning everything seems calm and quiet, suddenly you can see a massive spike in interest. And if you didn't take the right measures, you might lose all that interest.

That's what startups are seeking, but it's not that often at all. Also, exponential doesn't necessarily mean "happens too fast to react". If the number of your users doubles every year, you still have exponential growth, if you only have paid users you still have a very nice growth of business and you also have time to react.

It's indeed pretty rare to see services that crumble under the exponential increase in traffic. Especially if it's not a spike from publicity (I don't know how you would say "being slashdotted" these days). It happens, but it's rare. But because it's usually newsworthy or at least interesting it gets more attention and it will feel much more of a danger than it actually is. Both for software developers and entrepreneurs (or even for the general public) it feels lame. Ha! They should have expected this! But the truth is that most of the time you should not prepare for this, because it's pretty rare, it's not even necessary for success, not even for startup scale success at the beginning.

It's pretty easy to see actually: (almost) all of today's successful services provided by startups started as monoliths (or maybe more realistically some kind of SOA, because monolith vs. microservices is really a false dichotomy). It did work a decade ago with weaker hardware, why wouldn't it work now?

Re: Distributed Systems Reading List

#28

Post by bovermyer »

herodoturtle wrote: post #22
lightlazer wrote: post #16

Earlier quoted context omitted.

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.

This too is excellent advice. Start off with a monolith if it makes most sense (in terms of simplicity / MVP) but from the start keep future scalability in mind and plan for it. I like this.

Unless, of course, you intend to cap users at a specific amount for another reason.

Re: Distributed Systems Reading List

#29

Post by calcorbin »

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?

Re: Distributed Systems Reading List

#30

Post by shred45 »

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?

It is definitely a broad term, and I think that disciplined implementation of the things that you mentioned is the real key. It just isn't as exciting to talk about.
Post reply on HN