Vendor lock-in: An unfortunate condition that forces a person or company to continue using a disliked product or service just because they invested in it so much. Vendor lock-in used to affect mostly large companies using mission critical legacy applications, but as more and more companies move to the cloud, cloud providers started to rediscover the joys of vendor lock-in by offering “value-added” services that simplify the lives of software developers who have better things in life than managing servers and databases.
I think most anyone would agree that virtual machines (VMs) that one could launch and destroy in seconds, and easily resizable block storage attached to such machines are generally good things. We don’t have to buy or rent servers which have more capacity than we need. We also don’t do really low-level machine maintenance tasks like replacing failed hard drives anymore. These days we are not really managing servers; they are already managed for us, but the thing is, given so much competition, there isn’t probably much profit left to cloud providers for offering plain-vanilla VMs. Where is the value-add in that, they would ask.
Put yourself in the shoes of a cloud provider eager to increase their stock price, and start pondering questions like “what are the things that are very hard to change in software development once you are committed to them?” Easy, the programming language itself, certain libraries such as ORMs, …and the databases used. Ah, the epiphany!
Cloud providers can’t really create their own languages or libraries, but they can all offer their own versions of popular databases in managed form. Managing and scaling databases is scary, they say. “You don’t have to worry about all that anymore. Just use us, and focus on your code.” Sounds tempting, doesn’t it? In reality, a managed database offering that is hard to migrate from probably isn’t such a good idea. When in doubt, using a PostgreSQL database on a simple VM can get you a long way, and doesn’t really require much maintenance, if at all. Sure, you need to monitor the resource usage of the VM from time to time, but all cloud providers offer built-in monitoring services, and it’s impossible to get a surprise bill for a simple VM as opposed to managed database servers that can auto scale. The worst you could do with a VM is to overload it. If that happens, it’s probably because your code is inefficient or you forgot to add an index to a column, or maybe everything is fine, but your app is getting popular. If you really are getting popular, that’s a good problem to have: upgrade the VM with more cores and memory, and go back to coding or whatever you were doing.
Come to think of it, although I said cloud providers couldn’t really create their own languages, they really came close by offering “serverless” code running environments. Again, it could be even harder to migrate from those offerings than migrating from managed databases, and surprise bills, once again, start to become a very real possibility. Again, when in doubt, running your code on a simple VM deployed by “git pull” can get you a long, long way.
Related: