Application Consideration for Disaster Recovery in cloud computing

The following items should be considered when thinking about including cloud computing for disaster recovery purposes.
1. Not all applications belong in the cloud. High-performance computing environments typically associated with research or applications relying on very large data transfers are usually not considered first pick for a migration to the cloud. Some of the limiting factors may include cost and network connectivity, especially in a third-party service context. Applications that are easily migrated to the cloud include email, CRM, Web portals and document sharing.
2. Where are the actual systems that make up the cloud? In the case of private clouds, it is important that you know the location of the systems making up the cloud. If your company decided to virtualize servers, data storage and network into its own cloud, understanding the location of the physical assets that make up this cloud is vital. If physical assets are in a single location that could be affected by a disaster of some sort, then the entire cloud can be a single point of failure and become part of the disaster for which it is expected to become a recovery aid. This approach is only valid if the physical assets that make up the cloud have redundancies in place and are hosted in collocation facility, or if your company's cloud spans multiple location with the ability to seamlessly move workloads.
3. Are service level agreements (SLAs) enough? For example, if there is an outage exceeding a pre-established duration, clients are entitled to a refund or credit on the service fees. Depending on the criticality of an application and the financial impact of an outage, a refund or credit may be meager compensation in comparison to the financial impact of a system outage on your company's revenue stream. A clear understanding of applications' criticality and the business process they support is essential.
4. Disaster recovery planning always focuses on making sure critical applications are available in the event of a disaster, but end users are often an afterthought. While cloud computing, Software as a Service (SaaS) or storage as a service can provide protection from failures by virtue of not having the systems as you place of work, a little more thinking is required for a disaster at your place of work. While the cloud is available, the users may not be able to access it. The DR strategy must also ensure users have the means and a place from where they can access the cloud such as adequate workspace, workstations and network connectivity among other things. This can be compared to installing an emergency generator for the data center; if 300 users on the tenth floor have no power to their workstations, it won't matter if the data center has power or not.
5. The nature of the organization's funding mechanism also plays a great part in how cloud computing and SaaS in general are viewed internally. Business models that lean toward reducing capital expenditure and are better suited to support operating expenditures are typically better candidates for cloud computing, especially when contracted as a service.
6. Develop a clear understanding of the redundancies and capabilities of the cloud. This is a key factor when considering how it can enhance availability and recoverability within your organization.
Leveraging the capabilities and mobility of the cloud to increase the availability of some critical applications is a smart idea. Some applications such as email, file services, document sharing and databases for CRM and ERP are easier to port to the cloud and should be considered first (in a non-DR environment).
In the end, some applications will not be good candidates for migration to the cloud but still require high availability or fast recovery. For most companies, the best solution is a hybrid that includes cost-effective cloud elements for mainstream applications or services and more traditional data backup, data replication, collocation or clustering elements for those applications that are not yet suitable for the cloud model