Fallacies of Distributed Computing

I was cleaning out a stack of old papers and ran across a copy of “The Eight Fallacies of Distributed Computing” that I’d made back in 2004. As Wikipedia puts it, a guy by the name of Peter Deutsch “asserted that programmers new to distributed applications invariably make a set of assumptions… and these assumptions ultimately prove false, resulting either in the failure of the system, a substantial reduction in system scope, or in large unplanned expenses required to redesign the system to meet its original goals.”

1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn’t change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogenous.

The first four were Bill Joy & Tom Lyon’s “Fallacies of Network Computing,” and James Gosling added the eighth, but regardless, I think they’re just as true today as when they were written in 1994. Look at storage technologies that run over data networks and cannot handle a single dropped packet. Or the number of applications, web or otherwise, that have no provisions for secure network transport, no SSL, nothing. Public cloud computing breaks #7, in all senses of the word “cost” (computer science or financial). And mobile computing singlehandedly challenges all of these assumptions, with unreliable, slow wireless connections that are inherently insecure, cost money per byte transmitted, traverse multiple carrier networks, and are not stable because the endpoint is never in the same spot.

At VMworld US 2011 a number of attendees criticized Paul Maritz for talking about computing history during his keynote. I see it the same way George Santayana did, when he said that “those who cannot remember the past are condemned to fulfill it.” Modern programmers, modern IT staff face very few new challenges, ones that were not fundamentally present two or more decades ago. Anybody who says otherwise is misinformed, a marketer, or a moron. Perhaps by taking a few minutes to be less ignorant, perhaps by actually learning something about the past, we wouldn’t still be fighting these decades-old problems in brand-new software and in brand-new systems.