The Real Cloud War Is Not About Cost, It Is About Dependency

Jun 20, 2026

10 min read

1 views

87%

The hidden question behind cloud sovereignty

What if the biggest barrier to digital independence is not money, regulation, or even technology, but habit?

That is the uncomfortable tension at the center of the cloud debate. On the surface, the issue looks like a geopolitical procurement problem: Europe wants to reduce dependence on US hyperscalers, while the market keeps drifting in the opposite direction. But underneath that is a deeper and more interesting reality. Modern software is no longer bought as a stack of products. It is inherited as a gravity field. Once a team starts building inside one ecosystem, every future decision bends toward it.

That is why the “escape” problem is so hard. It is not simply that one vendor is better than another. It is that cloud platforms now bundle together compute, storage, deployment, identity, analytics, observability, AI tooling, and developer workflows into a single, sticky operating environment. Moving away is less like switching supermarkets and more like rebuilding your kitchen, your recipes, and your memory of how to cook.

And yet, the rise of modern open source tools points to a surprising counterforce. The same era that made hyperscalers powerful also made it possible to assemble credible alternatives for authentication, databases, design, localization, policy, scheduling, newsletters, and even AI workflows. The real story is not “open source versus cloud.” It is something subtler: modularity versus lock in.

The future of digital sovereignty will not be won by replacing one giant with another. It will be won by reducing the number of places where switching costs can quietly accumulate.

Why lock in feels invisible until it is too late

Most people think dependency is a big dramatic event. In practice, it arrives in small conveniences.

A team chooses managed authentication because it saves a week. Then it chooses managed storage because the integration is simple. Then it chooses the vendor’s monitoring because it is already there. Soon the architecture is not a design, it is a path. At every step, the choice is rational. At the system level, it becomes nearly irreversible.

This is the key insight: lock in is not mainly caused by bad decisions, but by good decisions that compose poorly over time.

That is why cloud concentration is so durable. A hyperscaler does not need to trap customers with one giant technical moat. It only needs to create enough tiny conveniences that migration becomes a project nobody wants to own. Each service solves a real problem. The sum of the services solves a bigger problem for the provider than for the customer: it creates a web of dependencies with compound interest.

Think of it like a city built with excellent roads but no sidewalks. Driving is easy everywhere, walking becomes difficult everywhere, and eventually nobody remembers what a walkable city was supposed to feel like. Hyperscalers are the roads. Open source tools are the sidewalks, local shops, and side streets that keep the city navigable when the highway system is congested or controlled by a toll authority.

The point is not that roads are bad. The point is that when roads dominate every movement, the city loses optionality. Digital infrastructure works the same way.

The new open source advantage is not ideology, it is composability

For years, open source was often sold as a moral choice: transparency, freedom, community, control. Those remain real benefits. But the most important advantage today is more practical and more strategic: composability.

A modern stack built from open source tools can now cover a shocking amount of ground:

Supabase for backend primitives and database driven apps
Stack Auth for authentication
Penpot for design collaboration
Tolgee for localization
Listmonk for newsletters
Rallly for scheduling
OPAL for policy administration
ChartDB for visualizing databases
Encore for type safe backend development
Taipy for AI web apps
KitOps for model management
Crawlee for scraping and data collection

Individually, each tool is useful. Collectively, they suggest a different model of infrastructure: one where a company can assemble a custom platform without surrendering every layer to a single vendor.

This matters because modular systems create a different kind of power. In a monolith, the vendor controls the whole experience. In a modular ecosystem, value comes from the ability to swap parts. If one authentication layer becomes too expensive, you replace it. If one scheduling tool becomes inadequate, you migrate. If one localization workflow is clumsy, you change it without rewriting the rest of your business.

That is not just a technical convenience. It is a political and economic property. Swappability is sovereignty in engineering form.

If every component can be replaced, no component becomes destiny.

The irony is that open source is sometimes dismissed as fragmented or “not enterprise ready,” while hyperscaler ecosystems are praised for coherence. But coherence has a hidden price: it often means the customer’s system starts to mirror the provider’s assumptions. Open source tools, when chosen well, let you preserve coherence at the application level while avoiding dependence at the platform level.

That is a better form of control. Not less structure, but more agency.

The black swan is not a crisis, it is a design test

Geopolitics often changes infrastructure thinking faster than technical debate does. A sudden policy shift, sanctions regime, data residency dispute, or pricing shock can expose whether a company or region has built an adaptable stack or a fragile one. These are the moments when people discover whether their architecture was resilient or merely convenient.

But the phrase “black swan” can be misleading if it makes us think only of rare catastrophes. In infrastructure, the more common black swan is not a disaster. It is a surprise that reveals hidden brittleness.

