At the last AWS reIenvent 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.

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. A 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.

Use containers to minimize instance customizations

Instead of creating a custom EC2 AMI, use a container solution instead. 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.

Deployment/Operations setup

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.

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.

Platform vs. Product Agility

Platform agility is as important as product agility. Agility is the ability to make changes (useful ones, we hope!) without much pre-planning and without rocking the boat. Agility is the ability to go from idea to experimentation very quickly, and to go from experimentation to actual deployment equally quickly. Product agility is defined as how fast you can pivot and crank out features. Platform agility on the other hand primarily relates to how quickly you can make changes to your platform without affecting product agility. Choosing a non-industry standard cloud provider service can sometimes enhance your product agility but by getting into a vendor lock in, you dent your platform agility. Technical leads have to continuously watch/fight for platform agility, as there will be a lot of pushback from product team.

In summary, it is essential that companies approach cloud services with open eyes that look beyond compute and storage to help avoid lock-in. The strategy employed should be based as much as possible around platforms and technologies that are open and are based on market standards. Provider-specific technologies, platforms and software solutions should be avoided at all costs. Many big exoduses have happened from AWS cloud. Would love to see a blog article from these companies on their move strategy.