Avoiding cloud vendor lock-in

These days when there is a wide variety of cloud providers to choose from, it is natural to wonder if the so called cloud vendor lock-in is really an issue. For the uninitiated, cloud vendor/provider lock-in refers to the phenomenon where once an organization has picked a particular cloud vendor, it is difficult for the organization to go to another vendor.

Logically speaking, having variety and being locked-in seem contradictory. If there is variety then shouldn’t it be possible to easily pick and choose between different options, thereby not causing lock-in? Cloud is not the first consumer area in which variety of options are available for consumers. When we are planning air travel, there are many air-lines to choose from. When planning to rent a car for our holiday travel, we have several rental car companies to pick from. But we don’t ever worry about getting locked-in to one particular airline or one particular car rental company. The option of choosing the best travel company always remains open for us. But with going to cloud, that does not seem to be the case. The skepticism and wariness of cloud provider lock-in remains front and center in the minds of IT decision makers who are planning cloud strategy for their organizations. What can be done to alleviate this fear? Read on to find the answer.

An organization’s cloud strategy needs to be optimized for the overall needs of the organization. This includes considering aspects such as, capabilities offered by the cloud, available support and SLAs guaranteed by the cloud provider, cost of using the cloud, so on. Note that even though cloud spending will typical fall under operational expense (OpEx) and not capital expense (CAPEX), it still matters when there are multiple competing platforms to choose from. Given these different constraints, it is very likely that different clouds will come up as winners on different aspects for different projects.

It is possible that organizations have different reasons to choose a particular cloud. May be the organization has prior licensing agreements and arrangements with enterprise software companies and that drives their choice of the cloud provider. Perhaps, the organization’s products require strict compliance, such as PCI or HIPAA, and they need to choose a cloud provider that satisfies such compliance needs. Or certain applications need to use certain services that are available through only a particular cloud platform. Or may be the organization has few projects already on a particular cloud and choosing a different cloud for new projects is not going to be cost effective.

So the question then becomes, how can IT decision makers balance these aspects with the need to not get locked into any particular cloud provider? Specially, if the primary reason to go with a particular vendor is the inertia created due to existing projects and the cost associated with evaluating other clouds and not any licensing or compliance needs, then is it possible to avoid vendor lock-in?

The solution, according to me, comes from three complementary avenues –

1.) Building applications in cloud agnostic manner,

2.) Using containers to package applications, and

3.) Using a standard IaaS layer such as OpenStack to deploy the containerized applications.

Building applications in cloud agnostic manner means that the application code should not contain anything that is cloud-specific. Consider a web application (written in any language) that uses a MySQL database to store its data. When deploying such an application to a cloud platform one of the key issues is how to provision a MySQL database on the cloud and access it from within the application? The standard solution that most of the cloud providers suggest is to include some cloud specific code as part of your application code. For instance, one of the cloud provider requires that the application code be written such that it uses only specific environment variables that are defined by that provider. Such environment variables would then be set by the cloud platform. For example, cloud provider would define the environment variables for database credentials and set them appropriately when the platform provisions a database instance for the application. However, the fact that application code now depends on these specific environment variables makes it tied to that cloud. So even though using environment variables is the right thing to do [1], getting locked-in to a particular cloud provider by using that cloud-specific environment variables in the code, is not. Another example is where cloud provider requires modifying application code to use a particular form of connection string in the application to connect to database on their cloud. Again, this makes the application locked into that cloud. So then how to really write cloud agnostic code? It comes down to not including any cloud vendor code directly in your application. No direct dependencies on any cloud-specific environment variables, nor using connection strings that are cloud-specific.

Using containers to package applications has several benefits. Containers provide all the tools and libraries that are essential for building and deploying an application. Container technologies such as lxc and Docker make it straightforward to define application dependencies and building applications in a consistent manner. Most of the cloud providers have added container services to their cloud offerings. So packaging applications as containers and deploying them on different clouds should be possible.

Finally, depending upon OpenStack for the infrastructure layer is the third strategy in becoming truly cloud neutral. OpenStack is now in its seventh year of existence and has matured to the level where several cloud vendors have public and private cloud offerings based on OpenStack [2, 3]. OpenStack consists of family of projects that are developed following open standards and by contributors from all over the world. Any OpenStack-based cloud works exactly the same down to the API-level.

So there you have it. Avoid cloud vendor lock-in by, (1) writing applications that don’t use any cloud-specific contructs, (2) using containers to package your applications, and (3) choosing a cloud provider that uses open standard (OpenStack) in building its cloud.

Comments are closed.