Vendor lock-in

Vendor lock-in occurs when customers tie them­selves to a single service provider so that it becomes virtually im­possible 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 un­der­stood as the de­pend­ence of a customer on a product or tech­no­logy. This de­pend­ency happens because switching providers may require sig­ni­fic­ant effort and therefore become an un­at­tract­ive option or seem im­possible. If the tech­no­logy is con­trolled by a single vendor, the customer is ef­fect­ively tied to that provider, resulting in vendor lock-in.

Customers can choose from a wide range of tech­no­lo­gies and services, offered at different prices and con­di­tions. Each business re­la­tion­ship between customer and provider has its own ad­vant­ages and dis­ad­vant­ages. Tension arises when working with several or only a few providers.

From an ad­min­is­trat­ive per­spect­ive, it is desirable to work with just a handful of providers. This creates a more ho­mo­gen­eous and less complex working en­vir­on­ment. In extreme cases, all products and services are purchased from a single provider. However, this also results in complete de­pend­ency on this provider. The customer has less leverage and a poor ne­go­ti­at­ing position vis-à-vis the provider.

The classic example of vendor lock-in in the software sector is Microsoft. Across many sectors, all core com­pon­ents are provided by the major cor­por­a­tion: operating system (Windows), ap­plic­a­tion software (Office), database (Access), etc. This means that all important software com­pon­ents, from programs to licenses and pricing to support, are con­trolled by one single vendor and the customer is locked in.

The de­pend­ence on a provider results from the inability to switch providers. Even if it is the­or­et­ic­ally possible to change providers, this may only be possible at enormous expense. The customer is ef­fect­ively tied to the provider. Let’s il­lus­trate the principle with a simple example:

Tech­no­logy com­pon­ents are so-called ‘com­ple­ment­ary goods’. In this case, the in­di­vidu­al com­pon­ents are in­ter­de­pend­ent. For example, if you own an Xbox or a Play­Sta­tion and a game col­lec­tion, 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 in­com­pat­ib­il­ity of competing tech­no­lo­gies described above, reg­u­lat­ory, and or­gan­isa­tion­al hurdles can make it difficult to switch providers. On the one hand, licensing con­di­tions and other con­trac­tu­al agree­ments may tie customers to a single provider. On the other hand, the customer may have invested in employee training. If this is tech­no­logy-specific and cannot be trans­ferred, the status quo is cemented.

At the core of the con­sid­er­a­tions lies the real­isa­tion that the whole is more than the sum of the parts. In fact, the whole comprises:

• The com­pon­ents
• the in­ter­ac­tions and other explicit or implicit con­nec­tions between the parts
• resulting (emergent) prop­er­ties of the overall system.

The in­di­vidu­al parts can often be moved re­l­at­ively easily during a change. In contrast, the con­nec­tions may have to be recreated or replaced at great expense. In an or­gan­ic­ally grown system, the con­nec­tions between the com­pon­ents are usually implicit. Where it’s unclear how to re­con­struct the entire system, a switch becomes difficult or even im­possible.

Here’s a concrete example:

Let’s imagine a database system that exists within a provider’s in­fra­struc­ture. The data stored within can be migrated re­l­at­ively easily when switching to another provider. But what about the other com­pon­ents and the con­nec­tions between them? Settings, access rights, dis­tri­bu­tion of the database across multiple servers (sharding), etc.? Do we know the com­plex­ity of the overall system, or can we grasp it? If so, can the overall system be re­pro­duced on the new provider’s in­fra­struc­ture with reas­on­able effort? In many cases, the answer to at least one of these questions is probably ‘no’.

The example of revision security il­lus­trates how emergent system prop­er­ties make it hard to switch providers. Revision security as a criterion en­com­passes technical, or­gan­isa­tion­al, and reg­u­lat­ory re­quire­ments. Thus, it is a higher-level system property. The audit­ab­il­ity of a system is proven by cer­ti­fic­a­tion. Cer­ti­fic­a­tion is related to a specific case; when a provider is changed, the system is rebuilt and must be re­cer­ti­fied ac­cord­ingly. The ad­di­tion­al effort increases the costs to switch and con­trib­utes to the lock-in effect.

Using the cloud has many ad­vant­ages. 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 trans­ferred over the network which incurs transfer costs. In that case, it seems at­tract­ive to also transfer the pro­cessing task to the initial cloud provider. This results in a creeping lock-in effect.

The more data you store and the longer the business re­la­tion­ship lasts, the stronger the lock-in effect. If your own business logic is based on provider-specific features, APIs, and con­fig­ur­a­tions, 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, cus­tom­isa­tion of the package results in strong customer loyalty to the provider.

