This is part two of my three part cloud trilogy:
- AWS vs Azure
- Lock-in (this post)
- Pricing
Lock-In
Cloud hosting can be very convenient and some of the value-add services that are offered on top of the basic packages can save a lot of time. However, you need to be wary of automatic lock-ins that can trap you in a particular host if you wish to migrate later.
The key is to stay generic and only use services that can be easily provided anywhere with no changes to your application. This means using software that you can run yourself and avoiding bespoke custom services that only run on a single cloud platform.
To borrow some analogies from economics, you want products with a high liquidity and fungibility. In other word, they can easily be exchanged for alternatives.
Using only the generic products is easier said than done and there is a sliding scale of how much lock-in they all have. To keep things simple I’ll provide a few examples in two categories and highlight some alternatives for the high lock-in products.
There are far more services than listed here and they don’t all neatly fit into two groups but this should give you a good idea of what to consider. There is a good open guide on AWS here that is more thorough.
Low Lock-In
Using a server instance directly with Azure Virtual Machines or AWS EC2 is clearly low lock-in. You can get servers everywhere and configure them to your needs. One thing you may want to consider is how easily you can get your server disk images in and out. However, if you are using DevOps practices and build you servers from the vanilla OS using scripts then this shouldn’t be an issue.
Similarly, if you are using an application hosting product such as Azure App Service or AWS Elastic Beanstalk then you shouldn’t get locked in. You could easily move you code to an different provider and it may even be easier than with basic instances if you don’t practice DevOps automation.
For normal relational databases you should also be fine. These products are usually just hosted versions of normal databases that you can run yourself. Amazon’s Relational Database Service (RDS) offers PostgreSQL, MySQL, MS SQL Server and others. Azure SQL is very similar to SQL Server and you can get MySQL from ClearDB.
Caches also typically use open source software, normally redis. Amazon’s ElasticCache and Azure Cache both offer this.
Pure file storage (such as S3) is normally OK too. You can just move your files to another host, but be wary of data transfer costs. Although if you use a cheaper cold storage service (such as Glacier) then it can be slower to get your files out.
High Lock-In
Using specialist NoSQL databases such as Azure DocumentDB or Amazon DynamoDB will lock you in to that platform. It would be much better to use an open source NoSQL DB such as MongoDB or CouchDB. You can even use traditional relational DBs in this style. For example, PostgreSQL has good JSON document support and there are many projects to use this in your programming stack (e.g. Marten for .NET).
If you use a custom message queuing solution such as Azure Service Bus / Notification Hubs or AWS Simple Queue Service (SQS) then this can also tie you in. It’s better to use a standard queuing system such as RabbitMQ. If you want a hosted version then services are available but you can always run it yourself. This also makes development easier as you can install a local copy to test with.
If you enjoyed reading this, or at least found it useful and interesting, then you will probably like my book on how to make high performance web apps. It includes plenty of discussion on cloud computing and vendor lock-in. The book covers how the choices you make affect the performance and agility of your application, and in turn the happiness of your users.
I’m also available for hire.