Multi-cloud is now clearly emerging as a strategic driver for many organizations as they seek to innovate and build a competitive edge. However, this shift brings with it challenges, many of which I discussed in a prior blog series. With organizations seeing increased complexity, projects falling short of targets, and growing cloud consumption bills; these challenges, if not addressed, can drive negative impacts that offset the business value gained from leveraging the public cloud.
But what if your organization had to either reduce its footprint or exit all together a public cloud provider? Would this be a smooth transition to a new provider or data center? Or would the organization simply contend with all of the same challenges they faced when they first ventured to the cloud.
In this two-part blog series, I will explore the now very real concept of having a “cloud exit plan”. I’ll also explore the challenges and strategic decisions you make when first deploying an application to the public cloud. Decisions that will make the use of an exit plan, if ever required, easier or harder to execute.
Different approaches to the cloud
For many, there are two schools of thought that come into play in this strategic discussion. There are those who claim that in order to gain the maximum benefit from public cloud, it must be fully embraced, without fear of lock-in. Building applications in a cloud native manner, running natively on the public cloud and fully integrating their application with a cloud provider’s higher level cloud services. This group argues that this is the only way to deliver true value from the public cloud.
On the other side of this discussion, are those who want a greater level of flexibility with public cloud adoption. They fear cloud consumption bills growing out of control and vendor lock-in. The fear having to live with an inability to negotiate best price status from a cloud provider who is deeply aware that their applications have a deep dependency on their higher-level PaaS offerings.
Even if an organization never actually moves cloud workloads back on premises, a process known as cloud repatriation, an exit strategy can guide negotiations with providers and influence application design. But what is the right approach? Well that of course depends on the business requirements and the strategic direction of the organization.
There is no single approach that will fit all scenarios. At the end of the day, CTOs and business leaders must make a judgment call on which of the two approaches, or a balance of the two, is right for them. However, when it comes to considering a “Cloud Exit Strategy” the second option can vastly simplify ending your relationship with any particular cloud provider.
Why you need a “Cloud Exit Strategy”
For reasons of corporate governance or compliance, many organizations are now realizing they need a “Cloud Exit Strategy”, even for applications that run in a key global provider’s space. Providers such as Microsoft Azure, AWS and Google Cloud.
The concept of ‘Cloud Exit’ is simple. Some refer to it as a ‘reverse migration’, but simply put, a cloud exit strategy is exactly as it sounds. It is a corporate plan developed to ensure that the cloud services that support business activities can be replaced or replicated efficiently and without significant disruption to the company.
There are a number of specific and good reasons why an organization might be considering a cloud exit strategy. Firstly, having such a plan already in place can help a business maintain a higher level of business continuity and reliability by protecting against recurring outages.
While the majority of public cloud providers deliver exceptional uptime on highly reliable services, even the big players in the market have in recent years experienced significant outages. In the coming years, if this continues to be the case, an organization would either have to consider changing vendors, building a DR solution between vendors or leveraging multiple vendors to achieve higher levels of availability.
The second reason for an organization to develop a cloud exit strategy might be driven by the need to access innovation that can help the business better respond to changing market opportunities. Multi-cloud is all about exploiting the unique capabilities of different clouds, rather than going ‘all in’ with a single cloud vendor. For example, an organization might want to leverage new cutting-edge technology that a cloud provider that they are not currently using introduces. Alternatively, a cloud provider might sunset or no longer support a particular application or service, leaving the application team looking for a replacement solution.
Legal requirements and regulations can also be a key driving force behind a cloud exit strategy. For instance, data residency requirements across Europe are increasing. The European General Data Protection Regulation (GDPR) sets out rules on how personal identification information must be handled for EU residents. If your current provider is hosting this type of data in locations that under GDPR are prohibited, your organization will need a plan to move that data to another provider, as the owner of the data, not the cloud provider, is accountable for meeting compliance.
Finally, having a well-planned cloud exit strategy alleviates the pressures of vendor lock-in. Having a ready-to-go cloud exit strategy might let you take advantage of better pricing and more attractive discounts by giving you more leverage in financial negotiations. It is noteworthy to highlight here that avoiding vendor lock-in can also be addressed through well architected solutions and designing applications to be more cloud agnostic, making them and their data more portable. For instance, if this is a key business requirement, avoid cloud lock-in by designing applications that:
- Rely on easily replicable infrastructure
- Avoid propriety cloud features when possible
- Abstract APIs as much as possible
In general, as illustrated in figure 1, if organizations exclusively use the IaaS layer of a cloud provider’s platform, virtual machines and containers, for example, then the repatriation will be easier, even at scale, then if your application has many dependencies on higher level PaaS offerings.
Figure 1: Understanding the scope of public cloud lock-in
On AWS, the IaaS layer includes services such as EC2, EKS, and S3. This is where the VMware ‘Any Cloud, One Platform’ strategy comes in, but more about that later. However, an AWS exit strategy becomes increasingly more complex as you build cloud-native that leverage AWS PaaS offerings. Cloud services such as AWS Lambda and AWS Elastic Beanstalk are representative examples of higher-level cloud services. Applications built using these higher-level services will largely need to be refactored if you choose to move them to a different cloud provider.
Finally, and we are now entering a world of unthinkable changes in approach by public cloud vendors, but what if a particular cloud vendor decided to sell customer data or metadata to marketing companies or even to a hostile state. Or what if one of these vendors decided to exit the cloud business altogether and go back to selling books? While these scenarios might appear unthinkable, the one thing we have learned living through 2020, is that nearly anything is possible.
Looking ahead to part two
In part two of this blog, I’ll discuss the need to have a plan for any app that is critical to the success of your business. I’ll also address the additional complexity that PaaS and SaaS bring to the table. Then we’ll look at one particular approach to multi-cloud that will really simplify how you approach the need to have exit plans for apps and that will also allow you to take full advantage of the variety of innovation that hyper-scaler cloud providers bring to the table.
Learn More
Interested in learning more about how VMware can help you architect a multi-cloud solution for your organization. Check out these two resources:
- Looking to better understand VMware’s unique approach to multi-cloud architecture? Get the definitive guide
- VMware Multi-Cloud Podcast: This Podcast series on SoundCloud interviews VMware technical leaders and explores how VMware Cloud offerings can help you architect a multi-cloud environment that accelerates application modernization across a multi-cloud landscape.
- VMware Cloud on AWS Reference Architectures: This collection of reference architectures details how to deploy various application and hardware stacks in a hybrid cloud model that includes VMware and AWS technologies.
