Build or Buy Kubernetes? Part 3

Managed Kubernetes is Not the Same as Managed Platform: How Companies Remain Sovereign in the Long Term

Part 3 of our series “Build or Buy Kubernetes”

In the first two parts of this series, we examined why the introduction of Kubernetes is much more than an infrastructure decision and why the actual costs of a platform rarely appear on the cloud bill. This leaves one crucial question unanswered: Which operational model is the right one in the long run?

The discussion is often reduced to three options: operating Kubernetes yourself, using a managed Kubernetes offering from a hyperscaler, or hiring a specialized service provider. This classification initially seems plausible but obscures a significant difference.

Not every managed Kubernetes platform also takes over the operation of the platform.

There are significant organizational and economic differences between a managed control plane and a fully operated platform.

Kubernetes is Just One Component of an Operations Platform

The term Managed Kubernetes suggests that a company no longer needs to worry about operations after providing a cluster. In reality, the term in most offerings refers to a very narrowly defined area of responsibility.

Typically, the provider operates the control plane, ensures its high availability, and provides new Kubernetes versions. From the cloud provider’s perspective, responsibility often ends here.

The actual platform begins beyond this point.

Who is responsible for the network architecture? What security policies apply to deployments? How are Container images signed and checked for vulnerabilities? Who develops backup and restore strategies? How are monitoring, alerting, and incident response organized? What processes ensure that regulatory requirements are consistently met? And who assists development teams in using this platform efficiently?

These questions cannot be answered by an API endpoint.

They are expressions of operational responsibility.

For this reason, it makes sense to distinguish between Managed Kubernetes and Managed Platform. While the former primarily focuses on the technical operation of a cluster, the latter encompasses all organizational and operational processes required to provide software reliably, securely, and economically.

The Shared Responsibility Model Does Not End with Kubernetes

Cloud providers have been talking about the so-called Shared Responsibility Model for many years. The term describes the division of responsibilities between infrastructure operators and customers.

This model applies without exception to Kubernetes as well.

A managed service reduces the effort for certain infrastructure components but does not absolve companies of their responsibility for architectural decisions, security policies, deployment processes, or Compliance.

This difference is often underestimated, especially in regulated industries.

A provider can offer a highly available Kubernetes control plane and still make no statement about whether the applications running on it meet the requirements of NIS2, DORA, or the Cyber Resilience Act. Nor can they assess whether backup concepts are regularly tested, identity concepts meet internal security policies, or recovery processes work under realistic conditions.

Compliance does not arise from infrastructure.

Compliance arises from processes.

And processes remain the responsibility of the company, regardless of the chosen operational model.

Platform Operation is a Service, Not Software

Many companies still view platforms as a technical product. In reality, they are a continuous service.

A platform is never “finished.” It is constantly changing.

New Kubernetes versions are released several times a year. APIs are deprecated, security vulnerabilities are published, regulatory requirements are expanded, and development tools are continuously adjusted. At the same time, the requirements of one’s own development teams change. New frameworks emerge, software architectures evolve, and business models grow.

A platform must be able to respond to all these changes without losing its stability.

This is precisely why professional platform operation consists significantly of recurring activities that are barely visible in classic economic considerations: architecture reviews, maintenance planning, capacity analyses, restore tests, security assessments, incident follow-ups, documentation, and continuous standardization.

These tasks do not create immediately visible added value. Instead, they prevent technical debt from accumulating unnoticed over the years.

Experienced platform teams therefore invest a significant portion of their time not in new technologies but in reducing future complexity.

The Biggest Mistake in Outsourcing is the Loss of Knowledge

When companies transfer platform operation to an external partner, a legitimate concern often arises.

Do we lose our independence as a result?

This question is legitimate. However, it is often answered in the wrong place.

Dependence does not arise from an external service provider taking over operational tasks.

Dependence arises where knowledge is lost.

