What to do if your cloud provider disappears

Software developer Christopher Shockey saw the first signs of trouble in late 2008. A sales rep who had always represented Web application development provider Coghead was now calling on behalf of Coghead's much larger rival Salesforce.com.

Soon, other sales reps left, and Coghead slowed new releases to its development platform. In December, CTO Greg Olsen wrote on the Coghead blog that the company was looking for more funding.

Then, on Feb. 18, 2009, came the death knell, in an e-mail to customers announcing Coghead was ending its cloud-based development platform service immediately "due to the impact of economic challenges." ERP giant SAP bought Coghead's intellectual property but pulled the plug on the development platform, giving customers until April 30 to retrieve their applications and data.

It took about 4.5 person-months for Shockey, founder and principal of Hekademia Consulting, to port his CRM application from Coghead to Intuit's QuickBase database. While he's philosophical about the forced migration, it's a stark reminder of how quickly a cloud vendor can go under.

In August 2008, the shutdown of online storage vendor The Linkup (formerly known as MediaMax) spurred a nasty online fight over who was responsible for losing customer data: The Linkup or Nirvanix, another firm spun from the same parent company. In March 2009, Hewlett-Packard shuttered its Upline storage service. Such failures raise the question of whether you can trust cloud-based storage providers -- or any cloud-based provider.

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.

Page Break

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 APIlet 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.

Page Break

Because Salesforce.com's Apex is Java-like, you may have "a fighting chance of porting it to another platform," says Ben Bloch, an independent technology consultant. It might be possible to reuse some logic, user interface, and other elements, but the developer would still have to redo a lot of work already conducted on the Salesforce platform, he says. This includes, he says, not only reconstructing the data required by the application but designing and implementing data and other models that describe the application and its data relationships.

Peter Coffee, Salesforce.com's director of platform research, downplays the porting effort. The Apex development language was designed to be similar enough to Java that it will require only an "insignificant portion of project cost" to translate the components written in Apex and using the company's Visualforce user interface builder to a new target platform, he says. What would take more work, he says, is writing new code to perform functions written to the Force.com API.

Another challenge is recovering the business logic and user workflow included within an application. In his latest development effort, Hekademia Consulting's Shockey is "making extensive use of QuickBase formula fields to create and update this process data, so that if we needed to export our data ... I will at least have the process information within my data model," he says. However, because the actual business logic is embedded within the field formulas of the database, "I would [still] likely lose that logic if we changed systems" again from QuickBase.

The use of open Web standards is, of course, the holy grail that would let any IT organization easily move an application from one cloud platform to another or to its own datacenter. One cloud platform shows how this could work: Because the SugarCRM open source CRM application is built on open standards such as the PHP scripting language and the MySQL open source database now owned by Sun Microsystems, moving an application is as easy as taking a snapshot of your data on the Sugar platform, along with any customizations or application add-ons, "wrapping it on a disk," and uploading it to the server of your choice, says Martin Schneider, SugarCRM's director of product marketing.

Whatever platform you choose, Shockey recommends that developers have a contingency plan for porting their applications, geared to the amount of advance notice the provider promises to give developers it if goes under. Before committing to a cloud development platform, Bloch recommends quizzing a provider not only about the strength of its business model and finances, but its processes for releasing new versions of its APIs and for providing technical and other support to developers.

Decide what you're willing to risk
Some customers -- especially those who have lost data to a defunct provider such as The Linkup -- swear they'll never trust the cloud again. For others, it's more a matter of balancing the benefits (low upfront cost and ease of deployment) with the risks (vendor lock-in).

Committing to a cloud platform is no more of a risk than writing to the Microsoft Windows API, say Steven Harper, the CEO of Plan2win, a developer of sales software. Assuring his apps would run on new versions of Windows "became very very cumbersome ... and very costly to support," he says. "There's almost an infinite number of configurations you can have on a personal computer, with the variety of operating systems" and related software such as Microsoft development frameworks that can drive up support costs, he says.

So he now writes applications for the Salesforce.com platform, and he doubts the company would ever abandon its developers. "There would be such negative publicity and blowback from the customers ... I just can't believe anybody would be that stupid," he says.

But providers do fail, no matter their intentions. At Hekademia Consulting, Shockey has made the best of the death of Coghead, using the porting process to consolidate more functions into fewer applications. He even added capabilities such as calendaring that weren't available in Coghead. What's more, he says, QuickBase is a bit cheaper than Coghead, and his customers are more comfortable dealing with giant Intuit than either Coghead or his own small company.

Unless and until data, application, and other cloud service standards become universal, there is no absolute guarantee you can work around the death or unavailability of your cloud provider. The best bet is to keep an eye on your vendor's balance sheet and to keep your local backups current.

"I still think the software-as-a-service model is where it's all going," says Shockey. "We've just got a bit of a shakeout of platforms right now."