Disaster recovery as a service (DRaaS) is making it possible for workloads running on premises to fail over to...
public clouds in the event of an outage, thereby allowing the workload to continue to run. This new capability has inevitably led some observers to question whether a workload that has failed over to the cloud should ever be brought back in-house or if it should be left running in the cloud indefinitely.
In most cloud recovery situations, an organization should plan on failing workloads back to their original locations as soon as the crisis is resolved. The one big exception to this is that some DRaaS providers do not support automated failback. Instead, these providers typically require local copies of virtual machines (VMs) to be restored from backup, and even after doing so, the organization must consider how to move the data that has accumulated in the cloud since the time of the failure.
There are five reasons why it is important to fail workloads back from the cloud as quickly as possible.
1. Failing a workload over to the cloud is a response to an emergency situation, not a migration strategy. If you are failing over to a DRaaS provider, that provider's entire business model is probably based around disaster recovery. As such, the provider probably isn't expecting you to run your VMs in their environment on a long-term basis and may even have rules against doing so.
DRaaS providers are not the only game in town for cloud recovery. VMs can potentially be failed over to infrastructure as a service clouds or colocation centers. Although these types of environments are better suited to long-term VM hosting, it is still advisable to treat the failover as an emergency rather than a permanent migration.
VM migrations to the cloud or remote facilities require extensive planning. Some IT professionals might incorrectly assume that if a VM is still functional after a failover, adequate planning has been done and there is no harm in leaving the virtual machine in its new location indefinitely. But migration planning is about more than just ensuring the VM remains functional.
2. Software licensing. Most software vendors readily accept the idea that IT disasters sometimes happen and that it may occasionally be necessary to perform a failover. However, there is a good chance that at least some of the software running in your VM is not licensed for use in the cloud. Migrating such a VM to the cloud without verifying the licensing requirements can expose the organization to legal risks.
3. You don't want to undermine your security and compliance strategy. Presumably, the cloud environment you are using is secure, but migrating VMs to the cloud may require you to rewrite your compliance documentation.
4. The cost involved in operating a virtual machine in the cloud. Conventional wisdom states that it is less expensive to operate a workload in the cloud than to run the same workload on premises. Sometimes, this statement simply does not hold true.
While there are costs associated with running workloads on premises, they are often intangible. If the workload is running in a VM hosted on a server that has been paid for, the only real costs of running the workload are power, cooling and ongoing maintenance. Conversely, cloud providers charge their customers for the resources they consume. When you move a workload to the cloud, you immediately begin incurring charges for things like storage I/O and CPU consumption. Depending on how resource-intensive a workload the virtual machine is running, costs for cloud recovery and running a VM in the cloud can be substantial.
5. You want the ability to fail over the VM in the event of a problem. If your contingency plan is to fail a VM over to the cloud in the event of a disaster, what happens to your contingency plan if you leave the VM running in the cloud? You might be able to configure the VM to fail over to a different cloud, but doing so requires planning and increases cost and complexity.
Essential guide to a solid cloud disaster recovery strategy
Transitioning to a hybrid cloud can save money
Why it's critical to test cloud-based DR