I have worked with many companies to help them either migrate to the cloud or develop new cloud applications for over 10 years. A very common requirement is that the designed architecture avoid using any cloud vendor specific technologies or services. The rationale is usually that although we are running our application on vendor X today we may want to run it on vendor Y tomorrow and don’t want to use any services that don’t directly translate.
In my experience, I have seen none of those companies actually make the jump from vendor X to vendor Y while using the delivered architecture. I’m sure there are some companies out there who have and my sample size is likely small but I will still argue that a strict mandate on avoiding vendor-specific services may hurt more than help in the long run.
Let’s take a company who is moving a currently on-premises two-tier application to the cloud. The application has a REST interface with a backend MySQL database. They want it to be cost efficient and to minimize the management needs. Both of which are very reasonable requests.
Now let’s imagine what that architecture may look like on AWS. The “lift and shift” would result in a load balancer, one or more EC2 instances, and a MySQL database. But we can do better in terms of cost and management. We can implement the REST API in AWS API Gateway, implement our services as AWS Lambda functions, and host the database in Amazon RDS. This architecture is scalable, removes the need to manage security updates on the EC2 instances since there aren’t any, and removes the management of the underlying database hardware by using RDS. This looks like a good AWS architecture.
But wait. AWS API Gateway, AWS Lambda, and RDS are all AWS-specific. Won’t that mean vendor lock-in by the definition that those services are all specific to AWS? Yes, it will. Ok, let’s try to remove that lock-in. We can run the REST API on one or more EC2 instances because virtual machines are virtual machines no matter where they are running. We can put the database on an EC2 instance because, well, it’s just a virtual machine. That’s all easily portable to a different vendor. But that’s the same architecture we started with before this exercise!
This “generic” architecture is missing out on a lot of great capabilities that we could be utilizing. We will have to manage the EC2 instances, apply updates, manage access control, keep the database server up to date, perform manual database backups, and determine some scaling policy for our application. Things that we could have had by using native AWS services. By trying to be generic we are increasing costs and potentially providing a user experience that could be improved at the cost of actual money and because we don’t want to use vendor-specific services.
By trying to be generic we may be actually increasing costs and potentially providing a user experience that could be improved at the cost of actual money and because we don’t want to use vendor-specific services.
You may say “but we use a tool like Terraform to manage our deployments.” That’s good, but even those scripts will need reworked to support a different cloud provider. Some services do not translate and some may not have exact equivalents between cloud providers. Using Terraform is fine but using it instead of a native tool like AWS CloudFormation will require you to manage state which CloudFormation handles for you. Is it really necessary to add another level of complexity right now?
I argue that creating your application to take advantage of your current cloud provider’s services is the best choice. You will likely have lower costs all around and a better experience. It’s fine to keep the thought of avoiding cloud vendor lock-in in the back of your mind if it is your organization’s goal, but don’t let it become such a requirement that it ends up harming your application and your end-user’s experience. In most cases, taking full advantage of the vendor’s native services will prove to be the best choice in terms of cost, scalability, and performance.
You don’t go buy a house and then only use the living room because one day you might want to move. If you use the living room as a kitchen it might work, but it’s going to take a lot more work. Use all of the house while you have it and when it comes time to move you will naturally decide the best configuration for living in the new house prior to moving in.
This post was previously published at https://medium.com/@jzonthemtn/the-fallacy-of-avoiding-cloud-vendor-lock-in-6f0d9e8a3391.