Breaking up with the Cloud: Crafting an exit plan

Today, businesses are rapidly getting digitally transformed on the back of innovative solutions including Artificial Intelligence, Machine Learning and LLM language models like ChatGPT. Cloud infrastructure and services have played a crucial role in providing impetus to these innovations, and truly made it possible to deliver next-gen applications with speed and efficiency.

That said, many organizations are still hesitant before adopting Cloud technology due to their business nature, associated risks, diverse regulatory rules, and compliance across the globe. Additionally, concerns about an organization’s readiness, skills, and capability to fully benefit from Cloud offerings, as well as the cost and risks associated with a multi-year migration project, may hinder innovation and justify the journey.

Once the decision is made in favor of Cloud adoption, everyone gets excited to embark on the journey, and starts planning for migration. But they often neglect to plan what if things go wrong with a Cloud Service Provider (CSP) in future for various reasons, mostly beyond its control. What options it would have, which can be executed without delays, minimizing the impact on the business?

Clearly, an organization needs a thoughtful Cloud exit strategy to have minimal disruption due to an adverse situation. Let me define what I mean by Cloud exit strategy. It is a plan developed by an organization to ensure that the Cloud services that support business activities can be replaced or replicated efficiently to other CSPs or on-premise, and without significant disruption to the company. In a recent study by Forrester Consulting, 85% of IT decision-makers agreed that exit is a critical part of their hybrid Cloud strategy.

Key drivers

Early adoption of an exit strategy is crucial for organizations migrating to the Cloud. Let’s examine the key drivers for this approach.

The multi-year lock-in trap: Organizations often begin their Cloud journey with one CSP for various reasons, such as skill shortage and cost savings through long-term contracts. However, lock-in with one provider’s proprietary services and pricing model is a significant concern. Flexibility to switch to different CSPs at any point is crucial.

Compliance and Regulations: Data localization and privacy laws in certain countries may necessitate a multi-Cloud or hybrid approach. Concentration risk also needs to be managed for regulatory reporting (e.g. FCA & PRA), especially in financial services. Even a brief downtime of a critical system can have catastrophic effects on the entire banking system.

Cloud outages are costly: Cloud performance optimization company GlobalDots calculates the cost of downtime as $5,600 per minute for the average business. Over the years, each of the major Cloud providers had outages lasting from a few hours to days and many businesses suffered frequently from these outages. Organizations need to plan for faster failover and disaster recovery. Having a multi-Cloud or hybrid strategy could be a lifesaver.

Innovation: Finally, leveraging niche offerings from a CSP enables innovation and helps the business respond better to new market opportunities, e.g. leveraging Vertex AI & AutoML offering from GCP to build an ML platform.

Tech & Design considerations supporting an exit strategy

An organization should formulate a Cloud exit strategy at the beginning itself while framing a Cloud adoption strategy instead of approaching it as an afterthought. Exit strategy influences the solution design and choice of technology stack significantly.

While deploying an application in a multi-Cloud environment, your choice of Cloud-native services may differ significantly from those in a single Cloud. For instance, using NoSQL databases such as MongoDB/CouchDB or Cassandra may be better than Cloud-native options like Azure Cosmos DB or GCP BigTable or AWS DynamoDB. Similarly, Apache Kafka may be preferred over Cloud-specific options like Azure Event Hub or AWS Kinesis or GCP Pub/Sub for messaging backbone.

Additional considerations:

Automate Cloud infrastructure using IaC (Infrastructure as Code) configurations i.e. Terraform. Though you’ll need to create separate Terraform scripts for each CSP in a multi-Cloud strategy, replicating them is easy. You can even use ChatGPT to transform AWS Terraform scripts to Azure, which serves as a good starting point. If not keeping multi-Cloud IaC code ready, maintain a mapping of resources between CSPs, configuration changes in GitHub, and blueprints design.

Opt for Open Source solutions whenever possible. Even though CSPs try to make these solutions ‘sticky’ to their platform, it is still much less work to transition to another Cloud. For instance, use Kubernetes and Containers for your microservices, use Kafka for messaging backbone, MySQL / PostgreSQL for RDBMS needs, MongoDB for NoSQL requirements and such. Using CSP-native services would incur expensive architectural changes if needed to exit.

Design solutions to facilitate data portability and interoperability, while also meeting regulatory requirements for an exit plan. Take into account third-party solutions, licensed products, and frameworks that are available across major CSPs.

Categorize the application portfolio into business critical, important, and non-essential/peripheral applications. Define the recovery point objective (RPO) and recovery time objective (RTO) for each application, as not all applications hosted in the Cloud require real-time failover to another Cloud or exit to on-premise. The exit strategy should outline how to handle each category of apps.

And finally, upskill your teams on the multi-Cloud environment to ensure that they can work efficiently in the new environment.

Some Caution

While developing Cloud capability for a secondary Cloud provider as part of the exit strategy is crucial in the longer term, it should not be progressed to the detriment of diluting the overall competence and capability development of the primary Cloud provider. A fine balancing act is required between competing priorities and having an effective exit plan meeting the cost, risk and innovation objectives. Additionally, operating multi-Cloud increases operational risks for an organization.

Also, building applications in a Cloud-native manner and fully integrating them with a Cloud provider’s services offers several advantages, such as a better solution offered in the Cloud, seamless integration, and reduced development and operational time. Some may argue that this is the only way to deliver true value from Cloud migration.

Summary

It’s hard to have one universal, sweeping exit strategy which would work for every organization. Like everything else in life, it depends on the organization’s context, business criticality, technical maturity of firmwide solutions, skills of people and a cost-benefit analysis. Leaders must adopt a grounded approach that enables smart decision-making, a favorable risk-reward ratio, and the ability to innovate to beat the competition.

The bottom line is, you should always have a Cloud exit strategy, because it’s not a matter of if you’ll need one, but when.

Also published in TimesTech: https://timestech.in/breaking-up-with-the-cloud-crafting-an-exit-plan/