Design Considerations To Mitigate Cloud Vendor Lock-In
At the last AWS reinvent conference I heard a quote that right now, AWS looks like a “benevolent dictator” driving the public cloud market agenda but people are worried that there’s a fine line between a benevolent dictator and a plain-old dictator. The good old vendor lock-in fear came up in many conversations I had during the conference with attendees. This seems odd though because one of the benefits of the cloud specifically was to avoid lock-in and make applications more portable. Whenever you talk about vendor lock-in, you are talking about your migration costs if ever you needed to walk away from your current service provider. When you realize you are locked in, then it becomes very expensive. The solution to prevent vendor lock-in is to be aware of vendor and technology lock-in in the design, architecture, and implementation decisions that you make, especially the large and core ones. I am not advocating shunning public clouds, but I would like more people to go in with eyes wide open. Cloud providers are going at war (on both features/price) and the best seat in the theatre belongs to the ones that are not locked in.
There are a few reasons why someone would want/be forced to migrate:
• A competitor cloud provider has just announced a new region that is geographically apt for your performance needs.
• The cloud provider you currently use has a new product offering that competes with your core business/ customers. Think Amazon Cloud Drive vs. Dropbox, Amazon music vs. Spotify, Amazon Prime Video vs. Netflix. While its not required that you migrate, strategically it makes sense to migrate.
• Change in provider prices. Remember the Google App Engine price hike that caused a huge vocal outrage. While this is unlikely to happen given the ensuing cloud competition, one must still be prepared.
• A M&A scenario where parent company will eventually force migration to one vendor. Cloud providers offer substantial discounts based on your annual spend limits and bigger spends get bigger discounts. From a parent company perspective, consolidating providers to one provider will consequently bring substantial savings.
• One of your key product differentiators is performance and you can only tune so much with a provider black box system. This was the reason cited by Dropbox for their migration away from AWS. Companies like Dropbox are scrutinizing the true value of what AWS provides and weighing that against the costs and limitations of what they can get out of that platform. For startups, SMBs, and mid-market companies, the clear risk and enormous costs of building a custom infrastructure is just not a reasonable technology strategy however companies with deeper technology roots have done their due diligence and chosen to leave AWS.
Many vendors sell proprietary solutions made with almost exclusively open source components, so play close attention
Design Considerations to Avoid Vendor Lock-in
SaaS vs. IaaS vs. PaaS
Vendor lock-in happens more in SaaS situation than in IaaS (Infrastructure as a service) and PaaS (Platform as a service). So if you limit your usage of cloud as a IaaS then you avoid the lock in.
Industry Standard or a Vendor standard?
This is a no brainer. You can host your platform/ application on AWS without being locked-in if you choose to implement your solution using industry standards. An application relying on EC2 with standard Linux Distribution + RDS with MySQL is easy to port vs an application using Lambda and S3 where you are tied in to the vendor implementation. Some argue that there is a heated competition among cloud providers and they will develop services that are competitor API compatible but that’s a bet you are making. As of now none of the higher-level provider API/services are compatible between cloud vendors and a complete rewrite is required in case migration is desired.
Watch for Proprietary Glue/Integration Code...
Many vendors sell proprietary solutions made with almost exclusively open source components. It is the mixture of them together that makes it a proprietary solution. So play close attention.
What if a vendor standard or vendor specific solution gives you an edge, competitive advantage, or value that you cannot get anywhere else?
For example an application using image recognition using Google Vision API or Amazon Machine learning. Data/ network affinity will also force you to build the rest of the application around/nearby to these services. So sometimes it may be wise to lock-in with a vendor and even have a partnership with them because it gives you an edge that no one else has but even in this scenario keep a watch for competitor offerings/new features because vendors factor in your alternative options when making partnership deals.
Dual Implementation Policy
Design your application with two implementations on different vendors. Use this option when there are no industry standard API’s available for your use cases. While this sounds like a good plan its hard to justify the extra effort.
Use Containers to Minimize Instance Customizations
Instead of creating a custom EC2 AMI, use a container solution. This will abstract your dependencies and since most cloud providers support standard containers, you can easily port your application to other provider basic instance types.
Build a Cloud Agnostic Layer- Implement a layer that is cloud platform agnostic into your enterprise architecture and into your application landscape.
Each vendor provides their own services for things like centralized logging, auto scaling, monitoring/alerts etc. Unfortunately there are not many standard API’s for these services and you will have to employ the dual implementation policy here.
Be Prepared for Data Gravity
Data gravity means that once data is inside a given repository, it is difficult and expensive to move it. The longer (more time) an application stays in a specific Cloud the more difficult it is to move. Why? Data Gravity increases due to more Mass (data being stored). Luckily every vendor is aware of data gravity and its lock in benefits and hence pricing around data storage is very competitive. The only way to avoid this gravity is by replicating your data to multiple provider storage solutions.
Routine Compatibility Tests
Similar to redundancy test how about a compatibility test every now and then? The good old proven way to test readiness of a redundant environment is to often do a test where you point production traffic to redundant site during off hours and ensure system works. Similarly the best way to test compatibility is to fire up your application on a different cloud vendor and ensure things work fine.
Don’t Base your Architecture Entirely on Cost / Ease
Some basic services are/will be subsidized by cloud provides to lure people in. If some service is very cheap (Ex: AWS S3), its a trap to get you locked in. Don’t base your architecture entirely on cost. What to a customer first looked like an exciting new piece of software—easy to try, no strings attached—soon infests the organization and isn’t quite as easy to remove.
Spread Risk among many PaaS Providers
Expect to see a new breed of template application architectures that mix and match services from multiple cloud providers.