Published: August 25 2010, 07:22 AM | 1 Comment(s)
by Andi Mann

Cloud computing is a nascent technology - and more than that, a new approach to management - that is starting to gain traction. From even the most basic outsourcing of machine builds for new application development, through the efficiency goals of using external platforms and applications delivered ‘on-demand' as services, to grand notions of reengineering the enterprise data center as a private cloud, or even replacing it with a third-party cloud provider, cloud computing is present in a lot of today's grand IT dreams.

However, it is interesting and informative to look at real world use cases that you can implement today. At the top of that list (alongside dev/test/QA and Web server outsourcing), is the ability to use cloud computing - both private and public - for critical backups, disaster recovery, and business continuity.

Imagine, for example, that your data center fails, from a hurricane or earthquake in the US; a cyclone or flooding monsoon rains in Asia; a Tsunami in the Pacific; geothermal activity in northern Europe; or unavoidable military activities in the Middle East. Or you may have a less spectacular event that is nevertheless potentially just as damaging - like a local pandemic that requires your staff to work from home; a transformer failure; or a localized blackout or brownout.

Even without the impending doom of a large-scale failure, you still need to be prepared to recover individual files that get corrupted or accidentally overwritten, application code that is updated without authorization, single systems that have failed unexpectedly, or user documents that have mysteriously disappeared.

Enter cloud computing - and a real world use case that you can implement today.

Backup and recovery, business continuity, and content storage are among the top use cases for cloud computing today. Applied judiciously, both private and public cloud can address all of these potential disasters, from a single lost document, to a full-scale data center failure.

You can, of course, simply backup your data to the cloud, by copying files and systems, in whole and/or incrementally, to a third-party storage service. This is possibly the easiest way to start out with cloud. There are dozens of enterprise-class services that provide the essential resource pooling, elasticity, pay-per-use, self-service, and network access for offsite data storage that defines cloud computing. In any disaster, your data - from a single end-user document to your entire enterprise storage - can be available across the network from any ‘hot site' location, including your work-at-home employees' PCs, for easy recovery and continuity.

You can even go a step further, and backup your applications, systems, and even entire services to the cloud. This would require a different set of cloud options - especially the ability to run the entire system and application stack in an off-site location - but the principle is the same, and the payoff is perhaps even better. After all, rather than just having data stored offsite, you can set up a fully operational application offsite. In this case, you will be able to not just restore data from the backup to your own facilities if you have a disruption; you will be able to keep running your existing applications, with your existing data, even while your core facilities are down.

Of course, you need to be aware of - and accommodate - a number of potential hurdles. For example:

• Security & Control - not all cloud providers have the same attitude to security and compliance that you do. This may be bad - if you have evolved mature security and control discipline; or it may be a good thing, if you are looking for an external provider to help you with best practices. Cloud is not, per se, either secure or insecure. You simply need to set your own standards, be aware of what your cloud provider can and cannot deliver, and choose according to your desired level of risk.
• Portability & Compatibility - not all cloud providers will be able to provide the level of portability and compatibility for your systems and data that you might need. Extracting and restoring data may end up being a slow manual process, due to API limitations and other restrictions; or it may be impossible to accomplish in a timely manner due to more mundane limitations like bandwidth. Your applications may also need significant changes to be compatible with storage in a non-specific location that changes in case of emergency. Be aware of your use cases, and make sure your recovery plan allows for the mobility of data the cloud will enable.
• Longevity & Accessibility - this may be an aspect of security, but is worth calling out separately. During an analyst keynote speech at the recent CA InfoXchange event in Malaysia, the speaker estimated that a substantial number of current cloud providers will be out of business within 2 years. You need to be assured of the longevity of your backup/DR host, and that your data will be accessible when and how you need it, before committing to them as your sole source for data recovery.

Now, none of these challenges are truly insurmountable - nor are they the only challenges - but they should give you cause to plan carefully. You may even decide the reward is not sufficient to balance out the risk. In this case, you may choose to employ a private cloud approach - or at least an ‘80% cloud'.

For example, even though you may not have infinitely scalable storage resources or storage chargeback in place, you may have a second data center or an offsite backup location that is accessible over the network, on-demand, without manual IT intervention. It is entirely feasible to use this sort or architecture for a private cloud backup service, with similar benefits as the public cloud options, and without many of the downsides. With virtual servers and WAN-connected storage, you can recover workloads at or from either site, making continuity even more flexible, albeit at a higher upfront cost.

Of course, private cloud and public cloud are not mutually exclusive choices either. A hybrid cloud - mixing both private infrastructure and public services - can be perfect for these sorts of use cases. A compromise solution may see you put confidential customer data in your own private cloud backup facility, with extra control but extra cost; while using a public cloud option for less critical system backups, with less control but at a lower cost.

Regardless of which route you take, you will need to make sure of a few things. First, understand that no option is perfect, and you will need to make tradeoffs. Second, plan carefully, down to the last detail, and prepare for every contingency. Third, test your plan, not just once, but early and often, continually refining it as you go. Fourth, do not just accommodate technology, but make sure to accommodate continuity in your processes and for your people too.

Fifth, and finally, make sure you have the right management tools that are going to let you achieve your goals.

For example, you will need solutions for sophisticated backup and recovery, including physical-to-virtual and virtual-to-virtual recovery (such as CA ARCserve). You will need solutions to automate the IT processes for backup/recovery (like CA Spectrum Automation Manager). You will need solutions that provide desktop and user mobility so your staff can work from wherever they are (like CA IT Client Manager).

These are just some of the processes and technologies that can help you achieve continuity with cloud computing, whether private or public. Perhaps you have other ideas, or know of other essential areas I have not mentioned. If so, I would love to hear them. After all, this is your community too, so go ahead and let us know what you are thinking. I will look forward to any comments.