What’s Your Cloud Exit Strategy?

One of the promises of cloud is workload portability; the ability to move workloads seamlessly between on- and off-premise and between different cloud providers. But sometimes, making the wrong architectural choices can hinder that flexibility. If your cloud provider suddenly increases their prices or has technical issues, can you quickly and easily move to another? 

Have you taken advantage of the underlying platform? Cloud providers compete not just on price and availability, but on additional features above and beyond the standard VM platform (such as Amazon’s IAM). It can be tempting to build your virtual machines and applications to use these features, but what happens if you want to change provider? Will these features still be available, or will you have to undertake an expensive redevelopment exercise? I met recently with Fedr8, who have a useful code analysis tool which can tell you whether your application will run in a given cloud environment. 

Have you used standard PaaS services? Most PaaS providers will offer backend services such as databases, reporting, monitoring etc, but make sure you choose well-supported options. MongoDb and Redis might be widely available, but if you choose a more esoteric database, you’re potentially limiting your choice of providers.  Of course, this can be a trade-off. If you want to take advantage of IBM’s Watson cognitive computing, for example, you’re going to have to use IBM’s Bluemix.

How easy is it to ‘flick the switch?’ OK, so you’ve decided to move from Amazon to Rackspace. How do you configure that within your own systems? How do you stop users from doing what they’ve always done? The answer lies in a good cloud orchestration platform – a front-end which hides all the complexity from the users. If a developer needs a new dev/test platform, they can have one – it will exist with a new provider, but the user doesn’t need to know, nor should he care. An orchestrator can also manage long-running environments – shutting them down and moving them without disrupting users. 

What about commercials? It may sound obvious, but if you’ve signed a contract with a cloud provider that commits you to future payments, then nothing architectural is going to help you. Be aware of the contract terms you’re signing up to, and try to stay on pay-per-use until you’re sure you’re happy with your provider. 

What happens to ‘dead’ environments? One of the reasons organisations choose to leave a provider is regulatory – a government decides that customer data can only be held in-country, for example. So what happens when you click the ‘delete’ button on a virtual machine? Is the provider contractually responsible for securely destroying that data? If not, then it should definitely be part of your lifecycle management processes. 

In summary, moving from one cloud provider to another should be easy, but can have challenges. A little up-front thinking, combined with a good orchestration platform for governance can go a long way to help. 


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s