Do You Have A Cloud-Exit Strategy?
If I had asked ‘what's your cloud strategy,’ it would've been much easier. I know some people who joke that your cloud strategy should be so simple that you should be able to explain it with just emojis. Well, yeah. But most IT leaders and businesses are overwhelmed by the abundance of information available from analysts, consultants and cloud-providers about why they should go to the cloud. This blog is neither about fighting that notion nor about telling you why you shouldn't go to the cloud. Instead, this is about a situation where you want to or are forced to move out of a certain cloud provider. This is about the parameters you should factor into your cloud strategy that lay foundation for your cloud exit strategy.
Now, why should you have to move out of a cloud?
After reading thus far, if you were one of Verizon's public cloud customers with IT investments, you'd feel at home. You had until the 14th of April to move out your infrastructure and applications as Verizon shut down their public cloud. I bet this is not a factor most of you considered when you devising your cloud strategy. The activities involved in assessing, designing and deploying cloud applications are not easy and are expensive. Add the exercise of having to figure out how to move the infrastructure out, and most importantly, where to put them this time around, - and it gets more complex.
One of the most of important reasons Verizon points out for discontinuing their public cloud offering is that they find their private cloud offering more popular amongst their customers. Winning in public cloud business is hard, even for technologically advanced companies. The investments are unfathomable; financially and technologically. The investment on a single datacenter alone could cost upwards of a billion dollars, with returns not coming back anytime soon. The ability to build several such datacenters at the same time in various geographical regions, handling local regulations, compliance, and marketing- all at the same time - is incredibly hard. All of that while technologically innovating to make the platform robust, mature and popular.
Let us look at another aspect; the aspect of deciding which cloud provider to go with and whether it should be private cloud or public cloud. Most organizations arrive at the right answer by looking at parameters like existing infrastructure, partnerships, licensing agreements, datacenter investments, analyst reports, skill sets and the likes, and into a complex excel sheet and run some canned calculations. And voila! Most people get AWS as their right answer.
So what is the takeaway from these examples? It’s this. Even when you choose to partner with a leading service provider or even though you have followed a well-structured method, chose a particular cloud, unforeseen events may force you to exit the cloud.
What is a cloud exit strategy and why do you need it?
Prior to the popularity of the public cloud, moving infrastructure meant moving from one datacenter to another. Is this possible with public cloud? One of the design principles involved in exit-strategy is to validate the ability to move from on-premises to cloud and vice versa, from one region to another, or from one datacenter to another with minimal downtime, modifications to applications and hassles. We'll analyze this with some examples. In the case of an on-premises move from one datacenter to another, chances are both datacenters have the same virtualization technology, whether it is Citrix Xen, VMware, Hyper-V; or whatever your analysis lead you to choose. Extending this ability to the cloud means your cloud provider should have thought this through and have this figured out. The provider should have the ability to serve customers on-premises, in cloud, and support the ability to move across the two. If the provider does not have a strong story in cloud or on-premises you are losing a major aspect of the flexibility. One way to work around that is to use containers and hence its popularity (will write another blog on this later!)
Let us take an example where you host an application in Google App Engine that operates on unstructured data, chances are your obvious choice of database is the Google Datastore; if you were to plan an exit-strategy, you could go for an Infrastructure as a Service (IaaS) based Document DB/MongoDB, either in cloud or on-premises, or with another cloud provider. But, this is an expensive affair depending on the complexity of your application. Also, Google has already figured out and built such capabilities in Google Datastore (Unlimited rows with query speeds faster than electricity...ahem!) The idea is, Platform as a Service (PaaS/ Microservices from Google, Azure and the likes offer tremendous capability backed by some technologically daunting engineering to provide immediate capability to your applications, and in turn, value to your customers. This capability comes at the cost of a tight lock-in. It is up to you to strike the right balance between flexibility and ease of exit on an ‘application to application’ or ‘business to business’ basis. I'm not suggesting that you develop your cloud strategy always with some intention or ability to move out, but it is important to know you should have one and it is not easy.
Plan ahead to avoid disruption
Regardless of your position, it is important to unbiasedly analyze your application for its suitability on the cloud - public or private, IaaS or PaaS, Containers or Microservices, or any combination of these. This means, your IT partner or cloud provider should be willing and able to tag along with you regardless of what suits your application. It also means, your cloud partner cannot be the one that decides for you if it’s either the private or the public cloud. Know that while all clouds have lock-ins, not all lock-ins are created equal, there are bad ones and there are very bad ones. Hence a cloud-exit strategy deserves to be thought through well in anticipation of a Verizon-like situation. And that this is probably going take a lot more emojis to elaborate.