For example, a company may discover that migration costs are far higher than expected, not because it used a single malicious vendor, but because its internal skills, workflows, and data models have become too specialized around one ecosystem. Even a competent in house team can be trapped by accumulated context. The more a platform abstracts away complexity, the less visible that complexity becomes until it must be moved.

This is why the barrier to independence is not merely technical. It is also organizational. A team that knows only one cloud language, one deployment model, and one identity system is not really using infrastructure, it is living inside someone else’s operating grammar.

Here is a useful mental model:

There are three layers of dependency

Infrastructure dependency: compute, storage, networking, managed services
Skill dependency: what your people know how to operate
Workflow dependency: how your organization ships, debugs, approves, and changes systems

Most conversations focus on the first layer. The hardest to unwind is often the third. You can buy your way out of infrastructure dependency faster than you can unlearn workflow dependency.

That is why sovereignty is not achieved by procurement alone. It must be designed into the everyday behavior of teams.

A practical framework: build for exit before you need it

The most powerful response to platform concentration is not rejection. It is designing optionality intentionally.

That sounds abstract, so let’s make it concrete. Suppose you are building a product that needs authentication, user data, newsletters, scheduling, and AI features. A default modern approach is to let one cloud ecosystem or one integrated platform provide all of it. The result is speed now and dependency later.

A more resilient approach is to treat each capability as a replaceable module with a clear interface. The goal is not to assemble a brittle Frankenstein stack. The goal is to isolate failure domains so that no single layer controls your entire business.

This leads to a simple rule:

Adopt managed convenience at the edges, but preserve independent ownership of the core.

What counts as the core? Usually anything that defines your product identity, customer relationship, or data model. If that lives inside an external platform in an opaque way, you are renting your own foundation. By contrast, if the core remains portable, the surrounding services can be as convenient as you like.

A helpful test is to ask:

Can we export our data in a form we can actually use?
Can we replace this service without rewriting the whole application?
Do our engineers understand the underlying concepts, or only the vendor’s interface?
Would a pricing change, compliance issue, or regional restriction force a redesign?

If the answer to those questions is no, then the system is not merely optimized. It is captured.

This is where open source shines most clearly. Not because every open source tool is automatically superior, but because the ecosystem makes it easier to choose components that are inspectable, portable, and community supported. Open source does not eliminate coordination cost. It changes who bears it. Instead of paying forever in platform rent, you pay more upfront in architectural discipline.

That is a trade worth making when independence matters.

The deeper lesson: sovereignty is a property of systems, not slogans

The strongest temptation in the cloud debate is to turn it into a moral narrative. One side is good, the other side is bad. One camp values freedom, the other values convenience. But reality is less theatrical and more useful.

Sovereignty is not a slogan. It is a system property created by a thousand design decisions.

A region can declare digital independence while still training its workforce on a narrow set of proprietary tools. A startup can praise openness while building its entire product around opaque managed services. A government can demand data locality while allowing the operational knowledge to remain concentrated in one provider’s tooling. In each case, the form of independence is present, but the substance is missing.

The better question is not, “Should we use hyperscalers or open source?” The better question is, “Where do we want dependency, and where do we want freedom?”

You will always have dependencies. The goal is not zero dependence, which is impossible. The goal is choosing dependencies that are cheap to change and hard to exploit.

That is why the most strategic open source tools are not just alternatives. They are leverage points. They make it possible to keep the center of gravity inside your own organization while borrowing commodity capabilities from the outside world. They turn infrastructure from a cage into a toolkit.

The cloud war, then, is not really about who wins the market. It is about whether software builders remember that convenience compounds just like control does. If you do not design for exit, you are designing for capture. If you do design for exit, you are not rejecting progress. You are ensuring that progress still belongs to you.

Key Takeaways

Treat lock in as a compound effect, not a single decision. Small conveniences can accumulate into strategic dependency.
Optimize for swappability in core systems. Authentication, data models, and deployment workflows should be replaceable where possible.
Use open source for composability, not just ideology. Its real value is that it lets you assemble a stack without surrendering the whole stack.
Audit three layers of dependency. Infrastructure, skills, and workflows all matter, and workflows are often the hardest to unwind.
Build for exit before you need one. Optionality is cheapest when it is part of the original architecture, not a retrofit after a crisis.

Conclusion

The most interesting thing about modern cloud concentration is that it hides inside convenience. The most interesting thing about modern open source is that it offers a way out that is not romantic, but practical. Put together, they reveal a larger principle: freedom in software is not the absence of platforms, but the presence of options.

That changes the frame entirely. The goal is not to become anti cloud or anti vendor. The goal is to ensure that no platform quietly becomes the shape of your imagination. The organizations that will thrive in the next decade are the ones that understand this early: the real battle is not for cheaper infrastructure. It is for the right to change your mind.