freshidea - Fotolia
Beat vendor lock-in with a cloud exit strategy
Without a comprehensive cloud exit strategy, an organization might fall victim to vendor lock-in and find itself dependent on proprietary tools and services.
A well-planned cloud exit strategy alleviates the pressures of vendor lock-in. 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.
A cloud exit strategy for AWS users, specifically, should take into account not only the AWS cloud itself, but also third-party services -- particularly SaaS applications -- that touch your AWS infrastructure.
Build an exit strategy from the start
A cloud exit strategy shouldn't be an afterthought. Instead, a company should formulate this strategy during its initial cloud planning phase, according to Elias Khnaser, research vice president at Gartner.
"An exit strategy should be developed as part of the overall organization's cloud strategy," Khnaser said.
Upfront planning is key, as exit requirements can ultimately influence whether an enterprise decides to migrate existing applications to the cloud or build new ones there instead. For example, if an organization simply lifts and shifts an existing app and its associated databases to run in containers on EC2, then it will be relatively straightforward to migrate that application off the cloud. However, that application will not achieve the same operational and cost benefits as an application that is refactored, or designed from scratch, to take advantage of native AWS offerings.
Determine early on if the exit strategy will apply to your company's entire cloud application portfolio, or if it will only pertain to specific applications. "I always advise customers to assess an application's exit strategy when evaluating that application's readiness for cloud," Khnaser said.
Revisit a cloud exit strategy and update it on a regular basis. This ensures the plan reflects the changing landscape of available cloud services, as well as the evolving IT and business needs of the organization.
Construct a detailed plan
Enterprises should include a variety of stakeholders when they construct a cloud exit strategy, including those responsible for the contractual, technical, legal and data governance aspects of the business. These different viewpoints can raise important considerations. Are there hidden costs to scaling up or down? Who bears responsibility when the cloud infrastructure or service goes down? Where is the data physically stored and how will this impact any regulations or compliance issues?
The strategy needs to be comprehensive and anticipate what could happen at the end of a relationship with a cloud provider, said James Meadows, founding partner of Culhane Meadows, a national technology law firm based in Dallas. It should address as many credible scenarios as possible, such as a key third-party service on cloud going out of business, a data breach or migration to another cloud provider.
"This is not a 'check the box' exercise," Meadows said.
Consider the human factors involved in a cloud exit strategy, said Jeff Lazarto, commercial advisory practice leader for Oracle, Workday and AWS at UpperEdge, a cloud negotiations consultancy based in Boston. These include organizational readiness, sourcing new services and teaching employees an alternative cloud option as part of the exit.
For example, there are substantial costs associated with the vendor sourcing process, which involves proposal requests, demos and relationship development with different cloud service providers. There is also a cost associated with training staff to learn a different cloud service.
Watch out for hidden costs
There are several hidden costs that enterprises should consider as part of their cloud exit strategy, Khnaser said. Before committing to one cloud vendor, enterprises should ask:
- If going back on premises, do we have the necessary hardware?
- Will we still have a data center at the time of the exit?
- Will we need colocation?
- Will the application being moved require any development work?
- Will we need to retrain our user base? If so, how long will that take?
- What is the cost to the business of any reduced productivity due to the switch or exit?
Cloud repatriation for IaaS vs. PaaS vs. SaaS
In general, if organizations use the IaaS layer of a provider's platform -- VMs and containers, for example -- then the repatriation process is relatively straightforward, Khnaser said. On AWS, this layer includes services like EC2, Amazon Elastic Container Service and S3. An AWS exit strategy gets more complicated as you build cloud-native applications with PaaS layers, such as AWS Lambda and AWS Elastic Beanstalk, because cloud-native apps need to be refactored to be moved off the cloud provider.
When considering PaaS options, assess the effort required to replace those offerings with on-premises equivalents or services from other cloud providers, Khnaser said. In many cases, it will involve development work.
A lack of cloud data visibility is one of the biggest constraints organizations face with a SaaS exit strategy specifically, Meadows said. Compared to IaaS and PaaS vendors, SaaS providers are more involved than IaaS and PaaS providers when it comes to managing and processing an organization's data, including how the data is structured and where it resides. Enterprise stakeholders involved in the exit strategy should consider which data sets the company might need to extract or transfer, along with data portability and conversion requirements.
In addition, consider data that a cloud service provider might claim to own. This could include analytics or AI models built from data that an enterprise supplies. "This is generally a matter of contract, so by the time the exit is occurring, it may be too late to change anything," Meadows said. These kinds of issues can crop up around different kinds of processing related to SaaS applications. Understand the provider's specific obligations to destroy or erase all data from the service and its systems, as applicable.
