Disaster Recovery as a Service Considerations

This cloud is definitely getting cloudy and has been for the last few weeks. I can't help it, as the conversation I'm having with customers is all about the cloud.

Many organizations are exporting certain workloads -- like messaging and collaboration -- to the cloud. You can throw disaster recovery in with them. Many of my clients tell me that they cannot justify paying a hefty price for a secondary DR site to protect against disasters that may never happen. For those clients, DR is a workload that is well suited for the cloud.

As with any other "as a service" offering, there are tons of providers out there offering these services. So, this week I offer a few considerations when choosing the best provider to meet your company's expectations:

• DRaaS assumes a highly virtualized environment. In other words, an environment that needs to be restored must meet all the prerequisites for being virtualized. With that, don’t expect an AS/400 to be supported. There are customers that have large, physical SQL clusters that have VM and physical nodes that can be replicated, and so on. Well, as long as it can be virtualized there is a way.
• Hopefully you have a business impact analysis and hopefully you have your applications and data prioritized, which would determine the servers and data that can take part in the DRaaS offering. Going through this exercise makes the pricing exercise easier and clearer.
• Many DRaaS providers offer failover, but very few offer failback. As you weed out providers, ensure that you pick those ones who have failback capabilities. Without it, you will end up stuck on their DRaaS platform.
• Make sure that your Service Level Agreements are clear and are aligned with your business expectations.
• Inquire and understand where the delineation occurs between the cloud provider and enterprise IT. For example, cloud providers will typically stop at the operating system -- once the VM is powered on and the OS comes up and data is connected to the VM, the provider’s responsibility ends. It is now up to your team to make sure that the applications are functioning properly.
• Assess your capabilities and if you determine that in the event of a DR you will need more technical support, inquire about the provider’s ability to produce system engineers that can support them and have specify how quickly such resources wil be available to you.
• You should understand clearly how long your cloud service provider will allow you to use the DRaaS before they have to move you to a different service level. For example, if you failover and you are now using your DRaaS and you happen to stay on this service for two months, does it make financial sense to perhaps move you to an IaaS offering which would be more cost effective, considering DRaaS must have a timeline? Once again, understand how long you can stay on the DRaaS platform.

Workload after workload finds the cloud a formidable fit that achieves a critical business requirement in an easy and cost-effective manner.

Are you having a DR conversation internally? And if so are you considering DRaaS? Please share your comments here.

Posted by Elias Khnaser on 05/15/2013 at 1:30 PM