Vendor lock-in

Vendor lock-in occurs when customers tie themselves to a single service provider so that it becomes virtually impossible to switch. This results in the customer becoming dependent on the provider. Lock-in can be an issue with cloud services. Find out what exactly is behind vendor lock-in and how it can be avoided.

In general, the “lock-in” effect is understood as the dependence of a customer on a product or technology. This dependency happens because switching providers may require significant effort and therefore become an unattractive option or seem impossible. If the technology is controlled by a single vendor, the customer is effectively tied to that provider, resulting in vendor lock-in.

Customers can choose from a wide range of technologies and services, offered at different prices and conditions. Each business relationship between customer and provider has its own advantages and disadvantages. Tension arises when working with several or only a few providers.

From an administrative perspective, it is desirable to work with just a handful of providers. This creates a more homogeneous and less complex working environment. In extreme cases, all products and services are purchased from a single provider. However, this also results in complete dependency on this provider. The customer has less leverage and a poor negotiating position vis-à-vis the provider.

The classic example of vendor lock-in in the software sector is Microsoft. Across many sectors, all core components are provided by the major corporation: operating system (Windows), application software (Office), database (Access), etc. This means that all important software components, from programs to licenses and pricing to support, are controlled by one single vendor and the customer is locked in.

The dependence on a provider results from the inability to switch providers. Even if it is theoretically possible to change providers, this may only be possible at enormous expense. The customer is effectively tied to the provider. Let’s illustrate the principle with a simple example:

Technology components are so-called “complementary goods”. In this case, the individual components are interdependent. For example, if you own an Xbox or a PlayStation and a game collection, you probably won’t change systems, because then you would have to buy all the games again because they don’t run on the other system.

In addition to the incompatibility of competing technologies described above, regulatory, and organizational hurdles can make it difficult to switch providers. On the one hand, licensing conditions and other contractual agreements may tie customers to a single provider. On the other hand, the customer may have invested in employee training. If this is technology-specific and cannot be transferred, the status quo is cemented.

At the core of the considerations lies the realization that the whole is more than the sum of the parts. In fact, the whole comprises:

• The components
• the interactions and other explicit or implicit connections between the parts
• resulting (emergent) properties of the overall system.

The individual parts can often be moved relatively easily during a change. In contrast, the connections may have to be recreated or replaced at great expense. In an organically grown system, the connections between the components are usually implicit. Where it’s unclear how to reconstruct the entire system, a switch becomes difficult or even impossible.

Here’s a concrete example:

Let’s imagine a database system that exists within a provider’s infrastructure. The data stored within can be migrated relatively easily when switching to another provider. But what about the other components and the connections between them? Settings, access rights, distribution of the database across multiple servers (sharding), etc.? Do we know the complexity of the overall system, or can we grasp it? If so, can the overall system be reproduced on the new provider’s infrastructure with reasonable effort? In many cases, the answer to at least one of these questions is probably “no”.

The example of revision security illustrates how emergent system properties make it hard to switch providers. Revision security as a criterion encompasses technical, organizational, and regulatory requirements. Thus, it is a higher-level system property. The auditability of a system is proven by certification. Certification is related to a specific case; when a provider is changed, the system is rebuilt and must be recertified accordingly. The additional effort increases the costs to switch and contributes to the lock-in effect.

Using the cloud has many advantages. However, there is also the threat of vendor lock-in. A typical example is storing important data with a cloud provider. If we want to use another provider to process the data, it must be transferred over the network which incurs transfer costs. In that case, it seems attractive to also transfer the processing task to the initial cloud provider. This results in a creeping lock-in effect.

The more data you store and the longer the business relationship lasts, the stronger the lock-in effect. If your own business logic is based on provider-specific features, APIs, and configurations, it will be difficult to unravel the web. In extreme cases, everything comes from a single Managed Service Provider. Beware of choosing single package solutions from a system house. Here, customization of the package results in strong customer loyalty to the provider.

Let’s first look at what technological capabilities make up the cloud. We identify three basic functionalities:

• Software Defined Networking (SDN): Instead of deploying and configuring physical routers and switches, virtual networks and network devices are used.
• Software Defined Storage (SDS): Instead of physical mass storage, object stores such as “Amazon S3” and block stores such as “Azure Blob Storage” are used in a Software Defined Data Center.
• Computer and serverless solutions: Infrastructure-as-a-Service (IaaS) and Container-as-a-Service (CaaS) virtualize operating systems and applications. With “Function-as-a-Service” (FaaS) such as “AWS Lambda” and “Microsoft Azure Functions”, individual functions are made available for invocation.

