Critiquing cloud lockin

I hear a lot of talk about cloud lockin. I hear it from people with self funded startups, authors on tech blogs and developers. The argument I hear most is that if you start using cloud native tooling, you’ll become dependent on it, accumulate tech debt and be forever burdened. There are of course legitimate reasons to be cloud agnostic, such as if your customers actually care what cloud your on, if your making a product that customers can self host, or if it makes compliance easier. In most other cases, I believe that a cloud agnostic approach incurs many of the same costs as a cloud native one, that the cost of migrating away from a cloud native solution is overstated and that the gains from using cloud native technologies outweigh any technical debt accumulated.

There is an idea that cloud native solutions impose technical debt, that the initial convince is offset by added complexity or cost later on. This may have some truth, but I’ve yet to see anything indicating that this is not also just as true for cloud agnostic technologies as well. There is a fear that your cloud service may cease to exist or cancel a service on you. This is an inherent risk of all Saas’s cloud or otherwise. The large cloud companies are generally financially stable and not going to go out of business anytime soon. Services may be deprecated but it depends on the cloud, AWS still supports services on its API that have been phased out 10 years ago. GCP is more heavy handed.

Another concern is that the price of your existing services will go up. This is possible but not for the obvious reasons. Generally speaking, prices for services go down as the clouds get bigger and rates get lower as you consume more. It may be that you reach a scale that the costs of managing your own workload outweigh the costs of using a managed service, but at that point you’ve already saved time and money to help offset the cost of refactoring. Moreso, the inherent scalability of managed services gives you time and breathing room to refactor at your own pace. I’ve heard people talk about hidden costs that don’t show up until a certain point before hitting you big. This is also partially true; some services charge per use or by bandwidth, this could mean that some inefficiencies won’t be discovered until you scale and can lead to unexpected charges. This is why its important to monitor and set billing alerts, especially after you deploy large changes.

If the cost of migrating away will be higher than the savings gained by leaving you are locked in. There’s little direct cost involved except for maybe bandwidth but that’s generally negligible; in fact if anything a competing cloud company (or one of their partners) may even incentivize you to move. It’s true that migrations can be a painful and expensive, but that’s generally not because of the cloud. More likely the culprits are things like uptime requirements, lack of documentation and the fact that no one has restarted the servers in a few years and don’t know what will happen when they do. Often times, its not much harder to migrate to another cloud than it would be to migrate to a new account in the same cloud.

There is the fact that your engineers will need to learn new technologies. This is a real cost, although it can be mitigated by a phased migration approach. Going mutlicloud can allow your engineers time to learn the new services before you completely move everything over. Some services API’s are also flexible. There are adapters that allow you to use the S3 interface to access files on other clouds blob storage solutions.

Cloud providers generally strive to provide service parity. Additionally, many of the services that cloud providers offer are in based off of commonly used or open source projects to begin with. This means that even if another cloud doesn’t offer a similar service, you can likely still use the original product it was based on. A multicloud solution may give you the best of both worlds, allowing your engineers more time to learn the new cloud and allowing you to pick and choose which services you want from each provider. Certain things can not be easily migrated. Things like the fundamental building blocks like security groups and IAM may have different paradigms that require a refactoring. Some formats like machine images can’t be natively exported but there are native tools that can not only move these formats but can move entire workloads. Many of them are provided free of charge by the competing cloud providers themselves.

Cloud lockin is an ideal that’s often overvalued. Leaving the option open for a migration could be a good idea, but cloud native services can provide an easy and scalable way to build your workload. Its important to understand the tradeoffs as you build. Acquiring technical dept and increasing your exit cost is not an inevitability. Research before building, adopting a multi-cloud approach and embracing refactoring can mitigate the cost of a future migration. There are valid reasons for going cloud agnostic but there’s no reason to consider it a “best practice”. In short, do whatever gets you in production in a quick, stable and secure way. Happy building!