Measures after the failure of cloud service providers

If your cloud service is closed or temporarily interrupted, what should you do to make the loss as low as possible?

In February 2009, cloud service provider Coghead in a letter addressed to customers that "due to the impact of economic challenges", the company can no longer operate, will immediately terminate the Cloud-based development platform services. Subsequently, ERP giant SAP acquired Coghead's intellectual property, but no longer supported the development platform, not only that, but also the original Coghead customers to retrieve their applications and data before April 30, 2009. In order to transplant the CRM application from Coghead to the Intuit Quickbase database, Hekademia consulting company founder and director Shockey spent almost 4 months. This is enough to warn people how fast a cloud service can fail.

The collapse of online storage maker Linkup (formerly called MediaMax) in August 2008 sparked a fierce debate online about who was responsible for losing customer data. HP closed its Upline storage service in March 2009. The end of such services has raised doubts that the ensuing collapse cannot help wondering whether we can still trust cloud-based storage providers, or any cloud-based service providers ....

Whether you're going to commit data, key applications, or your entire application development effort to the cloud, you can take the following 4 steps to ensure that the death of your cloud provider does not destroy your business.

1th Step: Prudent Choice Cloud service provider

The first and most obvious risk is that cloud providers have financial problems. Before signing up with a cloud service provider, you need to conduct a "health" check that you have signed with any vendor, such as reviewing their earnings, profitability, cash on hand and number of customers.

In addition, some analysts recommend spreading the business across multiple cloud service providers to spread risk. It's also easier to force service providers to cut prices, although your overall cost savings will not be as high as the need to manage multiple vendors.

Step 2nd: Back up your cloud data

In cloud computing, a service provider keeps your important data, servers, and even the entire application in a location that you cannot access directly, usually in a virtualized or proprietary environment. The only way you can access them is through the manufacturer's own download tools or APIs. So you have to make sure that you back up your key assets, opt to backup locally or back to another cloud service provider, and you have to make sure that you can access your data, virtual machines, applications, and so on at any time.

Many cloud servicers implicitly admit that their services may fail, so they support customers to easily back up their data on a regular basis. For example, the Intuit Company's Quickbase desktop service allows customers to back up data from Quickbase to the client's local ACCESSS database at any time.

IBM provides SLA (Service level Agreement) assurance in its offline backup service, which provides an effective and recoverable number of copies available for customers to recover data at any time. Salesforce.com supports data replication and weekly data export services, and its Web services APIs enable customers to write their own data output/input programs.

In addition, some cloud service providers use proprietary data formats to store customer data in order to improve performance or save hard disk space. Therefore, be sure to ask your cloud service provider whether to save your data in a standard, generic format. Otherwise, if they fail, you may not be able to read your application even if you retrieve the data. For example, the e-mail hosting service Liveoffice saves data as a. eml file that is available to exchange and many other messaging applications.

Step 3rd: Keep the storage space available for use at any time

Another particular cloud computing is the use of the web to purchase "bare" servers from providers such as Amazon elastic Compute Cloud (EC2) services.

Once a cloud service provider collapses, it can reduce application downtime if you have additional storage space (whether it is your own or from another cloud provider) that you can use at any time.

As virtualization becomes more pervasive, it becomes easier to move servers from a defunct cloud provider to a new platform, because virtualized servers exist in a file that can move between physical servers. In contrast, it may be more challenging to restore an application that was originally written using the cloud vendor's API or development platform.

Step 4th: Prepare for application portability

The most difficult challenge in the cloud is to migrate your cloud-based applications when cloud services fail. Porting an application to a new cloud platform may require access to the runtime library of the application, the business logic of the application, the database that supports the application, and the data that your users have entered into the application. The more proprietary the platform used by cloud service providers, the more the application management that cloud service providers have completed, the greater the difficulty of porting applications.

For example, Salesforce.com claims that it has freed customers from the hassle of buying, managing, and installing CRM software on their own hardware platforms. Once customers sign up, they can access the Salesforce.com Web site through any computer that has a Web browser installed, and hundreds of applications written using Salesforce APIs on the Apex development platform.

However, this highly proprietary model means that customers can only run salesforce.com applications on the Salesforce platform, including their use of any customizations made by those applications on the Web page.

While some tools, such as Force's toolkit, allow developers to use force APIs to create Web applications that run offline. However, while users can modify data offline, most applications must be synchronized with the Salesforce site on a regular basis in the database, business logic, and workflow capabilities. Therefore, you still rely on Salesforce.com.

Independent technical advisor Ben Bloch points out that because the apex of Salesforce is similar to Java, there is an opportunity to "migrate applications to another platform." It may be possible to reuse some logic, user interfaces, and other elements, but developers still have to redo a lot of the work they have done on the Salesforce platform. For example, to reconstruct the data needed for the application, it also includes designing and deploying data, and other models that describe the relationship between application and data.

Peter Coffee, Salesforce's platform research director, said the work on the transplant was not much. He said that the apex development language was designed to resemble Java, so the translation of components written in apex and the use of the company's Visualforce user interface Builder to connect to the new target platform would require only a small portion of the project cost. More work, he says, is writing new code to execute the application.

Another challenge is to restore the business logic and user workflows that are included in the application. Hekademia Consulting, Shockey of the company, says he uses Quickbase formula fields extensively to create and update process data in recent development efforts. "So, if we need to output data, I'm at least guaranteed to have these process information within my data model." However, because the actual business logic embeds the database in the domain formula, if we change the system again, such as abandoning quickbase, I may still lose this logic. He said.

Of course, using open web standards will make it easier for IT departments to move applications from one cloud platform to another, or their own data centers. There is a cloud platform that proves to be effective. Martin Schneider, SugarCRM's product marketing director, said the application of migration was easier because of open standards such as PHP scripting language and MySQL open source database for SugarCRM open source CRM applications. Users simply take snapshots of the data on the SugarCRM platform, as well as custom or application additions, save them on the hard disk, and then upload them to the selected server.

No matter what platform you choose, Shockey suggests that developers should develop a contingency plan for transplanting their applications according to the amount of time the service provider promises to give notice when they fail. Before planning to adopt a cloud development platform, Bloch suggested that users not only ask the cloud provider about the advantages and financial conditions of its business model, but also ask them about the process of releasing a new version of the API and what technology and support they will provide to developers.