Head in the Clouds

What does Amazon nuking Kindle copies of 1984 tell us about cloud computing? Unfortunately, quite a bit.

Working in the Cloud


I have to admit it: I’m not a huge fan of the cloud computing concept. I do understand its utility, and I can certainly see why some companies, such as Google and Sun/Oracle, might be excited by it. But the cloud model strikes me as terribly non-resilient: Wonderful when it works but disastrous when it fails–and recent headlines demonstrate quite clearly just how brittle cloud computing may be.

(If you’re still not quite sure what “cloud computing” is, Wikipedia has a rather detailed discussion of its particulars, but in short: cloud computing is a system in which computing resources are provided “as a service” over the Internet to users who do not need to have control over the technology infrastructure, or even a firm grasp of how it works. The most commonly-used example of cloud computing is probably Google Docs, offering a relatively full-fledged office suite via a Web browser.)

Cloud computing offers individuals access to data and applications from nearly any point of access to the Internet, offers businesses a whole new way to cut costs for technical infrastructure, and offers big computer companies a potentially giant market for hardware and services. All well and good, but it requires a great deal of centralization to function properly–and here’s where trouble sets in.

Kindle 2

You couldn’t have spent more than a few seconds online over the past few days and not have heard about Amazon remotely deleting copies of 1984 and Animal Farm from the Kindles of people who had purchased them. It turned out that the publisher selling this Kindle version didn’t have US rights (the copyright on the books has expired in most countries, but not in the US), and the current rights holder demanded that Amazon do something about it. Since Amazon is in constant communication with the millions of Kindles out there, they did what any centralized provider of a service could do–they zapped the infringing copies not just from the storefront, but from any Kindle on which they could be found.

Now, the Kindle is not a cloud computing system, but the Amazon-Whispernet-Kindle infrastructure mirrors many cloud features. More importantly, this incident is indicative of what kinds of trouble can emerge when we reframe “content” as “service.” As numerous pundits have noted, the physical book analogy would be Amazon breaking into your home and taking away a book you’d purchased (leaving you a refund on your desk, of course). But a Kindle book isn’t a physical book–it’s a service, one that (as the Kindle license makes clear) you don’t really own.


As Farhad Manjoo notes in Slate, there’s plenty of precedence for courts to order the removal (or even bricking) of devices attached to centralized services when there seems to be an infringement of some kind.

At least with the Kindle, you can make a backup of your downloaded files; if the Kindle was truly a cloud device, where the book file itself lived online, you may not even have that option. In either case, since Kindle books (even free ones) are wrapped in DRM, you can’t legally read them on anything else anyway. And all of this points to the real risk: when your work is treated not as content but as a service, and is subject to centralized control, it can be altered or deleted at any time. For legal reasons, for “local standards” reasons, by mistake, by malice, or simply when the system owner decides to discontinue that service.

Centralized systems like this run counter to principles of system resilience. The premise of a resilience strategy is that failure happens, and that the precise mode of failure can’t necessarily be predicted. Resilience demands that we prepare for unexpected problems so as to minimize actual disruption–minimize in terms of time, but particularly in terms of how widespread the disruption may be.

Resilience design principles include: Diversity (or avoidance of monocultures); Redundancy; Decentralization; Transparency; Collaboration; Graceful Failure; Flexibility; Openness; and Foresight. It’s easy to see how cloud computing can run afoul of many of these principles.

Centralization is in many ways the worst part. It’s the core of the cloud computing model, and anything that takes down the centralized service–network failures, massive malware hit, denial-of-service attack, and so forth–affects everyone who uses that service. When the documents and the tools both live in the cloud, there’s no way for someone to continue working in this failure state. If users don’t (or can’t) have their own personal backups, and don’t (or can’t) have other tools with which to access their backups, they’re stuck.

The cloud computing model may be a wonderful system when it works, but it’s a nightmare when it fails. And the more people who come to depend upon it, the bigger the nightmare. For an individual, a crashed laptop and a crashed cloud may be initially indistinguishable, but the former only afflicts one person and one point of access to information. If a cloud system locks up–or if a legal decision, change in ownership, or service provider whim alters the rules unilaterally–potentially millions of people will lose access.


For me, a resilient cloud would be one where the data lives simultaneously online and in local storage, and is in a format that can easily be read (and edited) by both cloud software and local applications. Simply put, it’s a retreat from thinking of content as a service. This isn’t where the computing world is heading, however, and as we’ve seen in the last few days, we may well be giving up more than we think for cloud convenience.

Working in the Cloud” courtesy Jamais Cascio
Kindle2” courtesy Jamais Cascio