As organizations increasingly realize that IT will be mix of different approaches, using public and private cloud as well as more traditional infrastructure, there is much discussion about the “best” way to deliver hybrid infrastructure. The city of Asheville, NC recently won an award and showed a good example of hybrid IT done right. The Amazon sponsored “City In A Cloud” competition is one of those dime-a-dozen vendor competitions, but the Asheville case study, as detailed by its CIO, Jonathan Feldman, is certainly food for thought nonetheless.
Feldman had something of a problem. Recently arrived to the CIO position, he took a look at the way the city provided for recovery from a disaster. He was please to see that Asheville had a DR facility, but less overjoyed to see that is=t was just two blocks from the main data center – there’s not a lot of geographical redundancy in there. Looking at the costs and options for a more robust DR setup, Feldman first looking to a build out of Asheville’s own regional DR facility. One this project was cancelled, he went back to the drawing board to look whether the cloud could help with Asheville’s issue. Having been involved in Hurricane Katrina, and seeing how DR facilities anywhere near a primary facility are a bad idea, Feldman looked to the cloud to give as much geographic spread as he wished for.
AT which time the problem quickly arose – while traditional approaches towards hybrid IT look at having some workloads on-premises with others ones in the cloud, Feldman was looking at a different scenario here – he wanted to provide disaster recovery for an on-premises application in the public cloud – that called for some complex moving of virtual machines between different infrastructures, and called for workload automation of a high order.
Working with a young company, CloudVelox, Feldman approached the problems, both technical and non-technical, of moving to the public cloud. At the time, it was daunting to move virtual machines into any public cloud, especially with the level of automation we were looking for. So we kept experimenting and investigating. Feldman started by taking one low-risk server and had CloudVelox apply their migration approach to it – having successfully proven that virtual servers can be moved without disaster, Feldman gave a green light to escalating the project. He put the application staff in charge of the project - they had “skin in the game” because the old failover methods were labor-intensive and hard to test.
The end of the story is that the entire DR system for the particular workload was put into the cloud (in this case, Amazon Web Services). Feldman achieved DR that gave fail over in less than an hour (previously DR exercises had been a weekend-long process).
This is interesting because DR is one of the real low-hanging fruits in terms of a move to the cloud. Running a disaster recovery facility is expensive, complex and time-consuming. All that infrastructure set up and maintained for an eventuality that might never occur is a bitter pill to swallow. By running DR on the cloud – complexity and cost are greatly reduced – workloads sit in storage on the cloud, ready to be brought to life if and when needed – the cost savings can be huge, and the move from capital expenditure to operating expenditure keep the financial folks happy.
Feldman pointed out a few things that proved problematic in the over to cloud DR. In particular DNS, licensing and bandwidth costs all offered challenges which had to be overcome. Feldman also admitted that more mission-critical workloads will likely continue to be situated in an on-premises DR facility. But as an example of moving to the cloud, putting an organization’s faith in a small startup, and believing that cloud migration is actually possible, the Asheville case study is highly illustrative.
