Distributed By Design

The Internet, by taking its name literally, means “the network between networks”. 40 years ago today, the Men and Women that first started implementing the technologies that grew up to be the Internet didn’t want to create one network- they wanted to unify distributed networks redundantly. They wanted to do it this way so that a problem on one network, had literally no impact on other networks – and especially no impact on the Greater Network.

Yet humans are congregational, fashionable beasts. Humans, in general, want to be where there are other humans- even virtually. They want to be a “part of something”. They want to be on Facebook or MySpace. They want an iPhone. They want a Gmail account. They want to be LinkedIn. They love fads and the feeling of faux exclusivity that they bring, like Twitter. They fight against distribution.

The Fallout of Centralization

When Gmail is offline for a few hours, it makes international news. Millions of people across the globe are without e-mail! Crisis! Panic! When Facebook “gets a virus”, it’s international news! Millions of people are at risk! Crisis! Panic! When Twitter gets knocked offline, it’s international news! Millions of people can’t tell each other what they’re eating! Crisis! Panic!

Why won’t they get their e-mail from a more local provider? Why won’t they get other services from a more local provider? Why do people by Macs? Why do people like malls? They fight against distributed designs, and try to pull things together. “One-stop shopping” to a network neophyte is all giggles and rainbows- To a network architect it’s “bad design”.

Internet history is littered with fads and centralized solutions that inevitably fail to retain attention after the Next Big Thing arrives: But distributed solutions tend to last much much longer. Why?

The Argument for Centralization

There’s only one reason Google loses more money than my lunch cost every time someone watches a YouTube video: Control. Companies offer centralized services so they can control their users, their content, and their market. Facebook doesn’t care about user privacy or quality services, they care about making money (or, in their case, losing less money). They want you to be on their site as often and for as long as possible, and they’ve already sold your information in order to fund more gizmos and whirligigs (“apps”, they call them) to keep you coming back and sticking around. Control.

If Facebook was distributed – anyone could put up their own Facebook-compatible site, and allow other geographically-similar people to use it – how would they exercise control? How would they censor you, collect your personal data and sell it? How would they push you the latest version of your favorite whirligig? How would they profit off of you (or prevent someone else from profiting off of you)? Control.

While Gmail is a centralized interface to a distributed system (collectively known as “e-mail”), they’d just love it if everyone used Gmail and there was no distributed e-mail system. They mine your e-mail for keywords to target ads at you, making truckloads of money at the expense of your privacy- Ads that companies pay a premium for because Google can already “guarantee” you’re interested. Control.

The Argument for Distribution

Keeping components small, simple, and “close” is a doctrine of many disciplines, and is imperative for “critical infrastructure”. I have more than one client that intentionally buy equipment from multiple vendors, to reduce risk of single-vendor product failures. Several only update a fraction of systems and application software to new versions at a time, to reduce risk of debilitating bugs (one client, literally, has some 8 year-old operating systems running unpatched for this reason). More, and more institutions have multiple WAN (“Internet”) connections, from multiple providers, to reduce risk of single-provider failures.

Distributed infrastructure is more about “us” (the global network users)  than “you” (the individual). You don’t care whether Gmail (with a few million users) is down, or whether your ISP (with a few thousand users) is down: all you care about is that you can’t get to your e-mail. Because of this, it’s hard to convince “you” that distributed is better. You, the individual, don’t care about network survivability or how many other people are impacted- you only care about yourself, and your inability to access your mail.

Would you like to travel to your State capital to go to a centralized hospital? How about to the National Library to check out a book? When it comes to travel-related logistics, most people go “duh, local hospitals and libraries and schools and whatnot make tons of sense”: But once they go online – once that facade of geography is lifted – eYouSpaceFaceGoogleTwitterBookMailBay.com really is the best thing in the world, OMG?!!


So what can we do? What can you do? Appreciate and utilize local, distributed infrastructure. Don’t outsource/offshore your new whizbang application when your local hosting provider can handle it. Limit your dependence on centralized services, and find distributed substitutes where needed. Pretty much every infrastructure application has a distributed counterpart, many of them with much much less evil than their centralized cousins. I’m not saying “don’t go to website X” – I enjoy Wikipedia and CNN and all sorts of centralized information sources – but I don’t depend on them for communication, and I certainly know other places to go if they’re offline.

Distributed service architectures are about freedom and survivability. Centralized service architectures are about captivity and control. Happy Birthday, Internet. I look forward to another 40 years of architectural ingenuity.

This entry was posted in Architecture, Life, Opinions, Work. Bookmark the permalink.

1 Response to Distributed By Design

  1. Pingback: M@Blog » A Rebuttal of a Rebuttal…

Leave a Reply

Your email address will not be published. Required fields are marked *