Disaster Recovery as a Service

Defining "as-a-service"

In the Information Technology industry, the "as-a-service" moniker refers to outsourcing of data/communications technology and applications at the technical level. It involves paying a service provider on a subscription basis to host and manage software and data on their servers that would traditionally run on equipment in your own data center or office server room. In general, the hosted applications are available to your users, clients, and partners via the Internet.

Since it's a new term associated with the accession of public cloud computing, "as-a-service" tends to apply only to things that weren't typically hosted before the cloud era. This is why no one says "web hosting as a service" or "e-mail as a service".

The obvious advantage is that you don't have to purchase hardware and software licenses, then pay employees or outsourced local service providers to install and maintain everything. You don't have to manage lifecycles for hardware (or deal with unexpected failures), or implement software upgrade projects. The disadvantages include more complicated security, new considerations for legal compliance for data protection and retention, significant loss of control of your data and applications, and generally reduced performance compared to in-house equipment.

Here are the core "as-a-service" categories of the cloud era, in ascending order of complexity:

  • Software-as-a-Service (SaaS). Instead of installing user software applications on your workstations, and manually downloading and installing updates, users simply log on to the provider's site using a web browser, work on their files or data, and save the information within the provider's system. Well-known SaaS providers include Salesforce.com and its competitors for customer relations software; QuickBooks Online and NetSuite for accounting; and Google G Suite and Microsoft Office 365 for office productivity software. When the provider upgrades the software (to add features or update the look), users will see the changes the next time they log in, without having to do anything. The provider manages computing power, network capacity, and physical storage, expanding equipment to meet demand. The provider also handles backups and intersite replication, to enable recovery in case their systems crash. SaaS has actually been around since the 1990s, long before modern cloud computing existed. Back then, SaaS providers were called ASPs (application service providers).
    • DRaaS
  • Platform-as-a-Service (PaaS) is where the provider implements and manages virtual servers for you to host your own custom-developed applications. The virtual servers run on the hardware architecture and operating system you need, and your developers can log in to manage them using a web browser or remote desktop technology. The PaaS provider also makes software libraries and interfaces available for accessing file storage, databases, and communications systems managed by the PaaS provider.
  • Infrastructure-as-a-Service (IaaS) offers even more powerful and complex capabilities, with more granular and low-level control. With IaaS, your network engineers can install and manage your own virtual servers, as well as virtual networking and firewalls (to segment and secure your database server, for example, so it's only accessible by your web server and not directly by the public). All of it can be managed from any computer with a web browser, with no hardware for you to buy. With IaaS, you will manually control how much computing and storage power you use, depending on what you need and how much you want to spend.

The line between PaaS and IaaS cannot be strictly defined, since there is significant overlap, and providers of either often provide both. Examples of these are the major players such as Amazon Web Services, OpenStack, Microsoft Azure, Google Cloud Platform, IBM Cloud, and their many fledgling but worthy competitors. Many well-known websites run on PaaS/IaaS services themselves. For example, Netflix, Blackboard, and Major League Baseball Advanced Media run on Amazon Web Services (AWS). Intuit's QuickBase is a leading example of a service that is solely PaaS; this offers a web-based system for developing highly-functional relational database applications.

Deploying Disaster-Recovery-as-a-Service

OK, so, let's define Disaster-Recovery-as-a-Service (DRaaS).

DRaaS means deploying some of the resources and tools you use to prepare for an IT system disaster into a PaaS or IaaS system. These resources would include backup storage at a minimum, but can also include copies of your databases and applications, as well as replicated network infrastructure, and system management tools required to facilitate the recovery process.

You can deploy DRaaS to support your Disaster Recovery plan whether your production infrastructure is already in a cloud service, it's entirely in your own facilities, or you have a mix. If your entire regular production system is already in the cloud, your risk assessments have to consider what happens if your cloud provider goes down, as unlikely as that is, and DRaaS from another cloud provider generally should integrate well into your existing cloud system.

DRaaS is not a replacement for the Disaster Recovery planning and maintenance processes; these business management activities must be done to ensure that the DRaaS service is adequate and appropriate. And, once deployed, the DRaaS service itself still has to be validated, managed, tested, and monitored to make sure the resources are ready as you expect them. All of this will be guided by the risk thresholds and recovery time requirements established during Disaster Recovery planning.

DRaaS replaces physical equipment and software, but does not replace the disciplines of Disaster Recovery planning and risk management.

Some services bill themselves as DRaaS, but merely provide data backup services. Some focus primarily on virtual machine recovery. The highest level of service is one that can replicate your entire virtual network, such as your virtual routing and storage infrastructure, along with your applications and data, to meet the challenges of enabling prompt recovery of your existing complex system. Obviously, not having the capabilities you need could be devastating. And, due to the subscription nature of these offerings, if you sign up for service that is beyond what you need, you may end up paying significantly more than you should, with the unnecessary extra expense adding up as each monthly payment goes out.

Site Recovery

If you read the article entitled Disaster Recovery and Business Continuity Examples, please recall the section on hot, warm, and cold recovery sites, for maintaining business operations. With DRaaS, you can set up hot or warm sites as well.

  • Hot DRaaS—All of your critical stand-by virtual machines are already running, with replicated copies of your data, ready to take over promptly or even automatically after a failure of your main infrastructure with minimal configuration.
  • Warm DRaaS—The virtual machines and software are set up already, but need to be manually started, and your data has to be restored into the systems from backup. Some configuration to redirect users and network traffic may need to be done.

We can't describe any setup as a Cold DRaaS, because it wouldn't make sense. Recall, a cold recovery site is an empty office, with space for you to set up a data center and workstations if needed to recover from the loss or isolation of a your primary facility, where fast recovery is not the highest priority. If you have backups of your data and/or virtual machines in the cloud, but you haven't formulated and tested the process of restoring service in case your primary infrastructure fails, you could say this is a Cold DRaaS, but it's more accurate to say you do not yet have a Disaster Recovery plan at all.

SaaS Recovery

DRaaS is well-suited to support existing physical infrastucture on your site, or systems in a PaaS or IaaS system. If your users do most or all of your production work through a SaaS service, though, setting up DRaaS for this presents a challenge, because you do not have access to the servers and storage infrastructure behind a SaaS provider. It may seem like you don't have to worry, because SaaS providers obviously will have high availability and recovery strategies for their own systems.

Tablet user

However, the contracts for these providers make clear that they don't back up your data for the purpose of protecting it from corruption or accidental deletion. Data loss incidents in SaaS systems due to such user errors are actually quite common, and certainly far more common than your data being lost because the SaaS provider's system fails. Also, although outages from the major SaaS providers are rare, they do happen, and sometimes they have such an impact that it makes the news. Even more common than an outage with the SaaS provider is your company's Internet connection going down, which completely disables your ability to work in your SaaS application. So Disaster Recovery is not something you can ignore just because all your applications and data are in the cloud.

Strategies for employing DRaaS for SaaS applications can include:

  • SLA (Service Level Agreements) in your contract with the SaaS provider, establishing their obligation to maintain a certain level of uptime, or compliance with legal requirements for data security (including encryption policy, notification after breaches, etc.).
  • SLA requiring the SaaS provider to perform backups and keep archives of your data commensurate with your recovery requirements and risk thresholds. The major providers generally won't do this.
  • A third-party DRaaS service performing backups. Since Salesforce.com, G Suite, and Office 365 each have millions of subscribers, there are several SaaS providers that can connect to your company's account on these and back up all your users' data. These backup providers, of course, must run on a PaaS or IaaS system separate from your applications provider, to ensure recovery in case your application provider's platform suffers a calamatous break-down.
  • Redundant Internet connections or other contingency plans to enable access in case of an Internet access outage at your facility.

As always, the appropriate approach has to be determined by the Disaster Recovery planning process. You need to calculate the impact, in terms of lost revenue or other costs, that would be incurred in the event of data loss or an outage, to set the budget for your DRaaS solutions. And, of course, plan maintenance and testing should not be ignored.