Ask HN: How did you learn distributed computing/systems?
please suggest any tutorials/vidoes/books or courses you used to learn and implement large scale distributed systems. I'm looking for something more practical with code/examples.
8 comments
Did an MS in CS ;-)
MIT OCW
http://ocw.mit.edu/courses/electrical-engineering-and-comput...
First start on the OCW course work. The terminology, basic algos, etc. are an important base to build - so you are able to build on other work, and not reinvent the basics.
Large scale distributed systems are HARD problems to solve.
The only way you can learn is to start by coding up the simple problems and getting to the bigger problems.
If you're a masochist, join someplace where they need to debug and maintain high scale distributed systems. The day you start solving multi-system deadlocks & data integrity you're getting there :)
And read http://eferm.com/implementing-durability-for-in-memory-datab... to get an idea of how to concurrency affects everything!
Books & Pubs
http://en.wikipedia.org/wiki/Distributed_computing#Reference...
http://en.wikipedia.org/wiki/List_of_important_publications_...
[edited formatting]
MIT OCW
http://ocw.mit.edu/courses/electrical-engineering-and-comput...
First start on the OCW course work. The terminology, basic algos, etc. are an important base to build - so you are able to build on other work, and not reinvent the basics.
Large scale distributed systems are HARD problems to solve.
The only way you can learn is to start by coding up the simple problems and getting to the bigger problems.
If you're a masochist, join someplace where they need to debug and maintain high scale distributed systems. The day you start solving multi-system deadlocks & data integrity you're getting there :)
And read http://eferm.com/implementing-durability-for-in-memory-datab... to get an idea of how to concurrency affects everything!
Books & Pubs
http://en.wikipedia.org/wiki/Distributed_computing#Reference...
http://en.wikipedia.org/wiki/List_of_important_publications_...
[edited formatting]
Distributed systems are just parallel systems in which any operation can fail.
There's a lot of boxed strategies you can use and literature you could read, but understanding the above is half the battle. Therefore I'd recommend anyone starting out to brush up on concurrency first.
There's a lot of boxed strategies you can use and literature you could read, but understanding the above is half the battle. Therefore I'd recommend anyone starting out to brush up on concurrency first.
I'd known, theoretically, about them for some time, but my first crash course was when I had to build (what I have labelled) a reverse-chat application for a very large government customer.
I was tasked with building an application that would allow a central presenter the ability to 'distribute' his chat messages out to as much as 5,000 users. The users could reply, but they would be moderated (and aggregated) by a team of n moderators (where n happened to be 3). User comments would be 'promoted' to the presenter, and the questions wouldn't show up on the screen unless the presenter responded to them.
The constraints were ridiculous. I had to build this app with Java, to be hosted on BEA WebLogic application server, and would be surfaced as a portlet on a BEA WebLogic portal. I was not allowed to make any changes to any existing databases already present though after some thought, I was able to get an Apache Derby database approved.
Long story short, the product was built, yadda yadda. After they'd used it a few times, some of the constraints were removed, and I was able to migrate it to a load-balanced platform. Of course, if you load balance an embedded database on two different servers, what happens is each node writes to its own data store, and that means that the users on side 1 are able to see side 1 chat, and the users on side 2 are able to see the side 2 chat.
So what I needed then, was some way for them to communicate. Since I'm tired of typing, I ended up having to write a bridge layer (with JMS) that communicated updates across the board, and then I ended up writing a task queue that allowed for components to be pushed into a queue, to prevent congestion.
I was tasked with building an application that would allow a central presenter the ability to 'distribute' his chat messages out to as much as 5,000 users. The users could reply, but they would be moderated (and aggregated) by a team of n moderators (where n happened to be 3). User comments would be 'promoted' to the presenter, and the questions wouldn't show up on the screen unless the presenter responded to them.
The constraints were ridiculous. I had to build this app with Java, to be hosted on BEA WebLogic application server, and would be surfaced as a portlet on a BEA WebLogic portal. I was not allowed to make any changes to any existing databases already present though after some thought, I was able to get an Apache Derby database approved.
Long story short, the product was built, yadda yadda. After they'd used it a few times, some of the constraints were removed, and I was able to migrate it to a load-balanced platform. Of course, if you load balance an embedded database on two different servers, what happens is each node writes to its own data store, and that means that the users on side 1 are able to see side 1 chat, and the users on side 2 are able to see the side 2 chat.
So what I needed then, was some way for them to communicate. Since I'm tired of typing, I ended up having to write a bridge layer (with JMS) that communicated updates across the board, and then I ended up writing a task queue that allowed for components to be pushed into a queue, to prevent congestion.
I learned about distributed computing in the '80s by writing a lot of small client server applications, tearing apart early chat systems, looking at the internals of NFS, etc.
Pick some current distributed system you find interesting and write a simple version of it. You probably can hack together a lightweight dropbox clone pretty easily.
Pick up a good book on network internals. You should find a lot of good information on fundamentals as well as example problems for you to work on.
Pick some current distributed system you find interesting and write a simple version of it. You probably can hack together a lightweight dropbox clone pretty easily.
Pick up a good book on network internals. You should find a lot of good information on fundamentals as well as example problems for you to work on.
I learned by founding a startup that productized a distributed system. One of the other cofounders had experience in the area, so, I guess I did it "old school" with a mentor. Highly recommended. There's nothing quite like a trial by fire when there is a fire fighter sitting next to you at the same folding table.
This site is probably the best place to start: http://highscalability.com/
I learned most of what I know from working for http://www.gemstone.com
I learned most of what I know from working for http://www.gemstone.com
Is hightscalablility.com really the best place to start?
I'd thought that reading some classic distributed computing books is a must.
I'd thought that reading some classic distributed computing books is a must.