With the list of possible disruptive events that can take a business offline growing in number year over year, it’s no surprise so many organizations’ leaders are now asking their IT departments to strengthen their stance against these threats. But what role can the cloud play in ensuring this greater resiliency?

There are two essential solutions that every IT leader should consider when shopping around for improving business continuity: Disaster Recovery as a Service (DRaaS) and Backup as a Service (BaaS). While these tow solutions are similar, they have differing core objectives when it comes to protecting a business. To learn more about these differences, check out the blog post “BaaS vs. DRaaS: 3 Key Differences to Know.”

In this post, let’s dig into the key elements and benefits of DRaaS.

What Exactly Is DRaaS?

Here are the components that make DRaaS what it is:

• Replication – technology that provides continuous data protection as opposed to backups that provide point-in-time snapshots of your data
• Cloud – the target of your replication is a cloud, either a hosted cloud or a public cloud like AWS
• as-a-Service

I’d like to add a fourth component to this list. DRaaS not only provides you with target storage for your replication but it also provides you with access to the infrastructure upon which to recover should you need it. Because of the cloud economics of DRaaS, you are only paying a fraction of the cost of this infrastructure if anything.

How you tier your applications will lead you to the type of technology you will use to protect their data. There are four major types of protection:

• Active-Active Applications: For those applications with near-zero tolerance for data loss or availability.
• Active-Active Infrastructure: Hot standbys that can be online in seconds to minutes…active directory…firewalls…those applications that must be in place before your line of business applications.
• Hypervisor Replication: Applications that have a low tolerance for data loss and must be available within 4 to 8 hours.
• Backups for Recovery: Applications that are important, but have low transaction volumes and can sustain outages of 24 to 48 hours.

The Managed Services Aspects

The “as-a-Service” model a DRaaS offering must include more than just a piece of software or an appliance; it has to be delivered as a service. The depth of the service can vary based on your needs and your budget. Think of the body of work that must be performed to establish, maintain, test, and update your disaster recovery architecture. The more of that work you can shift to the provided the more time your team has available to work on other value-add projects. Service models for DRaaS fall into three main categories:

• Full Service: The DRaaS vendor provides an end-to-end service covering the implementation and the tools, to the iterative cycle of test and update. They are also there when you need to declare a disaster to perform much of the playbook the two of you have developed.
• Assisted Service: The DRaaS vendor provides the implementation and the tools. Once replication is validated, they hand you the keys to take over operations and management while they tend to the target infrastructure. Of course, they are always there in the background should you need an assist.
• Self-Service: The DRaaS vendor provides an automated way to set up your replication, manage and operate that replication, and failover should you need it. The provider again manages the target infrastructure.

Before we dive into replication targets and the pros and cons of the choices, let’s review the primary drivers for choosing a DRaaS solution.

The Primary Drivers of DRaaS

With DRaaS, you have the infrastructure on which to restore your applications and data when you need to do so. Many organizations still rely on backups for their disaster recovery strategy. When they need to recover, they first have to procure, configure and deploy the infrastructure to recover. This adds weeks and possibly months to the recovery time. Some organizations have a secondary datacenter. Often, that is where old hardware goes to die. The thinking is the organization will be okay running on lower-performing hardware during the failover period. This may be true when the failover period is a day or two. Beyond that, how much business will be lost because the staff can’t keep up with demand?

Some DRaaS providers also will sign service level agreements (SLAs) with you, in a sense guaranteeing recovery within the agreed-to recovery time. This shifts some of the risks to the provider. Because of this shift, the provider will be proactive in ensuring you test your disaster recovery failover. This will give them, and more importantly you, the confidence they can recover.

It’s important not to forget the ability to failback following a disruptive event. In other words, you’ve had an event. You’ve failed over all or part of your systems to your target datacenter or cloud. Now it is time to return operations to your home datacenter. DRaaS technology provides a seamless way of doing this by shifting the target of your replication stream to your home datacenter. Because of the nature of continuous data protection, once the replication reaches a steady state you can failback to your production datacenter.

Considerations for DRaaS

As you consider DRaaS, you have some choices when it comes to targets. A replication target is a cloud where you send your replication stream, and it is where you will recover when the need arises.

As I mentioned, for DRaaS to be DRaaS, the target must be a cloud. Yes, you can use the same tools DRaaS providers use to replicate your virtual machines to one of your other datacenters or colo, but I contend it is no longer DRaaS at that point, it’s just DR using hypervisor-level replication. You lose most of the benefits provided by DRaaS.

