Disaster-Proofing The Cloud

As the cost and convenience benefits of cloud computing become more compelling, more and more IT departments are taking a close look at moving large parts of their infrastructure out of their data centers.

While a year or two ago it was possible to dismiss many of the cloud offerings as too new and somewhat rickety, that objection no longer applies. For the industry-leading cloud vendors, the growing pains are essentially over and the services for storage, computing, load balancing and other functions are as good or better than what most IT departments are getting out of their data centers and are offered at extremely attractive prices.

The massive barrier that remains in front of a wholesale migration of IT to cloud computing is the problem of facing the worst case: How will an IT department deal with a major outage in the cloud or in the network that connects to the cloud? This is a different issue than everyday quality. No matter how substantial a cloud offering it is, as with all computing resources, massive failure is possible. This week, the JargonSpy takes a look at the different approaches that can be taken to managing disasters in the cloud.

The first and most important step that savvy IT managers take when deciding what can be moved to the cloud is to separate infrastructure into various groups according to its importance. In every company, there is a set of applications and infrastructure so important that nobody outside the company can be trusted to run them. But for most businesses, the bulk of their infrastructure could go into the cloud. The definition for what is safe for the cloud is different for every business, but if you can live without an application for two days, it is probably safe to put it into the cloud.

So, once you have decided what you can put into the cloud, how do you manage the risk of disaster? One approach that can offer some comfort in certain situations--service level agreements (SLA) that state a level of performance that must be met and remedies in case of failure--is a non-starter for the cloud. If you take a close look at the SLAs in the cloud, you'll see that they guarantee almost nothing--not even that the service will continuously operate. The remedies are similarly weak. You may be able to cancel a contract or get your money back or get credits to pay for future services, but that's about it.

To be fair, SLAs in other areas of computing and outsourcing aren't much better. Vendors are only comfortable offering strong SLAs if they are being paid a fortune or if they have a dedicated architecture to solve a well-understood problem.