[Cloud lock-in] Overview and pros and cons of cloud lock-in / AWS

I will start a series of posts about how we can avoid cloud lock-in and interoperability between managed cloud services and external systems using different solutions on the market.

Cloud lock-in Overview

There are multiple definitions on the market, but when we talk about cloud lock-in or vendor lock-in, we refer to direct and indirect costs of a platform to be moved from one cloud vendor to another.

The lock-in makes customers more dependent on a cloud vendor, and migration to another vendor becomes expensive. There are multiple dimensions of cloud lock-in that we need to be aware like:

• Storage (AWS S3)
• Data (AWS RDS)
• Payloads (AWS EKS, AWS Lambda)
• Communication (AWS SNS, AWS Kinesis Firehose)
• Infrastructure (AWS VPC)
• Managed Cloud and Monitoring (AWS Cloudwatch)

We need to be aware that cloud lock-in comes with advantages, especially from the time-to-market and cloud economics point of view.

Cloud Managed Services like AWS Elastic Beanstalk, AWS SNS, AWS ElastiCache help us build a platform in no time. The effort required to build the infrastructure and implemented the NFRs (e.g., availability, redundancy, backup and recovery) is drastically reduced, together with the SLA that are provided for each Cloud Managed Services. It is much easier for the support team to manage the services that are out of the shelve offered by cloud vendors like AWS or Azure.

Should I go ALL-IN?

Going all-in for a cloud vendor provides a high level of agility and the effort required to manage the infrastructure, stack components like cache or DB and middleware are very low. Using this approach there is more time to invest in security, scalability, DR and HA and cloud managed services competencies. 

Pros and Cons

The most important cons of a cloud lock-in are:

• Dependency outages - Using a high number of cloud-managed services increases the chances to have service down. Even if we are backed by SLA and a recorded history we need to be aware of it and mitigate it when necessary. 
• Leverage - When you have a high level of dependency on a cloud vendor it is harder to negotiate the costs or what you get for that amount of money.
• Migration - Using a high number of PaaS and SaaS services makes it harder to embrace another cloud vendor.

The pros of cloud lock-in are:

• Speed to market - Cloud Managed Services saves us weeks of hard work to implement and manage different bits of our systems (e.g. AWS RDS, AWS S3, AWS Device Farm)
• Technical Dept - Especially because of SaaS services and the integration packages, the technical dept of our systems is much much lower.
• Innovation - It is much easier to integrate a serverless or a NoSQL solution when you just spin it up from the dashboard, with ZERO effort on installation and configuration. The best example here is AWS RDS , which you can run spin-it-up in just a few minutes, ready to host your databases.
• Consistency - You have the same approach across your entire system. From the security or monitoring point of view, you can use the same approach for all the system components. 
• Knowledge Competencies - It is much easier for teams to work with the same services across multiple systems and to have consolidated best practices and recommendations related to how to integrate different components. 

The real challenges

 Large organizations have a strategy to avoid cloud lock-in. This can be achieved at the program level, ensuring that different parts of the systems run in different cloud vendors or by building the systems to run seamlessly (more or less) on multiple cloud vendors.

The real challenge is finding the right balance between Cloud Managed Services (PaaS and SaaS) and the ones you managed by yourself.

 In the last few years, adopting containerization solutions like Kubernetes combined with different solutions like Dapr enabled us to achieve a higher level of interoperability with less effort and a high degree of loosely couples between cloud services and the application. 

The out of the shelf integration and abstraction layer that Dapr offers, give us the ability to switch between AWS SNS and Azure Services Bus without making changes at the application layer. Kubernetes enable us to run the same application inside AWS EKS or Azure AKS seamlessly.

There are many other ways to handle cloud lock-in and each of them will be discussed in a series of articles.

Is cloud lock-in so bad?

YES and NO

There are many aspects that need to be taken into account when you decide what level of cloud lock-in you want to have. You can find below a list of items that need to be taken into account when you take such a decision:

• Organization strategy related to cloud vendors
• Regulation and Compliance 
• Time-to-market
• Learning curve
• Infrastructure skills to manage all the components (e.g. DB, Storage, Cache, FW, ...)
• System lifecycle (1-3-5-15y)
• Geographical deployments locations
• Cost of managing the platform
• Functional requirements 
• NFRs
• Architecture approach and design
• Running costs (high volume of consumption on a cloud provider can facility getting a better price - Amazon EC2 Reserved Instances)
• Transfer costs across cloud vendors 
• Security and Monitoring across cloud vendors