Everybody wants a flying car.
Wouldn’t it be nice if we could press a button, pull a lever, mash a pedal and rise up out of the traffic, leaving all of the challenges of the road behind? It certainly would, but it would also give rise to a whole new set of challenges, and that’s why we don’t have flying cars.
The flying car approach is however a disturbingly common one when it comes to cloud migration proposals being put forth by those who have not done them. “We will move our servers to the cloud, and all our problems will go away!” is far less reasonable an expectation than “we will migrate our mail to the cloud and quit paying money to keep our Exchange servers running” and herein lies the lesson: migrate the application to the cloud, not the server.
A great illustration of why this is true is Amazon’s Elastic Compute cloud. The two things that are often downplayed or dismissed by advocates of cloud strategies are Amazon’s responsibility for your server instance if it dies (zero) and the rate of failure of the elastic block storage underpinning most server instances (up to .5% per year). The third thing that is probably not taken seriously enough is the cost of running and administering a cloud server instance, at Amazon or at any other provider for that matter: you are often adding a dependency on a skill set (managing cloud infrastructure) in addition to the skills needed to administer the server you migrated, and while you’re not paying for space in a datacenter you ARE paying by the hour to keep servers running. Amazon’s pricing calculator comes as a shock to most people who have never used it. It turns out that what Amazon and its competitors are mostly good at is providing dynamic capacity for applications that require it, when they require it, and when those applications have been architected to take advantage of it.
After all the costs are taken into account, you will probably determine that there are definitely applications (mail and DNS being great examples) that are quite cost-effective to take to the cloud if uptime and administration costs are a factor. You will also quite probably determine that for applications you can’t get from a cloud provider, your static server capacity needs are most cost-effectively met somewhere between the server room in your office or a rack in a datacenter. I feel a lot better about placing a server in a datacenter with solid power, cooling and redundant paths to and from the internet than I do about trying to build those traits into a server room, and you have to think about those costs and the impact on your business if they’re not present.
It’s always good to think about uptime and the total cost of ownership, and it’s great to know what goes along with migrating a given application to the cloud. Just be sure you’re looking at the problem in the right way. As I hit the 9th-street on-ramp at 5:30 today, I’m pretty sure I’ll be wishing my car had a Z-axis, but I’m pretty sure I wouldn’t want it attached to my VW.