Multi-Cloud Is Not the Same as No Lock-In
Multi-cloud is sold as freedom from lock-in, but running on two clouds usually doubles your lock-in. What actually removes lock-in, and what just spreads it.
Multi-cloud gets sold as the answer to vendor lock-in. It is usually the opposite. Running on two clouds does not free you from either one; it ties you to both, plus the glue holding them together. You end up with two sets of proprietary services to learn, two bills, two failure modes, and an integration layer that is itself the hardest thing to move. Lock-in is not about how many vendors you use. It is about how hard it is to leave any of them. Real portability comes from owning the layers that matter and using standard, swappable pieces everywhere else, not from spreading your dependence across more providers.
Why multi-cloud does not remove lock-in
The pitch sounds logical: if you run on two clouds, no single one controls you. The reality does not work that way, for three reasons.
You use each cloud's proprietary services. The whole reason to be on a given cloud is its managed offerings, and those are exactly the parts that do not port. So going multi-cloud means adopting proprietary lock-in twice, not zero times. This is the same trap as serverless being the deepest lock-in: the convenient services are the sticky ones, and now you have them from two vendors.
The glue becomes the lock-in. Making two clouds work together requires an integration layer, custom networking, identity federation, data sync. That layer is bespoke and fragile, and it is the single hardest thing to migrate. You did not remove lock-in; you invented a new, worse kind.
Cost and complexity go up, not down. Two bills, two consoles, two security models, twice the surface to keep patched. You pay more to be less free.
What lock-in actually is
Lock-in is not vendor count. It is switching cost. The real question for any dependency is: if this vendor tripled the price tomorrow, how long and how painful is it to leave?
Measured that way, a lot of multi-cloud setups are more locked in than a single-cloud one, because now you have to unwind two proprietary integrations and the glue between them. Adding a vendor to escape a vendor rarely lowers switching cost. It usually raises it.
The clean way to think about it is the same test I use to spot lock-in before signing anything: look at your data format, your critical path, and your proprietary dependencies. Multi-cloud does nothing for any of those. It just duplicates them.
What actually removes lock-in
If spreading across clouds is not the answer, what is? Owning the layers that are cheapest to own and most expensive to lose, and keeping everything else standard.
Own the foundation. Your database, your deploy pipeline, your backups, your DNS. When those run on infrastructure you control, no cloud can hold them hostage, and moving your compute is a repoint rather than a rebuild. That is the entire reason I keep my database on a box I own instead of a managed service.
Use standard, swappable pieces. Postgres instead of a proprietary database. Object storage that speaks a common protocol instead of one vendor's exclusive API, so you get object storage you control. Containers instead of a platform's bespoke runtime. When each piece speaks a standard, replacing any one is cheap.
Keep an exit ready. For anything you do rent, know how you would leave and keep the export current. That is the discipline behind every vendor needing an exit plan. One well-prepared exit beats two clouds you cannot leave.
When multi-cloud is genuinely the right call
There are real reasons to run on more than one cloud, and I want to be fair to them. Regulatory rules may require data in specific regions no single provider serves well. A true never-go-down requirement may justify the cost of active redundancy across providers. And sometimes an acquisition leaves you with workloads on two clouds and consolidating is not worth it yet.
But notice that none of those reasons is remove lock-in. They are availability, compliance, and history. If your goal is actually to not be trapped, multi-cloud is the wrong tool, because it adds dependence rather than removing it. The thing that removes dependence is owning the core and standardizing the edges, which is the whole point of the own-your-stack approach. You get more freedom from one box you fully control than from two clouds you half control. Put the foundation on hardware you own at HostSSH, keep the rest standard, and lock-in stops being a thing you have to spread around to escape.