Like all hot tech markets, an ever growing list of well funded DRaaS (disaster-recovery-as-a-service) vendors continue emerge and vie for customer business with a wide variety of solution approaches. Gartner recently reported that there are over 180 vendors currently on the market offering DRaaS related capabilities. While most of these vendors claim essentially identical product capabilities, the reality on the ground for those who peel back the onion of hype is considerably different. Even some market analysts still struggle to differentiate the true disruptive DRaaS technology players from the legacy DR players to be disrupted. So here is a list of the top capability differences between DRaaS providers that most DRaaS marketing efforts will try to avoid and obscure.
1. Backup-only products disguised as DRaaS
There is a big difference between a solution that is dominantly just for data recovery vs. complete system/data/applications recovery. Make no mistake, DRaaS is in many ways an evolution and disruption of the traditional backup and recovery market. Unfortunately, the relentless marketing campaigns of large, legacy backup providers continue to blur the lines between backup, or “cloud” backup and DRaaS. Should a backup-only solution really be considered a true “DR” solution in today’s compute resource on demand market? A simple analogy might be the comparison of a Nokia flip phone to an IOS or Android smart phone? To go one step further, can a backup product with a cloud hosted recovery node (an identical clone of your production server or vm) bolted on to it really be considered DRaaS, when in its complete form DRaaS is a blend of modernized backup, infrastructure-as-a-service, cloud and compute resource orchestration that replaces traditional stand-alone backup capabilities with tightly integrated backup, archiving, high availability and disaster recovery? Remember, the end goal here is instant recovery of not just your data, but of your full set of critical system(s), data and applications.
2. DR-only products (remote recovery) without High Availability (instant recovery local to the protected systems)
The IT category label of “DRaaS” is good, but buyers beware that many DRaaS products on the market offer only the “DR” part of the equation, which is a remote recovery capability via the cloud. While this DR capability is essential for recovery from catastrophic, yet relatively infrequent, full data center outages that typically comprise maybe 2-5% of overall IT outages, remote DR is a problematic option for the other 95% majority of outages that occur on a weekly or monthly basis (think operator errors, SAN failures, crypto-locker virus infections, etc.). Instant recovery resources that are local to the protected IT systems (typically referred to as high availability or ‘HA’) provide significant advantages vs DR for these types of outages in terms of RTO (recovery time objectives), simplicity, end-user transparency, and fast, simple fail-back. Remember that with DR-only DRaaS solutions, during every failover your end users connect to the recovery node(s) in the cloud. From that point on, all subsequent data changes from end users will be on the systems in the DR cloud for however long you stay in failover mode (which btw some vendors limit severely). So when it is finally time to fail-back, you will need to put all of those data changes sitting in the cloud back onto your original production servers, which can be a much longer and more involved process than failing back from recovery nodes that are local to your original production servers.
3. Recovery node quantity and startup limitations (“Too little too late…”)
Of the DRaaS vendors that provide local HA capability (i.e. the ability to failover to local recovery nodes), many have severe limitations on how quickly that local recovery can occur, and on how many local recovery nodes you can use at the same time. At a minimum you should expect options for several to many local HA instant recovery nodes that are ready in just the amount of time it takes to boot your server, supporting recovery time objectives (RTO) as low as 2-5 minutes.
4. Protection of a virtual machines from within the same hypervisor is a bad idea (“There’s a fundamental reason an ocean liner’s lifeboats are on the outside of the ship”…)
Many DRaaS products on the market today focus entirely on VMs (primarily VMware for obvious marketshare reasons). This makes some sense considering that the vast majority of the world’s production IT workloads are now virtualized. The fundamental flaw with most of these products is that they are deployed into and execute from the exact same hypervisor environment that the VMs to protect run within. So if there is a problem with the platform that the protected systems run within, then the recovery system within that same platform will be affected as well. Note that additional problems with this approach typically include: a) different product needed for protection of physical systems, and b) costs for additional VM licenses and infrastructure to host the DRaaS product local system components.
5. Beyond DR (“Get value from your DRaaS investment even when you are not experiencing and outage”)
Most IT organizations invest in some amount of additional server and/or VM infrastructure resources for production staging and other testing of production systems. Many also expend resources to prepare accurate representations of production systems and data in those staging environments. Consequently, a few DRaaS products provide a simple way for customers to reduce their testing costs by leveraging their DRaaS production system clones off of the primary production network to test upgrades and patches, or to offload data extracts for business intelligence system feeds and more.
CHIEF EXECUTIVE OFFICER
Simon Pearce brings deep expertise and experience with over 20 years in the technology and software business, Simon has led several companies from the start-up phase through global expansion. Simon also serves as a partner in Toba Capital, the major investor in Quorum. Prior to joining Quorum and Toba Capital, Simon spent 15 years with Quest Software, and as the company’s first UK-based employee, he built an EMEA operation with over 300 staff members and 15 offices across the region, before moving to the US to lead a Quest Software Subsidiary based in Washington DC. He also held senior leadership roles at ParcPlace and Computer Power Group.
Posted on 09/09/2015 at 07:15:00 AM
Enter both words below, separated by a space
Please enter the words or numbers you hear
This is a standard security test that we use to prevent spammers from submitting fake response More Help