What to do if your cloud provider disappears

Whether you trust the cloud to host your data, a critical application, or your entire app development effort, there are four steps you can take to make sure the death of your cloud vendor doesn't kill your business as well.

Step 1: Do a health check, and hedge your bets
The first, and most obvious, risk is the financial failure of a cloud provider. Before signing on with a cloud services provider, run the same health checks you would with any vendor, such as their revenue, profitability, cash on hand, and number of customers.

In addition, some analysts and industry reps suggest spreading the risk through the time-tested strategy of splitting your business across several competitors. This also makes it easier to push rivals for price cuts, although your total savings won't be as high because of the need to manage multiple vendors.

Step 2: Back up your cloud data
In cloud computing, providers hold your important data, servers, and even entire applications in locations you have no direct access to, often in virtualized or proprietary environments. The only way you can reach them is through the vendors' own download utilities or APIs.

So you need to be sure you have backed up your key assets -- locally or at another cloud provider. And make sure your data, virtual machines, apps, and so on are accessible at all times. For example, use establishing data retrieval methods, such as FTP, that don't require cooperation from the vendor.

In an implicit admission that their services could fail, many cloud providers make it easy to regularly back up your data the old-fashioned way: at your own site. Intuit's QuickBase Desktop service, for example, lets customers back up their data from QuickBase onto a local Microsoft Access database as often as they like.

In its off-site backup services, IBM offers SLAs guaranteeing, among other things, the number of valid and recoverable copies of the data available for recovery by the customer at any time. Salesforce.com supports both data replication and a weekly export service; its Force.com Web services API also lets customers write utilities that export (and import) data through a variety of means.

Retrieving your data is of little help if your applications can't use it. That's why it's important to ask whether your data is being stored in a standard format you can read even if the cloud provider is no longer around. For example, e-mail host LiveOffice stores customer data as .EML files usable by Exchange and many other mail clients.

While using a proprietary data format has the effect of locking in customers, some providers say they use such formats to speed performance or save disk space.

Step 3: Keep some extra capacity on tap
Another popular type of cloud computing is purchasing the use of "bare metal" servers over the Web from providers such as the Amazon Elastic Compute Cloud (EC2) service.

In the event a provider goes under, having extra capacity on tap (either at your own site or with another cloud provider) can reduce application downtime.

The growing use of virtualization makes it relatively easy to move servers from a defunct cloud provider to a new platform, since the virtualized servers exist as files that can be moved among physical machines. Retrieving an application written to a specific cloud vendor's API or development platform, though, can be significantly more challenging.

Step 4: Prepare for application portability
The most difficult challenge in the cloud is porting your cloud-based applications if your provider goes bust. Porting an application to a new cloud platform may require access to the application runtime, the application's business logic, the database supporting the application, and the data your users have already entered into the application. The more proprietary the platform used by the cloud provider and the more of the application management done by the cloud provider, the harder it can be to port the application.

Salesforce.com, for example, boasts that that it frees customers from having to buy, manage, and install CRM software on their own hardware. Once they sign up, they can access Salesforce.com, and any customizations they have made to it, over any computer with a Web browser, as well as use hundreds of applications written to Salesforce's Force.com API via the Apex development language.

However, this highly proprietary model means customers can run only Salesforce.com (including any customization they have done to the pages they use within the application) on the Salesforce platform.

Yes, tools such as the Force.com Toolkit for Adobe AIR and Flex and the Google Gears API let developers use the Force.com API to create Web applications that can run offline. But although users can make changes to data in offline mode, most of these applications rely on regular synchronization with Salesforce.com for their database, business logic, and workflow capabilities. So you're still dependent on Salesforce.com.