The very public and spectacular Microsoft/Danger/Sidekick failure has been a rallying cry for those who detract as well as over-simplify Cloud Computing. A large part of the discussion has focussed on the fragility of CC services and storage, and the over-hying of CC. However, this reaction is itself anti-CC hype, failing to truly understand the implications of the failure. A recent blog entry from Dan Dilger provides a reasoned analysis that should provide a cautionary tale against:
- Assuming “if you build it, they will come” (referring to wishful-thinking RAS),
- Shrug-and-grin, fluff SLAs (referring to “SLAs” which essentially state “caveat emptor” and “we are not responsible [for anything]“)
- Traditional Browser-based CC is sufficient (with no viable service redundancy, which would increase DC costs considerably, expecting “always connected” modes for basic functionality makes little sense.
The T-Mobile Sidekick interacts with the Danger cloud services
Microsoft operates in the same manner as a Traditional Browser-based Cloud app. It expects to always be connected to Danger’s Cloud, so the device does not durably cache or otherwise store any of your data locally. When the device is power-cycled, the database is with an empty database and reloads all data from the service when it is able to reconnect.
Dilger uses iPhone as a foil for the Sidekick. The iPhone represents the opposite extreme – the device that utilises a Client-Installed, Network-Accessed Cloud application – ITunes – and the MobileMe Cloud service to sync data between the MID, a netbook/notebook/desktop device, and the Cloud. Data is durably cached and stored on the iPhone, which together with the local storage repo (the netbook/notebook/desktop device storing a copy of your content) and the Cloud, provides not only the ability to use the iPhone disconnected, but an additional level of redundancy.
I see a better path which lies between these two extremes. This path involves more efficient utilisation of client resources and SLAs that can be taken seriously. The former would not have every install of iTunes redundantly storing all music files on the clients, rather targeting each netbook, notebook, or desktop for a level of storage, or allowing one to treat a series of their personal clients as an on-premise cloud. Likewise, content can be streamed from one’s nearest storage rather than locally stored. Synchronising every file across each device is not the most efficient model. Yet some local storage and processing is necessary to make the content useful, since devices are never always connected, and the quality of that connection and location vary widely.
The latter would provide for a level of redundancy and data protection that users have come to expect from CC. Although there are a number who would attest that they “trust” providers with 2 9s reliability, or that they are comfortable with providers taking liberties with their data as they are providing them with a “service”, the same people react more viscerally to outages and failures, painting these as a CC #FAIL. The both of these extremes are daft: 2 9s reliability leaves one’s data RAS to the winds of fortune, and the failure of 2 9s Cloud services does not equate CC #FAIL. Users of CC need to take it upon themselves to understand their providers’ SLAs and, rather than wait for a failure to occur, either demand greater rigour or move to services which do. The continued exodus from Flickr is an example of this. If the “service” has no responsibility for what’s stored therein, and anyone can delete users’ data, what is the use of the “service”? Sharing must enjoy a degree of reliability, otherwise, the “service” offers nothing substantial that provides an advantage over traditional sharing forms.
Rather than ignoring the Microsoft/Danger #FAIL, or using it to detract from CC as a whole, I see the failure as exposing the fallacy of Traditional Browser-based thin architectures, and calling for greater balance between devices and the DC for CC.
Top Posts