If we were to play a little game of free association, and the word I gave you to start with was “Security,” I bet you wouldn’t say (after mentioning your favorite childhood blanket) . . . “Clouds.” Neither would I. Neither did J. Nicholas Hoover in his InformationWeek article last month, “Service Outages Force Cloud Computing Users To Rethink Tactics“.
Hoover cites several recent outages which are “forcing customers to rethink their dependency on software as a service and other cloud services, and devise strategies for the inevitable breakdowns”:
Last week, Google’s Gmail went down for two hours [August 6th and 11th], the second time in two weeks. Citrix’s GoToMeeting and GoToWebinar were temporarily unavailable [August 7th]. A month ago, Amazon.com’s Simple Storage Service was out of commission for an excruciating eight hours [July 20th].
As options for protecting yourself from SaaS failures, Hoover suggests
- “storing data with multiple service providers”
- “regularly backing up SaaS data on on-premises servers”
- avoiding cloud computing providers who are startups, and
- ensuring your SLAs have fangs.
But the reality is that servers are going to crash. Whether they’re on-premise or in a cloud somewhere, they’re going to fail at some point. The problem is not necessarily that they do, but how easy it is to maintain continuity during and rebound from the failure. Does your data vaporize when the cloud vaporizes?
When a server is on site, a good IT department will have its data and applications backed up on one or more other servers. Hardware virtualization is making this easier by allowing organizations to configure critical applications for high availability. Hardware failures can in many cases be handled with little-to-no repercussions visible to the end user.
This is ostensibly the benefit of using a service. The service provider promises to store your data and run your application for you. You don’t even have to have an IT department [no one believes this part]. The service provider can virtualize its hardware and promise you high availability.
However, backing up the applications and data on one server in your own rack with another server that is also in your own rack is one thing. Backing up the data and applications in someone else’s cloud with the same ease and integrity is another.
Hoover says it might be a good idea to “limit your dependency on cloud services for business-critical processes.” Not a bad suggestion considering the nascent stages of the industry and recent failures by solid, reputable corporations. Quoting Russ Daniels, VP and CTO of Hewlett-Packard’s cloud services business,
You need to be thoughtful about how use you use cloud resources, so that the things you do have lower risk. [. . .] Be thoughtful about where this stuff sits, rather than imagining that your existing systems will be replaced by stuff in the cloud and it will all be OK.
Our philological prejudice against thinking of clouds as secure is probably good — a fair warning about building anything absolutely essential in them . . . or at least in the clouds that aren’t ours.
