[Cloud lock-in] Lock-in cost

Cloud lock-in is one of the most common topics related to cloud adoption. Surveys like the one done by IDG show that cloud lock-in is the biggest challenge for around 48% of large organizations. Finding the right balance between SaaS and IaaS and the level of cloud lock-in that you want for your IT systems is challenging.

This is why in today's article, we talk about figures and numbers. The primary purpose is to see how we can calculate the cost of a cloud lock-in strategy vs. a multi-cloud approach from the cost point of view. 

Lock-in cost

To be able to assess the cost of lock-in, we need to take into account two elements. 

The first one is the migration cost, giving us an overview of how much it costs us to migrate from the current cloud vendor to another. In most cases, it can be quantified in the total effort required to move a system from one cloud to another.

The second element that is sometimes underestimated is the opportunity gain. How much do you obtain by using the full spectrum of services provided by the cloud vendor, especially the SaaS ones? The opportunity gain is not reduced to less implementation effort, it means also:

• Better SLAs 
• Better NFRs
• Fewer incidents
• An easier way to build a robust system

 I often see organizations influenced by the migration cost and forgetting the opportunity they gain by cloud lock-in. 

Lock-in cost optimization

There are two ways on how you can reduce the lock-in cost:

• Minimize the migration cost
• Maximize the opportunity gain

As expected, in most cases, companies are driven by minimizing the migration cost. With the current technologies trends, it can be achieved easilty by using microservices and serverless approaches. For the rest of the system layers, to reach low migration costs, customers prefer to use products available on multiple cloud vendors or host them by themselves (e.g., inside containers). 

By having an approach like the one mentioned above, you limit the opportunity you gain by using the cloud and the specific cloud features offered by each cloud vendor. Take into account that there are no right or wrong solutions; there are just different approaches to optimize the lock-in cost.

Minimize the migration cost

There are a set of recommendations and best practices that are followed to minimize migration costs. They are covering the following three aspects:

(1) Standardized technologies

(2) Cross vendor programming language 

(3) Separation application domain from the platform

Standardized technologies

This topic covers all the layers of a system, from database and storage to how services are exposed to the public. 

Using an RDBMS database layer like MSSQL or MySQL ensures strong compatibility at the database layer between cloud vendors. HTTP and REST API are the standards at the API level, ensuring that you get the same support across all CSP (Cloud Service Provider). You should not be afraid to use services like Azure API Management or AWS API Gateway because migrating from one service to another is easy. 

For message base communication, the compatibility across cloud vendors is limited. To ensure that a standarzied solution is used to minimize the migration costs, Dapr or similar approaches need to be part of the strategy.

In the last few years, we saw that the AI, ML and Analytics services of cloud vendors started to use the same technologies stack. For example, Apache Spark is shared across all cloud vendors and can be used seamlessly. 

Another area where we need to be aware of is IaC and the tools used to build the infrastructure. To ensure a high level of compatibility between CSP and minimize migration costs, solutions like Terraform can be used that have a high level of reusability during the migration 

Cross vendor programming language

It is important to ensure that the cloud vendors support the selected programming languages. Java, .NET, NodeJS are the most common languages. Even if there is strong support for Go or Python, not all services from the CSP are not well integrated with them. Additional migration costs can be generated because of it.

Separation application domain from the platform

This topic will be covered in another article in detail. From our application code, we are integrating different CSP services and APIs to build our applications. By doing this directly, without an abstraction layer and good design patterns, the level of dependency that we have on a specific cloud vendor increase, making the migration more expensive. 

We forget that it is not enough to put our code in an AWS Lambda or Azure Function. As long as we access other services directly, migrating to another vendor will be complex and expensive. The business application code needs to be isolated from external dependencies by an abstraction layer.

Maximize the opportunity gain

Once you decide that your strategy is to maximize the opportunity you gain on a cloud vendor, things might become more complex than you expected. The high number of cloud services that each cloud vendor provides makes, pretty hard to decide what service you should for each specific scenario.

In this situation, you need to be driven by the idea to be as close as possible to the native cloud service. Use native cloud services and avoid doing things by yourself (customization and reinvent tools and features) is how you can maximize the opportunity that you gain. 

It involves going on an approach where most of the used services are from SaaS and PaaS offer by using the BaaS services provide by the cloud vendor. The best examples are messages, events and monitoring services. Going on an approach using Azure Services Bus or AWS Kinesis would maximize the opportunity that you gain. 

Conclusion

The cloud lock-in cost is not driven only by how easy a cloud migration can be done. The opportunity gain cost is an important factor that can influence the total lock-in cost. Finding the right balance between these two elements and exploring the opportunity gain cost in detail can change how you look at the multi-cloud strategy and the lock-in cost.