We sure are hearing the chickens running around in a panic about the dangers of cloud computing following the massive data loss involving T-Mobile Sidekick customers. And as usual, the cacophony sounds more like a bunch of pundits ruminating about the great dangers that may be ahead instead of the reality at hand.
The problem is, most of them are making zero distinction about what constitutes a cloud computing service. The Sidekick disaster was not the result of a cloud disaster. It was a centralized data center that had poor oversight.
DevCentral clears things up with its distinction between cloud services and applications:
A “cloud service” is used by IT, by developers, by the technical community at large. What consumers access is an application, and nothing more. They aren’t the user of the cloud service, they are the consumer of an application deployed in a cloud environment. Google Docs is an application. Gmail is an application. Twitter is an application. None of these are “cloud” services, even when using APIs designed to integrate them with other applications; they are still, always and forever, applications.
We do not question the severity of what happened to Sidekick customers. It looks like about 1 million people are affected. They lost it all. Pictures, calendars and a whole host of information.
These customers had no choice about what happened. They relied on T-Mobile. And T-Mobile relied on Microsoft/Danger for storing the data. This was not a cloud catastrophe. Developments continue to unfold: Hitachi Datasystems is now being fingered as the source of the problem.
But since we are on the topic, there are some basic lessons to learn in working with a cloud service provider. This is not a complete list. Feel free to add your own pieces of advice.
Lesson #1
If you are storing your data in the cloud for your customers to access, you’d better know if the company you have hired is actually the one managing your data. If your vendor is outsourcing your data to another provider, it could be a recipe for trouble.
Lesson #2
Know who you are working with and make sure there will be no surprises. Software-as-a-Service (SaaS) providers that don’t keep customers posted about changes or upgrades can be real trouble-makers. All kinds of mix-ups can occur. A SaaS vendor recently pulled this one on its users. Customers had no idea about the upgrade. They had no control.
Lesson #3
Make sure your provider has safety valves in place. How is the data backed up? Let’s say, again, that the SaaS provider does an upgrade, but there’s a nasty bug fouling things up. If the cloud configuration has a safety valve in place, then the customer can mitigate the issue pretty easily.
Lesson #4
Don’t use just one cloud service provider. Security experts make the point that you don’t put all your eggs in one basket. Look at multiple cloud service providers so that if there are issues, damage is limited.
Perhaps, overall, the greatest lesson out of the Sidekick disaster has nothing to do with the cloud at all but more about the applications that people use in the enterprise. Facebook? Twitter? Those are applications that may be more troublesome than cloud computing services because of their vulnerability to attack and lack of control over the data.
