A team proposes wrapping every cloud provider SDK behind an internal abstraction so the company could migrate providers later. Evaluate the proposal.

What is being tested

Whether you price an abstraction against the probability that its option is ever exercised, rather than treating portability as self-evidently good.

The case against, stated honestly

An abstraction over multiple providers tends toward the lowest common denominator. If it must work on three clouds, it can only expose what all three support, which means giving up the managed capabilities that were the reason to be on a cloud at all. You end up running your own queue on virtual machines because the abstraction cannot express any provider's managed one.

The second cost is that abstractions leak most at the failure boundary. Providers differ in consistency guarantees, error taxonomies, retry semantics, throttling behaviour and eventual consistency windows. An interface that hides those differences is lying, and code written against the lie breaks on the other provider anyway — which is to say the migration you paid for does not actually work.

The third is that most such abstractions are never exercised. They are pure overhead with a story attached.

The case for, and when it holds

Dropbox's move of file storage off Amazon S3 onto its own infrastructure is the strongest counter-example. It worked at petabyte scale, while the product kept running, largely because application code had long stored and retrieved content-addressed blocks through an internal interface and knew nothing about the underlying provider. Had S3 semantics been spread through every service, the migration would have been implausible.

Note what made that abstraction correct:

• It was narrow. Blob storage with a small verb set — put, get, delete — which is genuinely similar everywhere, so the abstraction was not lying.
• It was over something enormous. Storage was the dominant cost line, so the option had real monetary value.
• The option was actually exercised. The economics of owning storage at that scale made the migration inevitable, not hypothetical.

The rule to take away

Abstract the narrow, high-volume, semantically simple dependencies where the option has plausible value: object storage, sometimes queues, sometimes secrets. Do not abstract the rich managed services — identity, managed databases, event platforms — because the abstraction cannot be honest and the migration will be a rewrite regardless.

A better answer than either extreme

Do not abstract for portability; abstract for testability and clarity, and accept portability as a side effect where it happens to fall out. A thin internal interface that exists so tests do not need a live cloud account is cheap and pays for itself immediately. The same interface may later turn out to enable a migration, and if it does not, it has already earned its keep.