If architectural decisions are understood solely by the service provider, operational processes are undocumented, or internal teams have no opportunity to understand and further develop the platform, a significant risk indeed arises.

However, this risk has nothing to do with managed services.

It is the result of poor collaboration.

A professional platform partner should therefore never attempt to withhold knowledge. On the contrary: their interest must be to document architectural decisions transparently, use open standards, design operational processes transparently, and continuously build internal know-how.

This attitude may seem contradictory at first glance.

Why should a service provider make their customers more independent?

Because sustainable partnerships are not based on information asymmetries but on trust and demonstrable competence. Companies rarely switch providers today because they suddenly possess more knowledge. They switch when transparency is lacking or when the feeling arises that they have lost control over their own platform.

Open Standards are More Than a Technical Detail

In the context of vendor lock-in, discussions often focus solely on proprietary APIs or cloud services.

This perspective is too narrow.

Dependencies also arise from proprietary operational processes, individual automation, or lack of documentation. Even a platform entirely based on open-source components can be practically unportable if no one can trace how it was built.

Digital sovereignty therefore does not begin with the selection of a Kubernetes distribution.

It begins with the consistent use of open standards, reproducible infrastructure definitions, and transparent operational processes.

GitOps, Infrastructure as Code, declarative configurations, standardized APIs, and traceable documentation are therefore much more than modern development methods. They form the foundation for platforms to remain portable and independent in the long term.

The crucial question is not whether a company hires a service provider.

The crucial question is whether it could continue to develop its platform without this service provider.

If this question can be answered with yes, true sovereignty is achieved.

Build and Buy Are Not Mutually Exclusive

The discussion around Build or Buy often gives the impression that companies must choose exactly one path.

In practice, the situation is much more nuanced.

Many successful organizations today pursue hybrid models.

Strategic architectural decisions, governance, and platform strategy consciously remain within the company. Operational activities such as cluster operation, monitoring, backup management, security patching, or 24/7 on-call duties, on the other hand, are transferred to specialized platform teams.

This division of labor follows a simple economic principle.

Companies should build their own knowledge where it creates a sustainable competitive advantage. Activities that are business-critical but not differentiating often benefit from specialization, standardization, and economies of scale.

Platform operation falls into this category in many organizations.

It is indispensable.

However, it rarely creates the actual corporate value.

Conclusion

The question of Build or Buy Kubernetes cannot be answered universally. It depends on regulatory requirements, company size, existing competencies, and the strategic goals of an organization.

However, one insight can be derived from almost every successful platform project.

It is not the cluster that determines the long-term success of a Kubernetes strategy, but the quality of the operational organization.

Managed Kubernetes reduces infrastructure effort. Managed Platform reduces organizational complexity. Both can be sensible—provided companies understand the difference and make their decision consciously.

At the same time, every platform strategy should be aimed at strengthening its own ability to act. Open standards, transparent processes, documented architectural decisions, and continuous knowledge transfer are not optional comfort features. They are prerequisites for platforms to remain manageable even in five or ten years.

In the end, it is not about whether infrastructure is operated or purchased.

It is about taking responsibility where it creates strategic added value and delegating it where specialization leads to more quality, higher security, and greater economic efficiency.

Final Thoughts

The introduction of a Kubernetes platform is one of the most far-reaching infrastructure decisions a company can make today. It influences architecture, organization, development processes, and not least the economic performance of the entire software development.

For this reason, it is worth not viewing this decision in isolation from the perspective of a single technology. Often, it becomes apparent in a joint architecture discussion that the real challenge lies less in the Kubernetes cluster itself and more in questions of governance, platform operation, or organizational alignment.

If you are facing the decision to build a Kubernetes platform, question existing operational models, or objectively evaluate the economic efficiency of your platform strategy, talk to us. We have been supporting companies for many years in building, operating, and further developing production-critical Kubernetes platforms—regardless of whether they are in the public cloud, on European infrastructure, or in