In economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs.
Source: Vendor Lock-in (Wikipedia)
The Past
Historically, vendor lock-in has been a serious challenge in IT. In general, investments in third-party hardware and software have to be evaluated carefully based on their cost-effectiveness for the project and the resulting long-term commitments.
For example, when it comes to building and running a new application it starts with carefully selecting its dependencies to other services, like databases and application servers. Traditionally, in the enterprise world these software applications must be licensed from vendors and developers might need a special training to use them.
Next, great care must be taken to estimate the resource consumption these applications would need when run in production since the actual infrastructure - servers, load balancers and other network equipment, etc. - have to be bought and managed. Additionally, the investment has to amortize over the course of 3 - 5 years. Again, the staff managing the servers and applications need to be trained as well.
All of this and other factors oftentimes lead to high investments and longterm commitments. Therefore, it comes as no surprise that great care must be taken to evaluate the options and finally come to a well-founded decision.
Naturally, decision-makers with this prior experience and mindset apply the same thinking when it comes to using services offered by cloud providers.
The Present
The lock-in effect is much less important when it comes to using public cloud services because of their very nature. The fear of vendor lock-in is not completely unfounded but its extent is less serious.
When it comes to planning the resource capacity and procuring the cloud infrastructure no longterm commitment is necessary. No matter how you start out - either overestimating or underestimating the resource consumption of your application - you can always adjust it at any time without the fear of breaking contracts or paying hefty fees. Additionally, if more capacity is needed it can be leveraged within minutes instead of days, weeks or months. You actually pay only for what you use.
The same applies to standard software which requires licenses, like operating systems or databases and other middleware components. In this case, nothing special needs to be done since the costs for the licenses are already part of the hourly rate you pay for using the services. Even better, the cloud providers offer lots of fully-managed services based on popular and widely used open source software solutions, like databases (MySQL, PostgreSQL, MariaDB, etc.), caching (memcached, ElastiCache), search engines (Elasticsearch), etc.
Last but not least, modern architecture principles, e.g. microservices, make it easy to reduce the lock-in effect. When it is actually necessary to migrate such an application to another environment - whether it’s another cloud provider or a classic on-premise data center - it tends to be easy to make decisions in the context of single, simple services. For each service it can be decided if it should be migrated, rebuild, retired or replaced, e.g. by a SaaS offering. Therefore, it’s not necessary to do the migration with a more risky big bang approach.
Another argument often is that the cloud providers might suddenly increase the prices for their services. Obviously, this fear is not completely unfounded since nobody knows what the future holds. However, at this point in time we have no evidence for such a move. For example, since its launch back in 2006 AWS has only lowered the prices for their services. Until now, there hasn’t been a single time they increased them. Additionally, the services are offered at the same price but over time the feature set has improved dramatically.
Another fear is that the cloud providers stop offering some services. Actually, the standard contract allows AWS to do so with only a very short grace period. Again, up until now they have not done this a single time. For example, they are still offering SimpleDB which they have introduced in December 2007. Since then it basically has been superseded by DynamoDB. Anyone still using SimpleDB for a business critical application should have migrated to DynamoDB or something else a long time ago. Otherwise, one could ask if this application is really so critical for the business if the necessary investment has not been approved yet.
The Future
Instead of focusing on the potential negative impacts a migration or coupling to a particular cloud provider might have the focus should be shifted to the benefits this decision provides for creating value for the business. We have seen time and time again that using cloud services dramatically increases speed and velocity in IT projects. It does not really depend on the nature of the project, whether it’s hosting a standard application or building a custom application suited for the actual business need. But especially in the latter case it’s apparent that using the cloud helps reaching the business goals.
Almost every single day the existing services are improved by adding new features which had to be build previously. From time to time completely new services are revealed which can be leveraged with very little effort. Using these features can provide an edge over the competition, maybe because a service can be offered at a lower price or with a higher margin, an important feature can be brought to market in a shorter amount of time or the user experience is improved and the services is easier to use.
Therefore, the discussion should really be about how cloud services can be utilized to reach the business goals and create value for the business and the customers.
Exceptions
Of course, there are some non-technical challenges that might speak against using the cloud. One particular example is the topic of data privacy and data security. In some cases these topics might actually block the usage of cloud. However, we’ve seen in many projects that the decision against the cloud is often made because of a gut feeling based an a lack of information. Therefore, the decision-makers do not fully understand the impact and therefore are not comfortable with taking the associated risks.
Oftentimes the wrong questions are discussed before making the decision. It’s not so much the question whether the cloud is safer to use out of the box. Instead the question has to be what concrete actions need to be taken to remove the barriers which stand in the way for actually using it.
Summary
When it comes to migrating applications to the cloud or building new Cloud-native applications the traditional mindset regarding a fear of vendor lock-in must be overcome. Instead, the focus should be shifted to the question how the usage of the services offered by cloud providers can be utilized to create value for the business and therefore helps in getting an edge over the competition.