alphaspirit - Fotolia
From the onset of the "Year of DaaS," both DR and cloud bursting have been waiting in the wings as potential use cases for DaaS. I've traveled the country speaking at shows, and whether or not these use cases are feasible comes up at every single event.
I have to say, I wasn't all that surprised. Using DaaS for DR is a great idea, but it has challenges. And once you've gone to the trouble of setting up a DaaS service, why not go all the way?
The trouble with DR
The typical DR setup for organizations is to have another site (or sites) pre-staged and ready to spring into action in the event of an emergency. In many situations, these sites have a data center with duplicates of critical servers, as well as a number of PCs that have to be maintained and patched.
Maintaining these DR environments, though necessary, is a burden on both employee time and corporate budgets, so companies should welcome anything that can alleviate those challenges and costs.
Using DaaS for DR would mean that companies could stop worrying about keeping aging desktop hardware alive and patched. It also removes the possibility of having hundreds of unattended zombie PCs on the network (although you could argue that those are actually more secure because they don't have users on them).
Some organizations get around this by using VDI, but replicating that infrastructure at a DR site makes your VDI hardware twice as expensive. No matter how you slice it, DR sites cost time and money, and being able to push it to the cloud would be beneficial for many organizations.
Why DaaS for DR is a challenge
The problem with using DaaS as a disaster recovery method is that you have to resolve all the same challenges you'd have if you were moving to DaaS, but then all you use it for is DR. To set up DaaS for DR, you must:
- make backend services have accessible from the desktops;
- integrate authentication;
- replicate data somewhere;
- have a provider that can stand desktops up quickly;
- and you must trust your provider.
Say you did all that work -- now what? You've just done all the work needed to move to DaaS, but then stopped short of moving to DaaS. You put in all that time, money and effort -- just in case of an emergency.
Simply saying, "We're using DaaS, but it's just for our DR," does nothing to diminish the amount of work required to actually make that happen. You have to resolve a lot of technical, regulatory, political and sometimes even emotional challenges to have infrastructure in the cloud that is useable at a moment's notice.
How it DaaS as DR is different
The biggest difference between DaaS and DaaS as DR is that the latter is cheaper than if you were to run full-time desktops from the cloud.
With traditional DaaS (if there is such a thing), you pay between $30 and $40 per month for a desktop. VMware's Horizon Air Desktop DR comes in at around $5 per desktop per month. That's because the $5 doesn't really buy you anything. You're renting a spot in VMware's system in the event of a catastrophe. There aren't even licensing costs built into that price -- it's a placeholder.
Really, it's the perfect model for DaaS. You're taking out an uptime insurance policy for $5 per month, per desktop. DaaS as DR makes a ton of sense, once you get past the fact that it's DaaS.
Should you do it?
If you can address each of the challenges that come with setting up DaaS for DR, then absolutely you should do it! But don't stop there.
You've already done all the hard work anyway, so open up the flood gates and just do DaaS all the way. At least evaluate it.
There's bound to be some situations where you have to keep desktops local (or in VDI, but still on-premises), but if you've managed to break through to the other side of the cloud model, you should use it for everything you can instead of artificially limiting yourself to something that you will hopefully never have to use.
Guide to disaster recovery in VD I shops
How cloud hosted desktops are different from VDI