Cloud platforms have radically accelerated software development. Today, teams can set up infrastructure that previously required weeks-long projects and significant investment in just hours. But with every new cloud provider integration, dependence on external service providers grows. Companies are becoming increasingly and more granularly tied to individual providers—technically, organizationally, and economically.

This shifts the actual challenge. At first, access to technologies became significantly easier. Now the focus is on maintaining the ability to act in spite of our many dependencies.

In this context, digital sovereignty doesn’t mean isolation or renunciation. It describes a company’s ability to make conscious technological decisions and, if necessary, change them without the organization failing due to existing dependencies. Three everyday situations make this especially clear.

When systems can no longer be moved

Many companies are familiar with projects that stall for months. It’s not due to lack of ideas or that teams can’t deliver, but because the existing system landscape can no longer be flexibly adapted.

New features depend on existing integrations. Changes require coordination with multiple platform teams. Security requirements must be retrofitted into complex architectures. Every step creates follow-up work elsewhere.

The result is an organization that appears technically capable but is operationally sluggish. The cause rarely lies in individual bad decisions. It arises over the years through a multitude of sensible individual decisions that have created path dependence over time and lead to an overall structure that’s difficult to change.

When Responsibility Becomes an Obstacle

A second pattern emerges in the area of security and governance. Technical decision-makers must make choices when they often can barely grasp the technical details.

As soon as new platforms or services are introduced, questions arise regarding data flows, responsibilities, and dependencies. These questions are legitimate, but in mature architectures they can often only be answered with considerable effort.

In practice, this causes a dilemma: whoever approves takes on a risk that’s difficult to assess. Whoever delays it slows down the business. The organization usually responds with extra processes and checks. This increases the coordination effort without eliminating the actual uncertainty. In any case, it costs productivity and speed—both are critical factors in digital markets.

When there are no longer any realistic alternatives

The third situation becomes clear in negotiations with vendors. Price increases or changes to contract terms can only be influenced if the company has genuine, credible alternatives at its disposal.

In many cases, these alternatives are effectively nonexistent. Applications are tightly tied to specific services. Migrations would tie up significant resources and block other projects. Switching is possible in theory, but in practice it’s too expensive, too risky, or would take too long.

The key insight is that this dependency doesn’t arise during the current negotiation. It’s created over years by the company itself and is rooted in architectural decisions, integrations, and operating models.

The underlying structural problem

These three situations share a common cause. They don’t arise from individual technologies, but from the way companies organize their technology landscape (Fig. 1).

Fig. 1: Complex, organically grown structure vs. clearly designed platform architecture

Many organizations grow into their cloud usage. New platforms are introduced on a project-by-project basis. Teams select services based on immediate needs. This results in a landscape that’s functional but lacks a clear structure.

There’s a missing layer that organizes this diversity and makes it manageable. Without this layer, tight dependencies arise between applications and infrastructure. Every change on one side has an immediate impact on the other. Centralized infrastructure control initially conflicts with the cloud-native idea of giving teams as much autonomy as possible. This tension must be resolved. That’s where Platform Engineering comes in.

Platform Engineering as a Structuring Approach

Platform Engineering introduces a deliberately designed platform layer that sits between applications and infrastructure. This platform should be built as an internal product and be operated by dedicated teams.

Its purpose is to implement recurring requirements in a standardized manner while simultaneously creating a stable framework for technology usage. This includes:

• Provisioning infrastructure via standardized interfaces
• Integrating security and compliance requirements
• Managing access and responsibilities
• Transparency regarding usage and costs

This creates a consistent working environment for developers. They no longer have to deal with individual platform details and instead, work within a prepared environment. The environment is configured and secured according to company specifications, reducing the burden on development teams. Frequently needed services like persistence, CI/CD, and monitoring can be integrated by default, significantly accelerating developers’ work.

This creates a central control point. Security, governance, and sovereignty requirements can be implemented in one place and are available to all connected applications. Development teams benefit from the fact that many “shift-left” topics are already prepared and only need to be adapted.

Why Platform Engineering Enables Sovereignty

The actual effect of platform engineering lies not in standardization itself, but in the combination of standardization and decoupling. The platform reduces the direct dependency between applications and individual infrastructure offerings. Applications primarily interact with the internal platform. This platform can integrate technologies and providers in the background.

This results in two key effects: First, speed increases. Teams can get started faster because they can rely on predefined environments tailored to their specific use case. Developers are given development environments. Data analysts are provided with a data science workbench. Coordination efforts and ramp-up time are reduced because fundamental issues are already resolved in the platform.

Second, the architecture stays flexible. New technologies can be modularly integrated into the platform and are available as alternatives without all applications needing to be adapted at once. For example, developers can choose between Kubernetes on Azure and Kubernetes on STACKIT. Teams can reduce existing dependencies over time instead of having to resolve them all at once.

This allows even complex organizations to reduce dependencies step by step. Individual teams create alternatives without having to overhaul the entire company at once.

