How to Avoid Vendor Lock In

What is vendor lock-in?

‍
Think of a situation where you're asked to build a service in AWS that distributes static content to your users. Your first option is to use its native CDN - Amazon CloudFront, as it seamlessly integrates with all of your other AWS Services that you're using to build your service.

‍

For example, consider the following scenario :

‍

‍

You've used Amazon S3 to host your static site and content and Amazon API Gateway to host your APIs that clients will use to decide on the static content to fetch. CloudFront makes a simple choice here as it offers direct integration with all these services to let you cache responses across its global edge locations. Later on, your service might require security, and you might use AWS Web Application Firewall, which directly integrates with Amazon CloudFront to help secure your service. 

‍

You might keep introducing CDN-level features specific to CloudFront that significantly improve your application's performance. And one day, your team lead decides that CloudFront is more costly and to change your CDN provider.

‍

However, by this time, you've done so many native integrations with CloudFront that the cost of switching to a different CDN provider is so high that you're forced to use CloudFront as your only CDN. Not only that, but it's essential to understand that each CDN uses its proprietary native runtimes and components to function. And different CDNs have different engines, which makes the transition much more complex. This is known as "Vendor Lock-in."

‍

Vendor lock-in is when your organization becomes heavily dependent on a particular vendor's products to the extent that switching to an alternative vendor becomes challenging, costly, or impossible. So, the more you get locked-in, the harder it is to migrate.

‍

In our case, using all or even some of its the native integrations and features that Amazon CloudFront supported meant that our application has now become tightly coupled with Amazon CloudFront such that switching to a different CDN provider would:

‍

1. Require a massive effort: Using many vendor-specific features on your application adds a lot of overhead when you're asked to switch to a different vendor. Your new CDN provider might still support the current integrations that you've made, but you'd need to build it from scratch, which would be extremely challenging and time-consuming.
2. Require a lot of resources: Companies that often switch to different CDN providers often need a lot of time to understand how the new CDN works, and would often spend a lot of time browsing its documentation, which creates a huge learning curve. Not only that, but you'll need to employ new people to aid in migration or acquired an integrator service to built it for you.
3. Impact business operations during the transition: The tighter the integration, the longer it takes to switch your CDN Provider. Therefore, there might be cases where your system could experience a downtime during the migration process. Not only that, but there can be cases where a piece of your application could break during the migration process that could take a long time to get back running.

‍

{{promo}}

‍

How does vendor lock-in occur?

It's essential to understand that vendor lock-in cannot happen overnight. You must understand if you're heading towards vendor lock-in and adopt the proper measures to avoid it.

‍

Sign 01 - Use of proprietary technologies

One of the primary signs of becoming a victim of vendor lock-in is when you're using proprietary technologies by vendors. These services are unique to a specific vendor and are not standardized or interoperable with other vendors' offerings.

‍

For example, suppose you're heavily relying on Amazon CloudFront to enhance your content delivery. In that case, you might become a victim of vendor lock-in without knowing it, as when businesses build their applications around such services, they start to rely on the vendor's ecosystem, thus making it difficult to transition to other providers without significant modifications.

‍

If you're looking to migrate the service shown above out of AWS, you'll have to make significant changes to how your content is coupled to the CDN. For example, AWS WAF and CloudFront have simple point-to-point integrations so if you wish to move out of CloudFront, you’ll need to find a suitable WAF that supports the same level of integration and functionality that you’ve already adopted into your CDN.

‍

Sign 02 - Use of vendor-specific APIs & standards

Sometimes, vendor lock-in can also occur when you're using an API that’s offered by a CDN provider that has little to none standardized forms of communication. This means that if you wish to switch CDN, you’d have to rewrite a vast amount of code to support a new API.

‍

‍

Sign 03 - Over-relying on vendor-specific functionality

Some CDN providers offer unique and specialized features that are unavailable to their competitors. So, when businesses integrate these exclusive features into their applications, they become tied to the vendor, as replicating these features in another CDN is impossible.

‍

For example, Akamai introduced ASI in 2005, which became the standard for building new websites. Akamai tried to convince many users to use this new framework. Therefore, some of Akamai clients decided to use it to build their own website, and they did. But, it’s important to understand that ASI was proprietary to Akamai and doesn’t exist on other platforms. Therefore, it was only developed and maintained by Akamai. So, when it was abandoned by Akamai, many of the Akamai clients couldn’t migrate as there was no parallel service similar to ASI on other vendors. because their website can never be supported by any other CDN.

‍

Sign 04 - Use of Free Tier Credits

Many CDN vendors provide customers with a high amount of free-tier credits (6 digits and above) to build their solution on. Therefore, the customer will eagerly build their solution on top of these free credits, but at some point, the free tier credits will get exhausted and the customer would be locked-in a costly application where they have to pay a huge bill to get access to their services and remain operational.

‍

{{promo}}

‍

Vendor lock-in is not just the customer's fault; it's the CDN provider too...

However, it's essential to understand that vendor lock-in is not just something from your end. CDN providers deploy their services to ensure that you lock into it. For example, consider an Apple Lightning Cable and an Android Cable. If you're an iPhone user, you can't plug an Android cable for data transfer. Likewise, CDN providers do this through the following techniques:

‍

APIs and protocols

CDN providers offer APIs and protocols that are not standardized. This makes it difficult for customers to integrate their applications with other CDN services as these unstandardized APIs limit interoperability and make it difficult to adapt the application to a different CDN's interface.

‍

Another fact is that most companies rely on IaC tools like Terraform, Pulumi to manage their CDN infrastructure. However, the IaC code significantly changes across each CDN provider.For example, the IaC code to provision a CloudFlare CDN and a CloudFront CDN is different in any IaC provider. Therefore, if you wish to migrate across different CDNs, you’ll have to rewrite the IaC code almost entirely. 

‍

Edge computing increases vendor lock-in

It's a common fact that when you rely on edge computing, the chances of falling under vendor lock-in increase significantly. For example, think about building an application solely relying on Amazon CloudFront as its CDN.

‍

And on top of that, you're doing computation at the edge using Lambda@Edge, where you've deployed thousands of lines of JavaScript code at the edge. Your application will function without any problem at the edge, but your real trouble starts when you're asked to change your CDN vendor. It's important to understand that each CDN uses a different compute environment.

‍

For example, Amazon CloudFront uses a compute environment that supports only JavaScript, C#, and Python. At the same time, other CDNs have various compute engines that support other languages, which can often cause these CDNs to behave differently. So if you're asked to switch vendors to CloudFlare, a CDN whose engine doesn't support languages like Python, your task will be near impossible as you're forced to migrate thousands of Python code running on Lambda@Edge to a language supported by CloudFlare. These situations are prevalent when you start edge computing and significantly increase vendor lock-in.

‍

‍

How to avoid/minimize vendor lock-in

Now that you've understood vendor lock-in along with its causes and impacts, it's essential to understand how to avoid it.

Use Multi-CDN Strategies

Consider using multiple CDNs simultaneously. Instead of relying solely on a single CDN provider, you could implement multiple CDNs responsible for delivering your content. This lets you utilize each provider's strengths and optimize performance while mitigating the risks of complete dependency on a single vendor.

Leverage API abstraction layers

You could consider implementing an API abstraction layer in your application architecture as an intermediary between your application and CDN Provider's APIs. This makes it easier to switch to a different CDN in the future, as you only need to change the codebase in your abstraction layer and not your entire application.

‍

‍

‍

Is Vendor Lock-in a Bad Thing?

Yes, But, sometimes it isn't. Sometimes, it is a good idea to embrace vendor lock-in. So, how do you determine if vendor lock-in is bad for you?

Seamless integrations

Vendor lock-in can lead to seamless integration between different services and components offered by a single provider.

‍

For example, consider the scenario we looked at toward the start of the article. Amazon CloudFront integrates with Amazon S3, AWS WAF, and Amazon API Gateway. It lets you improve development efficiency and build more complex workflows with minimum operational effort, thus allowing your business to focus on its core objectives faster rather than dealing with complex integration challenges.

‍

If you're looking for a situation like this, vendor lock-in is good for you!

Dependency on a single vendor

Vendor lock-in causes you to depend solely on a single vendor. As a business, you're starting to rely heavily on a particular vendor to provide its CDN services. So if this vendor decides to change their data policy or increase their prices, you have no choice but to comply with these regulations as you have no other option.

‍

If this is not what you're looking for, then vendor lock-in is bad for you.

Risk of service disruptions

Heavily relying on one vendor means you must be prepared to face service disruptions. As you don't have a multi-CDN strategy, your CDN becomes a single point of failure. If the CDN fails, your application fails.

‍

If service disruptions are something that you don't want, vendor lock-in is a bad thing for you.

‍

Specialized features

Some vendors offer specialized features that are not available in competing CDNs. For example, not all CDN provide Edge compute capabilities.
If your tools heavily rely on these specialized features to deliver a specific functionality in your app, then vendor lock-in is the right fit for you.

‍

{{promo}}
‍

What Industries or Companies Are at Higher Risk of Vendor Lock-in?

Vendor lock-in is not something that all organizations that use CDNs will run into. However, it's essential to understand that if your service falls into one of the categories discussed below, you might have a higher risk of losing to vendor lock-in.

‍

Software-as-a-Service (SaaS) Providers

SaaS tools rely on chunks of dynamic content that serve from the origin. Therefore, they heavily rely on services such as a WAF and Rate Limiting to help with securing the origin, load balancing and edge computing that ultimately helps bring dynamic content close to the user at the edge.

‍

They generally do this by integrating their app to a specific CDN. However, this leads to vendor lock-in and could make switching to alternative CDN providers challenging without impacting the application performance.

‍

E-commerce

E-commerce requires global content delivery to reach their audiences effectively.

‍

These companies often utilize CDNs optimized for low-latency content delivery of the products that they offer. But since they don't rely much on dynamic content, but rely more upon static content that can be cached at the edge. Additionally, these services are more prone to attacks and would require additional services like WAF, Bot Detection, and Rate Limiting.

‍

So they can adopt a deep integration with a single CDN that supports these features, but could lead to vendor lock-in challenges if these companies wish to explore alternative CDN solutions as there might not be the same type of support for these services.

‍

‍

‍

‍

‍