When considering which cloud to target, there are two major categories: hosted clouds and hyperscale (or public) clouds.

Hosted vs. Hyperscale Clouds

Hosted clouds range from small boutique cloud providers to those whose scale is larger but not as large as the hyperscale providers like AWS, Azure, or Google. Hosted clouds may also be referred to as enterprise clouds by some providers. Many times, the Hosted cloud provider is also the provider of the DRaaS service. Typically, these clouds are based on commercially available hypervisors like VMWare and Hyper-V.

Hyperscale clouds include AWS, Azure, Google, and others. When it comes to DRaaS targets the most common are AWS and Azure. Both provide the tools to replicate into their clouds, however, they stop short of providing DRaaS. You will need a third party to be your service provider when targeting the hyperscale clouds.

As we consider the pros and cons of a) using a cloud as a target and b) which cloud to target, keep in mind this is not a one-size-fits-all proposition either. You may find yourself using different targets for different workloads or you may find yourself using multiple targets for the same workload.

The TCO Benefits of DRaaS

We have already discussed some of the benefits you will realize by using DRaaS for your disaster recovery strategy: recovery target that you don’t need to maintain or keep updated, offloading work to a third party, and failback.

Additionally, you will recognize a lower Total Cost of Ownership when compared to maintaining like-for-like environments in production and in DR. The amount of lower TCO will be based on the tiering of your applications and whether you choose a hosted cloud or a hyperscale cloud.

Leveraging a cloud as your target can also provide greater geographic separation between your production workloads and your recovery target. When deciding which clouds to target, it begins with your cloud strategy. If in your cloud strategy, you have plans to migrate some or all of your workloads into AWS, for example, you should investigate the options for using AWS as a target in your DRaaS solution. If a hosted cloud is part of your cloud strategy, then look to that cloud as your primary target.

Aligning DRaaS with Your Long-Term Cloud Strategy

Aligning your replication targets with your long-term strategy can pay dividends by providing a less critical place for your team to learn how your applications will behave in the cloud. During your DR tests, a copy of your production environment will be brought up in the cloud. It will be segregated from your true production environment, allowing you to run simulations, regression testing, stress tests and more against it. This will help your team to learn cloud. It will also help you identify applications that may need to be refactored to run efficiently and effectively in the cloud.

You may be feeling some pressure from your CEO and other executives to “get to the cloud.” DRaaS can be a way to show a “quick win” without jeopardizing your production environment. While a DRaaS project can take weeks or months to implement, it is far faster than a full cloud migration. Another benefit you will see from aligning your cloud strategy with your DR strategy is a faster cloud migration when you are ready.

Considering Geodiversity of the DRaaS Target

Some other points to consider when choosing which clouds to target for your replication might include the geographic diversity of the cloud provider. The hyperscale clouds have datacenters all over the world. If you are a global company, this could be the factor that tips the scales to AWS or Azure. Many countries have data sovereignty laws that require the data to stay in the country. Choosing a provider whose footprint aligns with yours would be crucial in those cases.

If you are a shop that has a lot of non-x86 workloads, you will want to work with a provider who can help design and implement a solution that protects those workloads as well. They can help you determine if targeting one cloud for all your workloads is the best option, or if you should consider a multi-cloud strategy of replicating your x86 workloads to a hyperscale cloud and your non-x86 into a hosted environment.

Application tiering comes with a tradeoff between cost and recovery times. This is also the case when deciding which cloud to target for your replication and recovery. Recovering your workloads in one of the hyperscale clouds will impact your recovery time. Recovery time will be somewhat longer in AWS and Azure than it will be in a hosted cloud based on the same hypervisor you use in production. This overhead is caused by the conversion that must take place from your hypervisor (VMWare or Hyper-V) to the hypervisor used by the hyperscale cloud. AWS uses a proprietary hypervisor and Azure uses a version of Hyper-V that is different from the commercially-available versions.

The tradeoff for these somewhat slower recovery times is cost. Storage costs while you are in a replication state (non-failover) can be significantly lower than the hosted clouds. This is especially true for the lower tiers of applications that can be moved to cold storage until a recovery is needed. BaaS provides you with low-cost cloud backups of your precious data, and these backups can be stored in AWS, Azure, or in a hosted cloud.

The Future and Strategizing Your Path To Business Continuity

Looking ahead, once you are ready to start exploring DRaaS deeper, and from a solution and provider perspective, reach out to one of our experts here. We’d love to have a conversation to help enable your IT vision.