What you need to know about vendor lock-in

Lock-in is defined as a close coupling to a supplier that leads to excessive dependency. The interdependence can be based on products and services. If the interdependence is too strong, switching to another provider becomes uneconomical due to excessively high transaction costs. In this case, we speak about the lock-in effect.

Vendor lock-in: Old news for IT systems

In IT, we are already so familiar with vendor lock-in that we are often no longer even aware of it. Every company makes a choice: operating systems such as Windows, OS X or Linux are needed just as much as development platforms such as .Net, Java or Rails or database systems such as Oracle, SQL Server or MySQL. In each of these cases, there is a lock-in effect, since changes to the systems or switching to comparable solutions from other providers are very difficult or even impossible.

Vendor lock-in for the public cloud

Even if the shift of workloads to the cloud naturally leads to more flexible work processes on the one hand, vendor lock-in is definitely a challenge to be taken seriously. This is because the offerings of public cloud providers currently still lack standard interfaces and open APIs. Different data formats, containers and virtual machines make migration difficult. Setting up and managing cloud resources can only be done efficiently by trained experts, as the public cloud providers each work with their own complex structures and interfaces. As a rule, it is also easier to transfer data to the cloud than vice versa: The export of data stored in a public cloud is supported by the providers - but is often more complex and cost-intensive than the upload. In addition, the customer usually has no influence on the product policy of a cloud provider: If the costs and risks of a change are high, changes in the offer and higher prices must be accepted.

Advantages of the public cloud

The use of cloud services and cloud-native software development inevitably result in a lock-in effect. But instead of brooding over this, one should weigh up whether the advantages of the public cloud simply outweigh the disadvantages for one's own purposes. Cloud services enable innovations to be implemented in a short time. Development times for new applications or the automation of existing processes can often be reduced from months to just a few days. If the cloud provider is changed, this development process must - in the worst case - be repeated. However, the short time means that the costs for this are limited. The lack of long-term contracts also speaks in favor of the public cloud: You pay for the service that is actually used. If the decision is made in favor of another provider, there are no follow-up costs due to a contract commitment.

Mitigate lock-in effect

In order to keep the risk of the lock-in effect small, portability should already play the main role when choosing a provider, a cloud application or when designing cloud applications. The fewer native functions of a platform are used, the easier it is to migrate - this must be especially true for the core applications of companies. In the best case, a provider comes into play that offers its services independently of technology. In fact, the situation is changing steadily in a positive direction: open and de facto standards are gradually replacing old protocols. For example, thanks to hybrid cloud approaches, it is now possible to perform user authentication across system and application boundaries. Platform-independent applications and services, so-called open source software, are also a means of reducing vendor lock-in - and every successful cloud platform now has open source applications integrated to a large extent. Standardized data formats and interfaces required for migration should be considered from the outset. It is also advisable to test several public cloud platforms first in order to be able to estimate the effort required for operation and migration of data and workloads more realistically.

This is how the lock-in effect loses its scare

All in all, there will always be a certain degree of vendor lock-in. Anyone who wants to exploit the potential of the public cloud will accept the risk. And - the better informed you are about the effect, the more likely you are to foresee undesirable consequences. Excessive dependencies should already be ruled out in the architecture of the IT systems: Keywords here are the encapsulation of the integration of third-party services, e.g., a database, the use of microservices, the use of continuous integration including an extensive collection of automatic test cases. Nowadays, however, these are no longer exotic principles, but should rather be part of the standard.