The Universal Remote

The Board wants “optionality” because they’re terrified of pricing power. They want to hear that we can switch clouds over the weekend. It sounds like prudent risk management. In practice it’s one of the most expensive habits in IT. We’re attempting to build an “Esperanto” layer for our infrastructure. We want a universal language that abstracts away the differences between the clouds. The problem with Esperanto is that nobody actually speaks it. When you force your engineering team to write generic code that runs everywhere, you ensure it runs poorly everywhere.

You’re paying for a “Universal Remote” that only supports the Power button. By refusing to use the proprietary features of your cloud provider you’re paying the premium price for the platform but using only the commodity features. You’re giving up execution speed to guard against a vendor pricing change that’s statistically unlikely to kill you. That’s financial anxiety dressed up as architecture.

Portability you never use is a premium you pay every month.

Worse, you’re crippling your velocity today to solve a problem that’s rapidly disappearing. If the day comes when you actually need to leave AWS then AI agents will likely be able to refactor your proprietary calls into Azure SDKs in an afternoon. The cost of code translation is trending toward zero. You’re optimizing for a future where migration is hard but we’re moving toward a future where it’s trivial.

We often point to 37signals leaving the cloud (opens in a new tab) as proof that we need this agility. They moved because they did the math on renting versus owning, not because they had a perfect abstraction layer. That was a capital allocation decision for a stable business. It wasn’t a feature of their code. Most of us aren’t moving to a datacenter. We’re just moving sideways to another landlord.

The lock-in that actually hurts is data. Data Gravity dictates that where your petabytes live is where your applications live. Moving that mass is a multi-year logistical nightmare. The abstraction layer you’re building is solving the easy problem while ignoring the hard problem. Pick a cloud and commit to it. “Lock-in” is just another word for “Leverage.”