Why cloud abstraction layers rarely deliver portability

Does Kubernetes make workloads portable?

It makes the application portable and stops at the boundary of the cluster. A container, a deployment manifest and a service definition will run on any conformant cluster, and that is a genuine and useful property. What does not travel is everything the cluster touches: how a load balancer is provisioned, how storage classes map to underlying disks, how pods obtain credentials for cloud services, how nodes scale, how the registry authenticates, and how ingress is terminated.

Those differences are not cosmetic. On one provider a service of type LoadBalancer produces a network load balancer with one set of annotations; on another the annotations, the health check semantics and the timeout defaults differ. Pod-level identity is implemented differently on each platform, which means the mechanism by which your application gets a database credential is one of the least portable parts of the system. Storage is worse, because volume snapshot and resize behaviour vary and stateful workloads depend on the details.

The practical consequence is that a Kubernetes estate is perhaps eighty percent portable at the manifest level and much less than that in operations. The remaining portion is where the incidents are, and it is exactly the part a team has to learn again on the second provider. Kubernetes is worth using for many reasons. Treating it as a completed multi-cloud strategy is the error.

What does Terraform actually give you?

One workflow, one state model and one review process across providers. That is valuable and it is not portability. A Terraform configuration for a virtual network on one provider shares no resource types, no arguments and no structure with the equivalent on another, because each provider's resources are modelled separately. Moving a stack between clouds means rewriting the configuration, not changing a variable.

The value is real in a different place. Having every environment defined in code, reviewed, and reproducible is the single largest determinant of how quickly you could stand up anywhere else, because the alternative is discovering that production contains years of console-made changes nobody recorded. Teams that keep this discipline can rebuild an environment; teams that do not cannot, regardless of how many providers they use.

Modules are where expectations go wrong most often. An internal module that presents a uniform interface across providers has to model the intersection of their capabilities, and that intersection is smaller and less stable than it appears. The usual outcome is a module with provider-specific escape hatches, at which point the abstraction is documentation with extra indirection.

What stays provider-specific whatever you use?

Identity, networking, cost structure and the operational surface. These are the four layers no tool abstracts convincingly, and they are also the four that consume most platform engineering time, which is why abstraction saves less than the diagram suggests.

What happens when you build your own abstraction?

It becomes an internal product, and internal products need owners, roadmaps, documentation, support and a deprecation policy. Teams rarely plan for this. The wrapper is written during a project, it works, and then a provider ships a feature that the abstraction cannot express, a developer needs it, and an escape hatch appears. After a few of those the abstraction constrains without protecting.

There is a second failure that is harder to see. Because the layer must work everywhere, it can only expose what every target supports, so the platform your developers experience is the intersection of the providers rather than the best of them. That cost is paid continuously by every team building on it, and it is invisible because nobody compares the internal platform to what they could have used directly.

The third failure is staffing. The abstraction has to keep pace with several providers' release cycles, and the people who understand it become the constraint on every project. When they leave, the layer is a system nobody wants to own, sitting between every application and the infrastructure. This is the most common way multi-cloud programmes leave permanent damage even after the multi-cloud goal is abandoned.

When is an abstraction layer the right call?

When you ship software into other people's clouds. A vendor whose customers require installation into their own AWS, Azure or Google accounts genuinely needs one packaging and deployment model across all three, and the abstraction is part of the product rather than overhead on top of it. The cost is justified because it is amortised over customers, not absorbed by one platform team.

It is also reasonable when the abstraction is deliberately narrow and covers a single concern. A thin internal interface for object storage, or for publishing a message, is a small piece of code with an obvious boundary, and swapping the implementation is a contained change. What fails is the general-purpose platform that abstracts everything, because the surface never stops growing.

The third legitimate case is regulatory repeatability, where an organisation must demonstrate that a service can be stood up in another environment on a defined timeline. Even then, the cheaper route is usually a rehearsed and documented rebuild rather than a permanent layer, because the requirement is evidence of capability rather than continuous readiness.

What should you do instead?

Contain the provider-specific parts rather than hiding them. Put the calls that touch a provider behind interfaces your own code defines, keep a written list of where those interfaces exist, and accept the platform's native tools everywhere else. This gives you the same replaceability that an abstraction promises, without a layer between every team and the infrastructure.

Then apply a test before adding any general-purpose layer. Ask what the layer would have to expose for the three most demanding workloads you run, and whether it can express the provider features those workloads actually depend on. If the answer requires an escape hatch on day one, the abstraction will not survive contact with your roadmap, and building it anyway converts a portability goal into technical debt.

A useful afternoon exercise: pick one running service and list every provider-specific dependency it has, including how it authenticates, where its secrets come from, how it is routed to, where its logs land and how its data is backed up. The list is nearly always longer than the team expected and it is almost never the application code. That list, kept current, is worth more than any wrapper you could write against it.