Getty Images/iStockphoto
4 best practices to avoid cloud vendor lock-in
Without proper planning, an organization could end up feeling trapped in its relationship with a cloud provider. Follow these tips to avoid vendor lock-in.
The cloud is a great resource, but sometimes a service provider, deployment, or architecture doesn't provide what you need. Taking steps ahead of time will ensure you don't get locked into a cloud platform.
Each major public cloud provider has differentiators, and you need to find the right fit based on your business goals. "But if those goals change or other applications would be better suited with a different provider, you want to be able to move workloads and get the best available," said Oliver Presland, a vice president at Ensono, a hybrid IT services provider.
To mitigate vendor lock-in, you first need to ask if your application belongs in the cloud. Then ensure your app is portable if you need to move to another provider.
Follow these best practices to ensure the best possible outcome for your application and business goals. However, keep in mind that vendor lock-in is not always bad if it "provides a unique capability that enables you to differentiate from competitors," Presland said.
Assess apps before migration
Before you migrate an application to the cloud, ask if that workload belongs there in the first place. Questioning whether to migrate an application was more relevant when enterprises were undecided on their cloud future, said Yugal Joshi, principal at Everest Group. A cloud exit strategy is not cheap. Perform a thorough analysis of the perceived benefit and the total cost to reduce regret later.
To make the move to the cloud, you need to focus on prioritization, feasibility and business case. During this process, you may discover workloads that are either complex, have regulatory burdens or do not make economic sense to migrate to the cloud.
You also need to consider the cost of what the application connects to, said Erik Costlow, senior director of research and product for Azul, a Java development platform. For example, Costlow worked with a business that wanted to migrate 300 applications to the cloud. The migration of five of those blew the budget for the entire year because the company didn't anticipate how large the storage requirements would turn out to be.
In some cases, increased costs could be acceptable. Some of the top benefits to weigh against these costs include IT efficiency, faster updates and improved scalability, said Kevin Beasley, CIO at VAI, an ERP solutions provider.
Increase application portability
You should consider ways to ensure application portability. Portability means minimizing how many changes need to be made to move an application from one cloud provider's environment to another. To minimize those changes, use services common to multiple clouds.
Presland recommends companies look at each workload's design, dependencies and technology stack. Then consider how this affects its portability to the cloud and, in the future, between clouds. This analysis can help you weigh the cost of specific measures against the benefit of access to cloud-specific services.
Joshi recommends enterprises ask why they seek portability in the first place. Assess how often earlier applications moved off a platform. If they haven't had to do this, then they should be less concerned about portability. "There are very limited instances of enterprises moving important workloads between clouds," Joshi said.
Tim Hinrichs, a co-founder of the Open Policy Agent project and CTO of Styra, recommends configuring non-Kubernetes resources with a cloud-agnostic tool to increase portability. For example, Terraform spins up infrastructure in the same manner across different cloud platforms. Cloud-agnostic tools can ensure that security, compliance and operational controls will not change, even if your organization's cloud service does. Cloud-agnostic APIs used by multiple clouds, as with Amazon S3, can also help.
In his experience, building portability can slow cloud adoption and make it more expensive. Scenario planning can help enterprises make a pragmatic assessment of what enterprises stand to lose in a lock-in scenario. This can prioritize which workloads they want to build or migrate that must be more portable than the others.
Explore container use
Containerization, which uses an abstraction layer, can lead to portability because it can run on top of various cloud platform layers. It may make sense to use a container model for apps that would benefit from disaggregation into business functions that can be updated or scaled independently.
However, other applications might not benefit from this change of deployment architecture. They may run on software that is not compatible with a container. Presland recommends implementing a proof of concept when considering conversion to a container.
Cooper Lutz, chief architect of digital solutions at AHEAD, a consultancy, said the underlying container orchestration technology could have its own elements of lock-in. However, this requires a lower effort to replace the container orchestration layer instead of rewriting a tightly coupled, monolithic application to exit a hardware lock-in situation.
Eli Zilbershtein, senior engineering manager at Hippo Insurance, also recommends building an abstraction layer between your applications and cloud service. For example, Hippo uses Loggly for log management. Since the company's applications use an internal library to send logs, it would be simple to switch to another logging vendor. Thanks to this abstraction layer, making such a switch would require only a single change in the logging library rather than changes to the application code.
Consider the data and workflow dependencies
Consider the data that the application relies on. "Data can be more expensive and more difficult to move than the application," said Nitha Puthran, senior vice president of cloud and infrastructure at Persistent Systems, a digital engineering provider. Enterprises need to decide whether to always have the data in multiple clouds, to migrate it when required or to leave it where it is and access it remotely.
Additionally, be sure to document workflow dependencies. Enforce a tagging and metadata convention and understand and document workload dependencies before a migration.