Companies gain digital sovereignty because teams can use genuine technological alternatives. Complemented by a culture of experimentation and the courage to explore new paths, this creates a diverse yet manageable technology landscape. Now, companies have credible alternatives at the negotiating table and can, if necessary—e.g., due to geopolitical constraints—switch providers in a scalable manner. Every team is capable of taking action.

Sovereign Platform Architecture in Practice

A realistic platform architecture takes into account that companies use multiple technologies in parallel. These include hyperscalers, European cloud providers, and often their own infrastructure (see Fig. 2).

Fig. 2: Internal platforms as a decoupling layer between base platforms and applications

Kubernetes plays a central role in application development and operations. It establishes a unified runtime environment for containerized applications, reducing differences between the underlying infrastructures.

It’s important not to view Kubernetes as an isolated technology, but as an integral part of the company’s own internal platform. Consistent developer experience only emerges in combination with clearly defined processes, interfaces, and governance.

A robust developer platform across multiple clouds

A real-world example illustrates how this approach can be implemented in practice. We built a Kubernetes-based internal developer platform (IDP) that enables identical workflows on two different cloud platforms:

• Microsoft Azure as a global US hyperscaler with its Kubernetes service AKS
• STACKIT as a European provider with its Kubernetes service SKE

The platform provides the same set of features on both platforms, consisting of a few clearly defined building blocks:

• a Kubernetes-based runtime environment
• a central Git repository per application
• an integrated CI/CD pipeline
• a container registry for storing artifacts
• separate target environments for development and production

These building blocks are provided as a cohesive system. An application team receives an integration development and operations environment instead of individual resources.

Technically, this model is described entirely as code. Terraform and OpenTofu define both the infrastructure and the integrations built upon it between the repository, pipeline, registry, and Kubernetes.

This model is ported to different cloud platforms. The structure remains the same, but the specific implementation of the building blocks differs (Fig. 3).

Fig. 3: Structural design of the sovereign developer platform

Implementation on Azure

Implementing on Azure follows this model exactly and utilizes the platform’s native services:

Kubernetes runtime: Azure Kubernetes Service (AKS) provides the target environments. Isolated namespaces for development and production are created for each application. Git Repository: GitHub serves as the central source for code and deployment definitions.

• CI/CD Pipeline: GitHub Actions handles builds and deployments. The pipeline is defined directly in the repository and is deployed in a standardized manner.
• Container Registry: Container images are stored and versioned in a connected registry.
• Deployment Model: A commit in the repository triggers the build process. The generated image is pushed to the registry and then deployed to the corresponding
• Kubernetes namespace: The separation between development and production is achieved through defined target environments within the pipeline.

Individual components are directly integrated and form a continuous delivery path from code to runtime.

Implementation on STACKIT

Implementing on STACKIT follows the same structure but uses the alternative toolchain available there:

• Kubernetes runtime: The STACKIT Kubernetes Engine (SKE) provides the target environments. Isolated namespaces are created for development and production.
• Git Repository: A Git system based on Forgejo serves as the central code source.
• CI/CD Pipeline: Forgejo Actions provides the build and deployment pipeline, fulfilling the same functional role as GitHub Actions.
• Container Registry: A connected registry (Harbor) stores and versions the generated images.
• Deployment Model: The process mirrors that on Azure: code changes trigger the build, generated images are stored, and then deployed to Kubernetes. Assignment to Development or Production is determined by the respective target environment.

Here, too, a consistent delivery path emerges with identical logic, regardless of the specific tools used.

Result: same operational model, different implementation

The key point lies not in the individual technologies, but in the stable structure above them. Both platforms offer:

• the same entry point for teams
• the same workflow from development to deployment
• the same separation of Development and Production
• the same use of Kubernetes as a runtime

The differences lie exclusively in the specific implementation of the building blocks. These differences are primarily relevant for platform teams. For development teams, the workflow remains the same, even if the underlying technologies differ.

Why this creates autonomy

In the example implementation, we created a unified developer experience that enables the choice between a fully US-based or a fully EU-based stack.

This creates a consistent workflow for development teams. They don’t have to redesign their applications for each platform. At the same time, the decision regarding the underlying infrastructure remains flexible for the platform team. This makes it possible to

• integrate new platforms without modifying applications
• migrate existing workloads incrementally
• change technology decisions without interrupting operations

Sovereignty arises not from the uniformity of technologies, but from the uniformity of structure—the shared internal platform. We call this principle a sovereign internal developer platform (sovereign IDP).

This platform is based on open technologies and modular building blocks. It can be adapted to different requirements and use cases and intentionally expanded. To achieve true sovereignty, concepts alone are not enough—implementation in production is crucial.

Conclusion

A sovereign IDP restores operational flexibility. Companies can respond to changes without having to review their entire architecture every time. Application development becomes less dependent on individual infrastructure decisions. Platform teams can integrate new technologies without destabilizing existing systems. Governance requirements can be implemented consistently and in one place without slowing down projects.

Platform Engineering provides a concrete approach for this. It creates a structure that consolidates complexity, facilitates decision-making, and makes dependencies manageable. Besides faster development, companies also gain the ability to actively and independently shape their technological future.