Distributed systems for fun and profit (free ebook)

http://book.mixu.net/distsys/

by phiggy • 13 years ago

77 14 13 years ago

book.mixu.net

You can get more practical information by reading the wikipedia page on distributed computing. There's many different models of distributed systems that this ebook doesn't touch on. For example, several of the systems i'm familiar with don't require consensus, consistency or time ordering (or they're resolved based on certain assumptions about the model, data, application, etc)

zdrummond• 13 years ago

I disagree. I think it is clear that this "book" is aiming to be an introduction to Distributed systems. As such, focusing on some models and excluding others does not decrease its value.

The real question of value is; does it allow someone outside the field to come up to speed and have enough understanding, that they can venture out and learn about alternate models (such as ones that don't require consensus).

mixu4• 13 years ago

Any chance you could be more specific as to what you feel is missing in the book?

Granted, "distributed systems" is a enormous topic that no book can cover fully, but I have tried to cover things like:

- key papers (Lamport; Fischer, Lynch and Patterson; Chandra and Toueg etc.)

- topics relevant to highly successful commercial systems (e.g. 2PC => *SQL systems, Paxos => GFS/Chubby, ZAB => Zookeeper, Dynamo => Riak/Voldemort/Cassandra)

- and recent topics such as CRDTs and the CALM theorem.

Having a sense of how time, consistency and fault tolerance have been explained and handled is (I think) a prerequisite to more advanced topics, but I'd be interested in hearing what parts you'd feel need improvement because some day (~ some years from now) - I will revise the book and it would be nice to have a solid list of issues to revise.

chubot• 13 years ago

I'm not sure exactly what the grandparent comment meant, but I think I have an idea. I only skimmed the contents so take this with a grain of salt.

Your book is focusing on a pretty narrow part of distributed computing. I would rename it "Managing State in Distributed Systems", or "Distributed Storage Systems". Your examples are Bigtable and Dynamo, which fall in this category.

The book seems to be aimed at sort of a "beginning" audience. But the topics are inappropriate for a beginning audience, and skewed for an expert audience.

Real distributed systems try to be stateless wherever possible. You need "big computer science" to manage state in distributed systems, but most code in a distributed system should not manage state. These techniques should be confined to specialized storage systems.

Here are some examples of real world distributed systems that don't use the described techniques to manage state:

  - clusters of stateless web servers + single master database (99%+ of websites people use)
  - message queue / work queue.  A single machine can productively manage 1,000 - 10,000 stateless workers, depending on the workload.
  - MapReduce
  - Original GFS
  - Napster
  - BitTorrent (tracker and trackerless would be interesting to write about)
  - BitCoin

The title seems to imply a practical bent, but it seems more like a collection of ideas (which are important and interesting, but not really what engineers need to know. IMO the #1 skill for distributed computing is to be competent at BOTH programming a single computer and at system administration).

If I wanted to be harsh, I would say it looks like you read a bunch of stuff and didn't work with it or implement it? At the very least, the ideas don't seem to be put in the context of commonly deployed distributed systems.

People need to understand these simpler, more robust, and more performant techniques, and how to apply them to their specific problem domain, rather than blindly throwing consensus at every problem (which is a disturbing trend I've seen).

strlen3• 13 years ago

Couple of suggestions:

1) I'd avoid mentioning CAP and FLP impossibility result much further in, this is like starting a discussion of mathematical logic or Computer Science with Godel's Incompleteness Theorem.

I'd definitely cover vector clocks and causality before: you really need this background in order to understand CAP/FLP. You may want to take a look at the approach Vijay Garg takes in his book:

http://www.amazon.com/Elements-Distributed-Computing-Vijay-G...

(E.g., use of vector clocks for proofs)

2) Don't over-focus on "webscale" (using the term only semi-ironically here) projects (I say this having contributed to multiple such projects). NFS, AFS, and CodaFS all raised very interesting questions about distributed state and disconnected operations. You may also note how some of the authors on the Plan9 (9fs, 9p, fossil) papers overlap with authors of some of the Google papers. "Mobile sensor networks" have been essentially an excuse to build distributed systems. Chord, Pastry, and Kademelia (sp? The System that Bittorrent uses) -- are actually far more truly "distributed" than many webscale systems (consistent hashing is a very simple DHT). Finally, don't forget that the Internet itself is a distributed system: the most successful eventually consistent, highly available distributed database is DNS.

I'd actually cover the web-giant infrastructure paper stuff a bit later on. While the Dynamo paper did have some novel contributions (regarding Gossip and anti-entropy), it's not what it's notable for: what's far more interesting in that paper is the way these concepts fit together.

I'd even hold my nose and cover CORBA: it's an interesting example in that it handled everything by the textbook, but failed due to complexity costs it had to incur in order do that. Far simpler RPC protocols and Web Services prevailed at the end by promising less. JINI may also be interesting to cover -- excellent system, far too ahead of its time -- Java VM and ecosystem were immature (anyone else remember Blackdown JDK on Linux?), marketed incorrectly (driver architecture?) to a market that wasn't ready for it (this is when dot-com startups could suffice on buying a couple of E10Ks or high-end Alphas).

3) This is an enormous and highly ambitious project and I commend you from embarking on it (I just re-read http://paulgraham.com/hs.html -- see the part about hard problems and ambition). Nonetheless, if you're serious about this, be sure to get plenty of editors -- there's a lot of room to make subtle mistakes (which I've done all the time). A lot of this can be genuinely confusing -- e.g., partitions aren't just due to networks, but at the same time not every type of a failure or a stop is a partition (I used to site GC pauses an example of a partition, but now I'm not so sure).

I'd help, but I've neither the cycles nor the habit of academic rigor; if you're still in touch with any profs from your uni, they could either help themselves or point you to others.

tantalor• 13 years ago

The ePub chapter titles are "The third chapter", etc. Would be better if they used the actual chapter titles, like "Time and order".

http://i.imgur.com/T6YtJ0F.png

abofh• 13 years ago

As a 'bottom up' interviewer, I'm often criticized for the same approach you're taking. You might do well to start at the highest level (and pseudo code) and work your way down to the clock.

In fact, I'd start with bad examples of temporal messaging and work down from there: ("Debit 250", to "Debit account A 250", to "Debit account A for 250 at timestamp Y", to "Debit account A for 250 at signed timestamp Y") -- showing bad is often more effective than explaining good.

Distributed systems for fun and profit (free ebook)

Related Stories