Kubernetes Promised Portability. So Why Are So Many Locking Themselves In?

When Kubernetes exploded onto the scene, it sold a powerful idea: build containerized applications once, run them anywhere. Portability became the rallying cry.

But the reality playing out in businesses today looks very different. Instead of breaking free from lock-in, many teams are finding themselves more entangled than ever, just higher up the tech stack.

Portability sounds good on paper. In practice, it’s a minefield of compromises, operational complexity, and false economies. If businesses don’t rethink how they’re building for cloud native now, they’ll end up paying a far steeper price later.

Kubernetes didn’t kill lock-in; it moved it

One thing is certain — containerised applications are taking over Australian IT. In the recent Enterprise Cloud Index (ECI) report, every local respondent (that’s right, 100%) said they were at least in the process of containerising their applications. Almost a third (31%) said all newly developed applications were being containerized.

The same report found that AI was the main driver, with three-quarters of Australian respondents citing GenAI as the most containerized applications in their organizations.

But there’s a hard truth many cloud-native teams are confronting. Kubernetes doesn’t magically make applications portable — it just shifts the lock-in problem.

Sure, you’re no longer tied directly to a single cloud provider’s infrastructure APIs. But now you’re locked into your Kubernetes distribution, your orchestration tooling, and an ever-growing web of third-party storage, networking, and security plugins.

The catch? Many of the best features of the cloud, such as managed databases, event-driven services, and serverless runtimes, don’t translate cleanly into a Kubernetes abstraction. Use them, and you’re tied to that cloud. Avoid them, and you lose the speed and simplicity that made the cloud attractive in the first place.

Too often, businesses hoping Kubernetes would future-proof them against lock-in are discovering a harsher reality: you still have to pick your dependencies carefully. And when requirements change, whether due to costs, sovereignty, or security, you’ll wish you had designed for portability upfront, not as an afterthought.

The day after tomorrow

Now, even if you do build theoretically portable apps, another challenge hits fast. Enter “Day Two operations.”

Containerized apps, particularly those built as sprawling microservice architectures, are never “set and forget.” Each microservice may have its own patching schedule, security risks, scaling patterns, and operational quirks. Without strong lifecycle management from the start, your modern app quickly turns into a tangled mess of half-updated components and firefighting incidents.

This isn’t just technical debt; it’s real financial cost. Teams get buried under operational overhead. Deployments slow down. Security risks pile up.

In many ways, the chaos some teams are seeing today with cloud-native mirrors what happened in the ‘wild west’ early days of microservices. Without strong operational disciplines, the supposed agility and portability of these architectures collapse under their weight.

Portability isn’t just about building right; it’s about operating right, every day after launch.

‘Old-school’ engineers are the cloud-native edge

There’s a narrative that cloud-native engineering belongs to a new breed of talent: developers who grew up in a world of containers, APIs, and serverless services. But when you scratch the surface, it’s often the “old-school” engineers who bring the real advantage.

Engineers who cut their teeth on physical infrastructure, who know that compute, storage, and network capacity aren’t infinite, tend to build more efficient, resilient systems. They don’t assume “infinite scale.” They know how to optimise for cost, performance, and real-world limitations.

As businesses move to hybrid and private cloud models to regain control over costs and sovereignty, this experience becomes invaluable, particularly when considering the local skills gap. The same ECI report found that, despite the rapid uptake of containerization, only 53% of Australian respondents felt they had the necessary skills to support cloud-native applications and containers. This was 10 points lower than the APJ average of 63%.

Upskilling your engineering talent to operate in a cloud-native world isn’t a fallback plan. It’s a smart way to build cloud native teams that know how to balance scale, cost, performance, and reliability without chasing silver bullets.

The real goal of Kubernetes adoption shouldn’t be chasing an abstract idea of “run anywhere.” It should be smart, deliberate portability, designing applications that are portable enough to meet business needs, without introducing needless complexity.

It means understanding where your lock-in risks are, mitigating them thoughtfully, and prioritising a platform that eliminates the trade-offs and simplifies the real-world demands of Day Two and beyond.

With the right mindset, skills, and platform, Kubernetes can deliver on its full potential. Armed with everything they need to succeed, practitioners can ensure that containerized applications deliver the promise of portability — not just in theory, but in the real world.

The views and opinions expressed in this article are those of the author and do not necessarily reflect those of CDOTrends. Image credit: iStockphoto/Afry Harvy