Vendor lock-in is a concept overly often associated with the IT industry, and in recent years, especially with cloud computing, although it is not inextricably linked with them. Economists considered it in a broader context long before the world first heard of AWS or Azure. From a customer and user perspective, it has tended to be viewed negatively, often creating reluctance and fear of using a particular service or product.
At first glance, the problem is not trivial in the public cloud area. Even the main beneficiaries of the phenomenon, i.e. the largest cloud providers, have decided to raise the issue on their official websites, so clearly something must be…
And whether it actually is, we will check in this article. We’ll look at the risks of vendor lock-in for organizations planning cloud adoption. We’ll also consider whether using multiple vendors (multi-cloud ) simultaneously can be a good recipe for improvement. In addition, we will take a look at the hybrid cloud.
Migrating to the cloud and choosing the cloud vendor
Let’s briefly consider an example scenario of migrating the local IT infrastructure of a certain enterprise to the cloud. The first stage of work includes various types of analysis and planning. Business and technological requirements are established, as well as the expected results of the entire project (KPIs). All IT systems used in the organization and related hardware resources are reviewed, and then the optimal strategy for moving them to a new location is gradually built.
The team considers the offerings of various cloud service providers, taking into account factors such as:
- estimated costs,
- operational reliability,
- security level,
- quality of technical support.
Also taken into account is the availability on the market of specialists with the right skills and experience in working with a particular cloud platform, without whom the success of the entire migration would be seriously compromised, if not impossible.
Once the final decision on the cloud vendor is made, the strictly technical part of the process begins. A detailed architecture design is created. Programmers and administrators get to work, and later also testers. Finally, after many weeks or months of work (depending on the scale of the project), all the applications and data to be moved are in the new location, in the cloud. Predefined goals are achieved and the company begins to reap the benefits of migrating to the cloud.
Several years pass. As the company grows, management decides to expand its offerings and enter new markets. This entails adding new components to existing IT systems. It becomes necessary to expand the previously created infrastructure in the cloud too.
Again, analyzing the current situation in the cloud computing market begins. In the course of it, the offer of a competing cloud service provider is better suited to the company’s needs than that of the current provider. A more favorable pricing model distinguishes it and is also more technologically innovative, allowing it to achieve its goal with less effort. Migration to another cloud is therefore considered. However, it soon becomes clear that the estimated costs of such an operation quite significantly exceed the potential gains…
Causes and symptoms of vendor lock-in
And here comes the collision with vendor lock-in in its full glory. As the textbook definition of this phenomenon explains, the customer then becomes dependent on a particular product, service or technology to the point where taking advantage of available alternatives is hampered. In the situation described, the company is dependent on the cloud platform of choice because, without it, the IT systems necessary for the proper functioning of the entire enterprise could not function.
But why would moving systems, infrastructure and data to a competitive cloud be so challenging?
The crux of the problem is at the technical level. It may seem that applications written in Java or Python can be run in many different environments without major code changes. Such an assumption is often true, but difficulties arise when these applications use native components of the chosen cloud platform, not available anywhere else.
As an example of such a component, one can cite Amazon EventBridge, a service available exclusively within the Amazon Web Services, often forming the core of applications in an event-driven architecture. While alternative clouds also offer services with a similar purpose, the differences between their interfaces are significant and prevent EventBridge from being easily replaced by another competing service. In other words, the pieces of application code responsible for communicating with Amazon EventBridge will not work with Azure Event Grid or Google Cloud Eventarc, and vice versa.
What if a company has a cloud-based IT system that does not use native cloud components?
For example, it can consist of several subnets, a dozen virtual machines running the Linux operating system, a PostgreSQL database cluster, a load balancer and a few more minor components. The whole thing is based on standard technologies and communication protocols known in the industry long before the advent of the cloud era. Can the migration of such a structured infrastructure be an equally problematic undertaking?
Unfortunately, this will often be the case, even though the types of resources mentioned above are available in all popular clouds. Again, important differences between the interfaces of the various providers are revealed here. Although a regular virtual machine is a resource with an identical purpose in both AWS and Azure, the way it is created and configured (at the infrastructure level, not the operating system level) will be different.
Differences and incompatibilities between platforms can involve many technical nuances, and even the two cited above imply significant difficulties in migrating to another cloud. Such an operation is, of course, possible, but its complexity and time consumption are often high and generate not inconsiderable costs.
On top of that, there is the human resources aspect, as the current team may need more experience with the new cloud. From the perspective of decision-makers in the company, one can point to many reasons to abandon plans for such a migration. Expanding the existing IT system within the current cloud may ultimately prove to be a more favorable solution. However, are there indeed no other options?
Multi-cloud. A single cloud does not make a storm
So far, we have assumed that there are only two possibilities in the situation described:
- Continuing to work with your current cloud provider,
- Complete migration of the entire system, including infrastructure and data, to another provider.
Meanwhile, on reflection, a legitimate question may arise about combining the two options, so as to make the most of the advantages of another cloud, but at the same time avoid parting with the one currently in use. Now, wouldn’t it be possible to select certain elements from different clouds and combine them into one coherent, well-functioning system? It turns out that in many cases this is achievable.
Such an approach is called multi-cloud.
Some sources, including Oracle, report that in selected regions of the world, more than 90% of large enterprises are using or planning to use the offerings of more than one cloud provider simultaneously. One can easily find companies that use three, four or even more clouds. The upper limit actually does not exist in this case.
Thus, the multi-cloud strategy is no eccentric, uncertain experiment but a proven solution with numerous benefits for organizations. It allows to achieve diversification and independence from a single provider. A certain analogy can be drawn to a well-diversified investment portfolio, which reduces the risk associated with a decline in the value of one or more component assets.
Similarly, thoughtfully distributing system components among different cloud platforms minimizes the risk associated with one of these platforms’ temporary or permanent unavailability. It should not be forgotten that failures and various technical problems are unfortunately inevitable in the cloud world as well, and it is the role of the user and good practice to design the infrastructure to be as resilient as possible to such events.
Let’s return to the example considered earlier. It seems that in the scenario presented, using a multi-cloud approach would be the optimal solution. It would allow an existing IT system to expand without the need for a complete migration to another cloud. New components that need to be added would benefit from the more technologically advanced yet more cost-effective services available from the existing technology stack of the new provider.
The company would therefore gain:
- more significant opportunities for cost optimization;
- higher reliability of system operation;
- Technology tailored to the implemented project and requirements;
- Independence from a single supplier (avoiding the vendor lock-in phenomenon).
Is a multi-cloud strategy the magic remedy for cloud adoption problems?
Unfortunately, not always. While it has a number of advantages, it also comes with certain challenges that should be kept in mind. First of all, in a multi-cloud environment, the complexity of deployments is more significant than in a single cloud. Services available within a specific platform can usually be easily integrated because the provider has handled that. You could say that they fit together like blocks in a puzzle, together forming a cohesive whole. Data is usually transmitted over the provider’s internal network, which translates into:
- high level of security,
- high speed
- And low transfer costs.
However, combining services from several different clouds is definitely more difficult, as they are like building blocks from completely different puzzles. It then takes more effort to ensure the right level of security, and the cost of data transfer increases. Therefore, designing an extensible architecture and using appropriate integration patterns is extremely important. This approach will make it relatively simple to add new components to the system running in almost any cloud, which will work together securely and efficiently. Ideally, this should be possible without disturbing already existing areas of infrastructure and applications.
How about a hybrid cloud, not just a public cloud?
Touching on multi-cloud environments, it is also worth mentioning hybrid cloud. The term hybrid is found in many areas of life and usually means a combination of different, mismatched elements. In biology, it means an individual resulting from crossing two other species. In automotive, it usually refers to a combination of internal combustion and electric propulsion. And in the world of cloud computing, hybrid is understood as combining two types of clouds – public and private.
As the name suggests, the public cloud is available to all interested customers via the Internet. In this case, users use computing resources located in a server room owned by the service provider and can be partially shared by different customers. This type of cloud has been considered so far in this article. Examples of the most significant public clouds on the market are Amazon Web Services, Microsoft Azure and Google Cloud.
However, for various reasons, some organizations cannot or do not want to use shared resources in the public cloud. In response to this problem, the concept of a private cloud was created, which is implemented for the needs of a single customer (and sometimes a small group of customers) in each case, and available exclusively to him. The customer uses the computing infrastructure located in his server room or a third-party provider’s data center, which, however, does not share these specific resources with any other entities.
By placing some system components in a private cloud and others in one or more public clouds, the result is a hybrid system. Similar challenges and benefits are associated with such a solution as in the case of the previously described multi-cloud strategy, of which the hybrid cloud is a part.
However, unlike deployments using public clouds alone, hybrid solutions bring organizations the additional benefits of a private cloud. Among the most important, one can point to full control over the location and security of data, which is particularly important in some industries where it is necessary to meet strict regulations in this regard. Another advantage is the extensive customizability of the private infrastructure, making achieving optimal performance while minimizing costs possible.
Summary: Which cloud to choose?
The decision on the type of cloud (public, private or hybrid) should be made following a detailed analysis of an organization’s needs and requirements. If the prospect of dependence on the chosen cloud vendor seems worrisome, it is worth considering a multi-cloud option. Scattering system components among different platforms and – optionally – its local server room will reduce the risk of vendor lock-in to some extent, as the organization will not rely on the services of only one external entity. It is worthwhile to consult the planned cloud adoption strategy with experienced specialists, who will help prepare for the possible consequences of certain choices.
On the other hand, one should be aware that dependence on a single provider (cloud vendor lock-in) does not necessarily bring negative consequences in every case. Especially small and medium-sized companies, which do not need extensive IT infrastructure, can use only one public cloud for many years without experiencing any major problems.
Amazon, Microsoft, Google and other cloud players are aware of their customers’ concerns and are clearly moving away from practices designed to make it difficult for them to migrate to other clouds, and are even trying to make such a process easier if necessary. And here’s at least one example of how Amazon is doing it: How the AWS Cloud helps to eliminate lock-in.
