Here at Sun, the Fallacies of Distributed Computing have long been a much-revered lesson. Furthermore, I personally think they’re pretty much spot-on. But these days, you don’t often find them coming up in conversations about building big networked systems. The reason is, I think, that we build almost everything on Web technologies, which lets get away with believing some of them.

1. The network is reliable · HTTP helps here in a couple of different ways. Most obviously, connections are brief; I’ve never seen much in the way of measurements, but I’d expect the average connection lifetime to be under a second. Compared to a traditional networked system with connections whose lifetime approximates that of the application, this moves the likelihood of experiencing a damaging connection breakdown while application code is running from “essentially always” to “rather rarely”.

Second, the clarity about GET, PUT, and DELETE being idempotent, while POST isn’t, helps hugely. Most obviously, if a GET gets a network blowup, just do it again. And if the breakage hits a POST, well, it probably only hits one, and this places very clear boundaries around the repair and recovery that an app needs to handle.

2. Latency is zero · The Web actually makes the latency problem worse, because every interchange, on average, requires connection setup/teardown. Oddly, its population of users has apparently internalized this, and is keenly aware of the difference between the normal single-digit number of seconds it takes for a nicely-functioning server to assemble request results and get them to you, and behavior under overload.

Since it’s not realistic to expect anything like keystroke-level latency across the Net, the correct engineering solution is to defuse the expectation.

3. Bandwidth is infinite · Once again, the Web has been a wonderful teacher of networking realities to the non-technical. Time after time, you’ll see messages, between computing civilians, of the form “Sorry that this picture is so big” because they know perfectly well that it’s going to slow down the experience of seeing it.

4. The network is secure · This is probably the fallacy least-well-addressed by the Web. True, people have become more aware that There Are Bad Guys out there, and they need to be careful. But not nearly enough.

Also, let’s grant that TLS, properly deployed, has been pretty well Good Enough to run apps in a mostly-secure way in a hostile environment. But who among us would be surprised if someone turned up a catastrophic flaw, perhaps not in TLS itself, but in one or two widely-deployed implementations? Who’s to say that someone hasn’t, already?

Anyhow, the Web technologies mean that application builders can survive even while subject to one or more of The Fallacies. But not this one.

5. Topology doesn't change · By making almost all our apps Web-based, and thus having everyone address everything with URIs, we all agree to share solutions to routing and addressing problems; solutions provided by the DNS, the network stack, and the Internet backbone operators. This doesn’t mean the solutions are easy or cheap or perfect; it just means that application builders almost never have to think about the problem.

6. There is one administrator · Well yeah, there isn’t. But who cares, any more? Web architecture makes addressing decentralized. Thus when an administrator screws up, or imposes policies that seem good to him or her and insane to you, the damage is limited to that person’s URI space.

Also, Web architecture, which requires that you talk about things in terms of the URIs you use to address them and the data formats you use to transmit them, makes it a whole lot easier to achieve administrative coherence even when there are millions of administrators.

7. Transport cost is zero · (See #3 above.)

8. The network is homogeneous · This is perhaps the Web’s single greatest triumph. For decades we thought we could extend object models and APIs and lots of other programming concepts over the network. This was a fool’s errand, because all you can do with a network is send messages over it.

The Web doesn’t do APIs and object models, it’s just a set of agreements over what messages you’re going to send and what messages expect back in return. Which, as a side-effect, makes heterogeneity a non-issue.

History · Did TimBL and Roy Fielding and Marca and those guys think, when they were pasting together the Web, “We’re about making those Fallacies of Distributed Computing irrelevant”?

I doubt it; they were just trying to ship hypertext around.

Conclusion · If you’re building Web technology, you have to worry about these things. But if you’re building applications on it, mostly you don’t.

Well, except for security; please don’t stop worrying about security.