Getting the Right Kind of Cloud Agility: Eye the Exits
Cloud vendors tout two main advantages to their products: cost and agility. Let’s talk about the kind of agility that I want all cloud users to possess: the power to make a quick and graceful exit from the cloud and back on-premises, should that become necessary.
July 26, 2011
Cloud vendors tout two main advantages to their products: cost (which we’ve covered in past columns) and agility, which is cloud-speak for “you can double the size of your data center in seconds with just a few mouse clicks.” It’s a pretty neat-sounding capability and it’s hard to think of a word with as many positive associations and as few negative associations as agility, so permit me to hijack that word this month and let’s talk about the kind of agility that I want all cloud users to possess: the power to make a quick and graceful exit from the cloud and back on-premises, should that become necessary.
Despite having acquired a reputation of being anti-cloud, the truth is that I believe that cloud computing will end up being the cheapest, most reliable, and best answer for a significant number of organizations, and by “significant” I mean somewhere between 20 to 35 percent of organizations. Those best-fit folks will drift to the cloud and never look back.
Some other organizations, however, will spend the time and money to move their IT stuff to a cloud, only to experience “clouder’s remorse,” wherein they find either that their cloud vendor just isn’t delivering what they expected, the costs are out of control or, worse, the vendor is simply a nightmare. Clearly their next step in both cases is to get off of that cloud (I so wanted to quote a Rolling Stones lyric here but, you’ll notice, have manfully resisted), but how?
Moving existing IT assets (whether they be classifiable as infrastructure, platform, or service) to a cloud can range from quite simple—some sort of P2V, a mailbox migration wizard, and a bit of DNS fiddling or the like—to the quite difficult, as in having to rewrite some mission-critical application to make it cloud-ready. No matter how it goes, moving into the cloud requires time and money and presents risk. But hey, it won’t be that bad, as the cloud vendor has done it many times before (hopefully), has developed a bunch of tools and expertise to make it all happen as smoothly as possible (hopefully), and so you’re not alone in your journey in-cloud (hopefully). But what about when you want to get out? Well, given that cloud vendors are running businesses and not charities, it’s not unreasonable to imagine that migrating your IT assets out of the cloud, should you need to, might be a journey that you’ll have to undertake alone.
So what does that mean? Simply put, it just means that moving to a cloud involves risk, and well-run IT shops manage risk by understanding it and incorporating it into their disaster recovery/business continuity plan. (I used to help people create DR plans, but if you call them business continuity plans, you can charge more, or so it seems.) Put something new, like a big SharePoint server, into your data center, and the DR folks will look at how it can fail, try to get a handle on how likely that failure is, what such a failure might cost, develop easily-followed, step-by-step instructions detailing how to rebuild and restore a dead SharePoint server and, most importantly, develop those instructions before the server fails. And when I say, “easily followed,” those instructions should be ones that a monkey with a mouse and installation media could easily follow. Don’t misunderstand me here—when I say “monkey with a mouse” I do it not of contempt but because I’ve been around for a few disasters and in situations like that, it seems that everyone temporarily loses about 50 points off their IQ, and few things restore clear thinking in those situations like being able to follow a trusted, well-written set of “in case of emergency do this” instructions.
It’s funny how we tend to get a functional fixedness about the word “disaster.” Before the word “cloud” even appeared in the IT world, everyone knew that disasters can happen sometimes. Ask any seasoned IT type for some examples of disasters, and he or she will have at least one story. A squirrel could decide to chew on the wrong wire, temporarily becoming part of your electrical system and thereby knock out power to your data center. A hacker could steal and sell your data to a competitor. Some crazy people could fly an aircraft into your building. Such events are scary, largely out of our control, and carry the potential to do our organizations some serious harm. But it seems to me that, in fact, organizations face far more risk and far more potential harm from the business decisions that we, the folks on the inside, make. The cloud may be a fantastic thing for you, but you simply can’t know if that’s true until you’re actually running your production network there, and that’d be a terrible time to discover that the door into the cloud goes one-way only, and that you have no idea whatsoever how to get out or how much it’ll cost.
Heck, some people would characterize that as something of, well, a disaster, wouldn’t they?
About the Author
You May Also Like