Let’s first look at what tech­no­lo­gic­al cap­ab­il­it­ies make up the cloud. We identify three basic func­tion­al­it­ies:

• Software Defined Net­work­ing (SDN): Instead of deploying and con­fig­ur­ing 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 server­less solutions: In­fra­struc­ture-as-a-Service (IaaS) and Container-as-a-Service (CaaS) vir­tu­al­ise operating systems and ap­plic­a­tions. With ‘Function-as-a-Service’ (FaaS) such as ‘AWS Lambda’ and ‘Microsoft Azure Functions’, in­di­vidu­al functions are made available for in­voc­a­tion.

A cloud computing en­vir­on­ment in­cor­por­ates the technical aspects of hosting, storage, and ap­plic­a­tions. Fur­ther­more, the or­gan­isa­tion­al aspects of con­fig­ur­a­tion, support, and reg­u­la­tions are sometimes included. A cloud en­vir­on­ment can be made up of different com­pon­ents of these in­di­vidu­al aspects. Depending on the number of char­ac­ter­ist­ics 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 para­met­ers 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 con­di­tions to the customer’s dis­ad­vant­age. In principle, the provider is in the driver’s seat here since the customer is dependent on the provider.

Reasons for de­pend­ency on a vendor also arise on the customer side. For example, the company’s employees are used to working with the tech­no­logy provided by the vendor. Technical experts are usually spe­cial­ised in certain tech­no­lo­gies. 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 or­gan­iz­a­tionor­gan­isa­tion depends on the success of the migration, it must be planned and tested be­fore­hand. Even if great care is taken, errors can become apparent ret­ro­spect­ively. A complex migration therefore always involves a high level of risk, and the question quickly arises whether the effort required is worth­while.

The best approach to avoiding vendor lock-in is to coun­ter­act it stra­tegic­ally from the outset. Instead of relying on one vendor, focus on several different ones. Internal systems are ex­pli­citly built with the goal that sub-com­pon­ents may be replaced later.

In the following, we have sum­mar­ised specific strategic, or­gan­isa­tion­al, and technical measures that will help you avoid vendor lock-in.

If the risk of vendor lock-in is con­sidered from the outset when selecting partners and tech­no­lo­gies, you can make more informed choices. Where comparing tech­no­lo­gies 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 re­quire­ments for new tech­no­lo­gies and recording existing IT struc­tures. Analyse your company’s IT systems thor­oughly. It is also important to take emerging trends into account and to keep an eye on the ‘end of life’ of tech­no­lo­gies. If, for example, legacy systems are still in use, it’s re­com­men­ded to swap.

Where a tech­no­logy 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 pur­pose­fully to un­fa­vour­able 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 sov­er­eignty.

Following the same pattern, it can be ad­vant­age­ous to obtain cloud services from several, rather than a single provider. The decisive factor here is that all the services used have adequate in­ter­faces. This is the only way to combine the in­di­vidu­al com­pon­ents into a coherent overall system. In addition, services from providers that ex­pli­citly support in­ter­op­er­ab­il­ity via open in­ter­faces are preferred.

All measures are only effective if they cover the struc­tures that actually exist within the or­gan­iz­a­tionor­gan­isa­tion. 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 de­pend­en­cies explicit and to stand­ard­izest­and­ard­ise processes and systems.

The simplest technical measure to avoid vendor lock-in is to avoid using pro­pri­et­ary systems and formats. If you con­sist­ently use open standards and free software, you are by defin­i­tion not dependent on a single provider. However, that approach is only suc­cess­ful in the cloud so long as you have not re­lin­quished control over the hardware resources.

For­tu­nately, powerful or­ches­tra­tion tools have been created in recent years that address this issue. These include OpenShift and Terraform. These tools serve as an abstract in­ter­me­di­ate layer and decouple your IT in­fra­struc­ture re­quire­ments from the un­der­ly­ing, vendor-specific layer. This makes it possible to build an entire IT in­fra­struc­ture dis­trib­uted across multiple clouds.

The keyword here is ‘In­fra­struc­ture-as-Code’ (IaC). Mind you: ‘code’, not ‘service’. While a service is leased, you control your code. In code, the desired struc­tures are defined. These contain in­di­vidu­al com­pon­ents, as well as the con­nec­tions between them. In addition to the explicit doc­u­ment­a­tion of the systems in the code that this entails, there are other decisive ad­vant­ages.

The code then defines which cor­res­pond­ing IT systems are needed. It is possible to dis­trib­ute the in­di­vidu­al com­pon­ents across multiple clouds. This works for cloud in­fra­struc­tures of different providers, and private clouds. Because the costs to switch are sig­ni­fic­antly reduced, your company is better protected from vendor lock-in.