Why Should You Have A Cloud-Exit Strategy?

If I had asked what's your cloud strategy? This would've been much easier. I know some fine people who joke that the cloud-strategy should be so simple that you should be able to explain with just emojis. Well, yeah. Go ??.

Most IT leaders and businesses are overwhelmed by analysts, consultants and cloud-provider-marketing on why they should go to a situation where you want to or is forced to move out of a certain cloud provider. This is about parameters you should factor into your cloud strategy that lays foundation for your cloud exit strategy. . Instead, this is cloud. This is neither about fighting that notion nor is this about telling why you shouldn't go to cloud

Now, why should you have to move out of a cloud provider? And, what's a cloud exit strategy and why do I need it?

After reading so far, if you're one of Verizon's public cloud customers with IT investments, you'd feel at home. You've until the 14th of April to move out your infrastructure and applications as Verizon is shutting down their public cloud. I bet this is not a factor most of you considered during the time you devised your cloud strategy. The activities involved in assessing, designing and deploying applications isn't easy and is 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.

One of the most the important reasons Verizon points out for discontinuing their public cloud offering is that they find their private cloud offering more popular amongst their customers. This is an indication that they couldn't make their public cloud successful. Winning in public cloud business is hard, even for the technologically dominating companies. The investments are unfathomable; financially and technologically. The investment on a single datacenter alone could cost upwards of a billion dollars with the 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. As a customer, does it mean you should just look at Gartner and figure out the leader in public cloud and invest there so you know they won't shut shop and go away? Or, what's the takeaway from this dialogue? 

There is a lot of commotion in the industry about what cloud provider to go with and whether it is going to be the private cloud or public cloud. Most organizations arrive at their right answer by throwing in parameters like existing infrastructure, partnerships, licensing agreements, datacenter investments, everything-Gartner-says, existing skill set and the likes and giving it a whirl. Voila! a lot of people get AWS as their right answer.

From the time prior to the popularity of the public cloud, moving infrastructure meant moving from one datacentre to another. Is that possible with the 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 or from one region to another or from one datacenter to another with minimum downtime, minimum modifications/configuration changes to applications and minimum hassles. We'll analyze this with some examples; as in the case of on-premises when we were to move from one datacenter to another, chances are we had the same virtualisation technology in both such datacenters; Citrix Xen or VMware or Hyper-V; or whatever came out of your whirl. Extending this ability to the cloud means your cloud provider should have had this thought through and have this figured out. The provider should have the ability to serve customers on-premises, in the cloud, and support the ability to move across these. If the provider does not have a strong story in cloud or on-premises you're losing a major aspect of the flexibility. [The way to work around that is containers (hence its popularity), but more on that later].

I'm not suggesting that you develop your cloud strategy always with an intention or foreseeing a reason or ability to move out. For example, if you were to host an application on Google App Engine that operates on unstructured data, chances are your obvious choice of database is the Google Datastore; if you were to plan for an exit-strategy you could go for an IaaS based DocumentDB/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; that Google has already figured out and built such capabilities in Google Datastore. [Read unlimited rows in a Google Datastore with the query speeds faster than electricity, retrieves x items from a billion row db as fast as it would retrieve x items from a 100-row db (I think we're off the topic now...ahem!)] The idea is, PaaS/Microservices from Google or Azure and the likes offer tremendous capability backed by some technologically daunting engineering that offers an immediate capability to your applications and in turn value to your customers. This capability comes with 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. Oftentimes, the benefits of a cloud-native PaaS service far outweighs the preparation and design in anticipation of an apocalypse.

Regardless of your position, it is important to unbiasedly analyze your application for its suitability for the cloud; public or private, IaaS or PaaS, containers or Microservices, or any combinations of those. This means your IT partner or cloud provider should be willing and be able to tag along with you regardless of what suits your application. This means your partner cannot be the one that vehemently talks down either the private or the public cloud. The only reason they have a disproportionate affinity to either private or public is because they are or they represent a cloud provider that has just one of those and cannot support the other. This means not all lock-ins are created equal, there are bad ones and there are very bad ones. 

So, while some cloud strategies can be simple and easy; cloud-exit strategy deserves to be through well enough as well in anticipation of a Verizon-like situation. Just that this is probably gonna take a lot more emojis to elaborate.