Dec 5, 2013
For any CIO who has not done it yet, cloud on-ramping will still be a major worry-point. And it is not just whether or not to migrate your applications to the cloud — although in some ways that is the more important question — but how to migrate them.
At the risk of stating the obvious, enterprise applications are not mobile apps, although once an enterprise app is cloudified it can offer many of the same advantages, such as access from anywhere that you can get a signal, and on any connected device. While the data volume involved in enterprise apps is a major differentiator — there can be a heck of a lot to transfer, and of course you will probably want to keep it in synch with your on-site servers while the migration takes place — there is a lot more to it than that.
My friend Clive has covered the data transfer issues on this very blog so I am not going to go over them again. But if you are indeed inclined towards cloudification — what a lovely word! — there are several other questions that you also need to think about. In particular, I would highlight application migration, cloud bursting, and perhaps most important of all, backup.
Application migration issues will affect some apps more than others. If you are using standard apps, then with a bit of luck you can provision those on your cloud service and migrate your data. Job done — perhaps… But if your apps are non-standard or bespoke, cloud on-ramping will be rather more complex.
Luckily, complex doesn’t mean ‘show-stopper’. There are numerous tools around which can convert the original server to a virtual machine (VM) and port that. There are even tools such as AppZero which can virtualize and move just the application — this can hugely speed the process, because a virtualized app is a lot less data to move around than an entire VM. Once virtualized, the server or app can of course be moved to an offsite cloud provider or between data centers in a private or hybrid cloud model. A clean slate would of course be preferable in many ways, but still, existing apps can be on-ramped if need be.
Then there is cloud bursting, using the public cloud to add extra load-bearing capacity as needed. This assumes that your systems have been architected (or re-architected) for the cloud, with tiers and pools of discrete services implemented as VMs, such as Webservers and database servers, that can be spun up as required. Bursting means that once your own server pool is exhausted, you rent extra short-term capacity from the cloud and spin up some more VMs there. It’s a more efficient way of handling spikes in demand than buying enough capacity yourself to meet all eventualities — if that were even possible to do.
Again, if you burst, what will you need to move around? Can you rent compatible Web services or will you need to copy over the template for a VM? And if you do, have you got the bandwidth and the WAN optimization in place to do that?
But perhaps the most worrisome aspect of cloud on-ramping is, as ever, backup and restore. Do you need a backup of your cloud data? Absolutely yes!
Ownership is all
It is vital to remember that on the cloud you very rarely actually own anything. Instead, you will be renting the resources you use, for however long you want to use them. Whether those resources are VMs, cloud storage, databases or even applications, they are only available to you for as long as you pay for them — and for as long as your cloud provider stays in business.
So what happens if your cloud provider goes bust, as Nirvanix did not so long ago? Or what if you simply want to change providers? With conventional on-site hardware and software, the stuff is still there and you can carry on using it. Your contract may even provide you with a copy of the source code if your software developer goes out of business. On the cloud though, you may not even get a chance to migrate your data back before it is lost.
Even if your cloud provider suffers a serious outage, your data could be lost. You might assume the provider will have backed it up, but all too often, when you check the fine-print it is ultimately the customer’s responsibility to protect their own data.
All that means you need contingency plans, whether it is data replication to your own site — again, if you have the WAN capacity in place — or backup to another cloud provider. The latter can be challenging, given that cloud providers usually do not make it easy to replicate to a competitor, but it can be done. There are even tools, such as Asigra Cloud Backup, which can offload the job — in essence, they backup in the cloud from one provider to another.
It seems counter-intuitive, but moving to the cloud does not mean you can stop thinking about disaster recovery. Sure, the potential disasters are a bit different, but their impact could be just as catastrophic to your business, so the more you think about and plan for them, the less impact they will have.