A cloud computing environment incorporates the technical aspects of hosting, storage, and applications. Furthermore, the organizational aspects of configuration, support, and regulations are sometimes included. A cloud environment can be made up of different components of these individual aspects. Depending on the number of characteristics making up each of these aspects, you can estimate how complex the migration between a provider would be:

The cloud products mentioned, such as IaaS, PaaS, SaaS and CaaS are all services. These are provided by the provider for a fee, but at no time belong to the customer. It is therefore up to the provider, within the framework of contracts, to decide under what terms their services are offered.

What happens if the parameters of a service change? In the worst case, the quality or scope of the service is reduced, or the provider increases the price or changes the conditions to the customer’s disadvantage. In principle, the provider is in the driver’s seat here since the customer is dependent on the provider.

Reasons for dependency on a vendor also arise on the customer side. For example, the company’s employees are used to working with the technology provided by the vendor. Technical experts are usually specialized in certain technologies. When switching to another provider, staff may need to be retrained; a change may even require the hiring of new personnel.

To break out of vendor lock-in, data and processes must be migrated to a new provider. Such a migration is often a complex process. Since the wellbeing of the organization depends on the success of the migration, it must be planned and tested beforehand. Even if great care is taken, errors can become apparent retrospectively. A complex migration therefore always involves a high level of risk, and the question quickly arises whether the effort required is worthwhile.

The best approach to avoiding vendor lock-in is to counteract it strategically from the outset. Instead of relying on one vendor, focus on several different ones. Internal systems are explicitly built with the goal that sub-components may be replaced later.

In the following, we have summarized specific strategic, organizational, and technical measures that will help you avoid vendor lock-in.

If the risk of vendor lock-in is considered from the outset when selecting partners and technologies, you can make more informed choices. Where comparing technologies from different providers, a slightly higher price shouldn’t deter you if it means that the risk of vendor lock-in is reduced.

It’s worth making a rigorous inventory of your requirements for new technologies and recording existing IT structures. Analyze your company’s IT systems thoroughly. It is also important to take emerging trends into account and to keep an eye on the “end of life” of technologies. If, for example, legacy systems are still in use, it’s recommended to swap.

Where a technology or vendor may seem like a riskier choice in terms of vendor lock-in, you should define an exit strategy. This allows you to react quickly and purposefully to unfavorable changes on the part of the vendor. You know in advance what needs to be done and are aware of the costs and risks involved.

The most obvious approach to avoiding vendor lock-in is to not become dependent on a single provider. Instead of moving all business processes to the cloud, you can choose a hybrid approach. Here, a private cloud is used in addition to the cloud resources of a provider. This means that core processes and data remain under the company’s control to preserve data sovereignty.

Following the same pattern, it can be advantageous to obtain cloud services from several, rather than a single provider. The decisive factor here is that all the services used have adequate interfaces. This is the only way to combine the individual components into a coherent overall system. In addition, services from providers that explicitly support interoperability via open interfaces are preferred.

All measures are only effective if they cover the structures that actually exist within the organization. Processes running under the radar or alongside without the knowledge of the company risk vendor lock-in. “Dark Data” is an example of this because the data here exists outside of the systems in use. It is useful to make dependencies explicit and to standardize processes and systems.

The simplest technical measure to avoid vendor lock-in is to avoid using proprietary systems and formats. If you consistently use open standards and free software, you are by definition not dependent on a single provider. However, that approach is only successful in the cloud so long as you have not relinquished control over the hardware resources.

Fortunately, powerful orchestration tools have been created in recent years that address this issue. These include OpenShift and Terraform. These tools serve as an abstract intermediate layer and decouple your IT infrastructure requirements from the underlying, vendor-specific layer. This makes it possible to build an entire IT infrastructure distributed across multiple clouds.

The keyword here is “Infrastructure-as-Code” (IaC). Mind you: “code”, not “service”. While a service is leased, you control your code. In code, the desired structures are defined. These contain individual components, as well as the connections between them. In addition to the explicit documentation of the systems in the code that this entails, there are other decisive advantages.

The code then defines which corresponding IT systems are needed. It is possible to distribute the individual components across multiple clouds. This works for cloud infrastructures of different providers, and private clouds. Because the costs to switch are significantly reduced, your company is better protected from vendor lock-in.