Vendor Lock-In: What Is It and How Do You Avoid It?
Dont pull all of your eggs in one basket. Chances are you have heard this piece of advice before. Annotated with the context of cloud native app development, it might read dont put all of your (data, APIs, services, applications) in one (cloud service provider)."
While this idiom generally refers to the concept of avoiding the investment of all of ones energy or resources into a single venture at the risk of losing everything, in this context, the risk of locking in to a single vendor is a different cost: budget, manpower and time. When migrating an application to the cloud and selecting a cloud service provider, this cost weighs heavily on the mind of every IT manager.
So what is vendor lock-in? How can it affect cost? Vendor lock-in refers to the measures that different service providers take to ensure that customers will have a difficult time when trying to migrate away from the vendors ecosystem.
It creates an environment where a customers business becomes completely reliant on the support of a single vendors products and services. With many organizations making use of a range of services from cloud providers (IaaS, PaaS, SaaS and FaaS), there is a great deal of potential for vendor lock-in to apply. Todays vendor lock-in is tomorrows technical debt.
The perils of vendor lock-in
When an organization does not diversify where their applications are running (IaaS, PaaS) and tightly couples their business logic (SaaS, FaaS) with a single cloud provider, a wide variety of issues can occur.
Price hikes and service degradation
As your company innovates, so too do cloud service providers. New products and features are constantly being shipped, with each provider looking to keep a competitive edge. If your systems and services are tightly integrated with a single cloud provider, it is much harder to move away if that cloud provider doesn't remain competitive.
Proprietary formats
Some cloud service providers use proprietary methods to store data and configure services. While these methods typically make it much easier to use the vendor platform, it also creates an environment that is not portable. Migrating your applications to a different provider will become cumbersome.
Limiting innovation
Restricting your business to a single cloud provider limits you to its roadmap. If another provider starts offering a service that is ideal for your specific needs, you won't be able to take advantage of that.
It also restricts development teams from choosing the best tool for the job and can slow down onboarding of new teams, as they have to migrate to your chosen vendor. When going through mergers and acquisitions, being locked in also slows down the process of integrating a new company's technology and could even place restrictions on what can be integrated.
Single point of failure
Although cloud providers boast impressive SLAs with all the nines, outages still happen, taking your services down with them. Lock-in may pose substantial challenges in defining failover and disaster recovery strategies.
Open formats
Ensuring the portability of your organization's applications is a good place to start when looking to avoid vendor lock-in.
Data is the most valuable commodity to a service provider and oftentimes the hardest piece of an application to migrate. Keep it in a common format to allow migration from platform to platform. Cloud service providers make it easy to use their proprietary managed data management platforms.
Steer clear of using proprietary data tooling in favor of using more open, widely used database management systems. MySQL, PostgreSQL and MongoDB are three great open source options that provide a premium feature set while enabling efficiency and scalability.
Leveraging open source technologies and modern standards will help to avoid being locked in to any proprietary standards. For example, OpenAPI specifications are the norm for designing and documenting APIs. Well-designed and documented APIs will allow for the maximum portability between platforms.
In the DevOps realm, using an open source system such as Jenkins can integrate with any cloud provider. If your organization is making the move to a container-based or microservice architecture, consider using Kubernetes for deployment and scale orchestration.
When developing applications, maintaining an open-format-first approach will help to select the best tool for the job. Selecting tools based on strengths, rather than vendor merit, will help to avoid using one cloud service provider for everything. The basics of writing good software apply too.
Ensure that the application is broken up into manageable, reusable components - that it is well organized, designed in a way that is easy to understand and is well documented. Keeping these values in mind will help to build a highly portable system. Maintaining portability will make it easier to switch between different service providers when the time comes.
Infrastructure alternatives
When deciding how or where an application is going to run, there are many viable alternatives to using a single cloud service provider. There are pros and cons with the following infrastructure patterns, but having options will allow teams to implement the best design for their use cases.
On-premises only
For: The organization most concerned with security and governance that wants complete control over data, hardware and software
Avoiding the cloud altogether means you need to invest in infrastructure upfront, provision sufficient capacity and retain expertise. This approach can be expensive; however, it does provide organizations with the highest level of control over their applications and services.
Private cloud
For: The organization that wants the same level of control that on-prem provides with the added flexibility and scalability of the cloud
Some organizations choose to build their own virtual private cloud (VPC). While building your own comes with setup costs and requires expertise for ongoing maintenance, a VPC ensures you keep control of your own data.
Multi-cloud
For: The organization that wants maximum flexibility in its managed services
A multi-cloud approach involves multiple cloud services platforms rather than one. The risk is spread and allows you to choose best-of-breed solutions. This approach does require specialist knowledge of a variety of platforms and providers but also helps when negotiating for the best price per platform.
Hybrid cloud
For: The organization that wants the flexibility of multi-cloud, coupled with the control of on-prem and private cloud architectures
A hybrid cloud (combination of on-premises and multi-cloud) approach is the best of all worlds. It retains flexibility, spreads risk and allows you to choose the best option for different use cases. This architecture can help to increase the agility and innovation needed to react to business demands, while persisting operational autonomy.
Wrapping up
Vendor lock-in can come in different forms, but the outcomes can be the same:
- Price hikes and service degradation
- Reliance on proprietary technology or configurations
- Limits on innovation
- Single point of failure
Cloud service providers make it easy to become locked in to their products and services. The ease of use may limit the overhead upfront but may prove to be costly in the long-term. Building agile applications and using open formats on top of a variety of infrastructural patterns will help to avoid putting all of your eggs in one basket.
- Leverage open source tools, including MySQL, PostgreSQL and MongoDB; OpenAPI specifications; and DevOps automation with Jenkins.
- Consider infrastructure alternatives such as on-premises, virtual private cloud, multi-cloud and hybrid cloud.
To learn how how to help your organization reduce the risk of vendor lock-in and help with managing APIs in a multi-cloud or hybrid configuration, check out this webinar or eBook.