"Can we throw this fire extinguisher away? We never use it."
My Mum said that once as she was cleaning under the stairs. At least, that's what my Dad says she said. I have my suspicions that she may have said something subtly different, but nowhere near as memorable. So, unfortunately for my Mum, that is absolutely what she said and no amount of protesting will convince anyone otherwise. That's just the way it works in our house.
Despite the dubious authenticity, this tale touches on a typical gripe we all have - we don’t like having things lying around that we don't use. IT is no exception to this; and having hardware lying around doing nothing costs money. Lots of it.
Nobody enjoys allocating chunks of cash to IT that doesn't deliver tangible returns. Yet, this is what organisations are asked to do to provide a viable plan for business continuity in the event of disaster. Robust disaster recovery strategies should include the ability to failover to a different physical location. In many cases this means a second datacentre that is dedicated to acting as a DR target for on-premises systems. You can't (or at least shouldn't) use this DR target for anything else, yet you must still dedicate a portion of your operational budget to keeping it warm.
Co-location goes someway to alleviating the pain of this by allowing companies to rent hardware and utilities in large multi-tenant datacentres, but you must still pay to reserve the hardware and keep the lights on.
Wouldn’t it be better to only pay for that secondary datacentre when it's in use? This is where Disaster Recovery as a Service (DRaaS) comes in.
Microsoft's cloud-based offering for DRaaS is Azure Site Recovery, and I've really been nerding out about it over the last month or so. I quite like it. Some reasons:
- It's cheap - Microsoft charge a flat fee of £15 per protected server, and you only pay Azure consumption charges in a failover situation
- It's reliable - it runs in your Azure subscription so it's highly-available and failovers are SLA backed
- It's flexible - ASR can be used to protect Hyper-V VMs, VMware VMs, and physical servers, and it can be used as a migration tool
- It's powerful - integrate ASR with Azure Automation and custom runbooks for end-to-end orchestration requirements
- It's easy to get started - it's fully manageable from the Azure portal
Sounds cool, but there are some limitations to even things up a little:
- It can't be used to failover VMs between Azure regions (though this is coming soon…)
- Services running application-level replication (e.g. ADDS) need careful consideration. ASR isn't magic, and replication topologies will break if you're not careful
- It needs detailed planning and testing for production workloads
(To be fair, the last two in that list aren't specific to ASR, I just don't want you to think that ASR means you don't have to think about the complicated stuff running inside your VMs. You do.)
Even with these limitations ASR has some solid use cases and the potential to deliver savings and orchestration benefits to many organisations. Unless you enjoy spending money on unused hardware, it's an option worth exploring.
My Mum would definitely approve.
Read more on the links below, or drop me a line to discuss how Coeo can help you implement ASR.
Microsoft Azure Site Recovery - https://azure.microsoft.com/en-gb/services/site-recovery/
Microsoft Azure Site Recovery Documentation - https://docs.microsoft.com/en-us/azure/site-recovery/
MSDN Channel 9 ASR Video - https://channel9.msdn.com/Shows/Cloud+Cover/Episode-149-Azure-Site-Recovery-with-Praveen-Vijayaraghavan