Blogs

Containerization has long since moved beyond its niche and become a core component of modern digital infrastructure. But whenever something moves from the margins into the mainstream, it often creates anxiety. Or, in the context of IT, skepticism and reservations.

And those concerns are often understandable. Containerization does not only change how applications are deployed. It also affects operational processes, responsibilities, roles, and sometimes even the strategic direction of an organization's IT landscape. Any significant change creates uncertainty, resistance, and concerns, especially when the situation is unclear, the future uncertain, and communication confusing.

That is precisely why it makes sense to take a sober look at the most common objections. Not to dismiss every concern or declare containerization the solution for everyone, everything, and forever. That would not be helpful. Instead, the goal is to make informed decisions, identify real challenges, uncover misunderstandings, and ultimately understand which problems containerization can actually solve.

Containerization Makes Everything More Complex

Containerization inevitably introduces a certain degree of complexity. Regardless of the platform or tooling involved, container images must be built, versioned, and distributed. Applications require clearly defined runtime environments, updates need to be managed in a controlled manner, and vulnerabilities in images and dependencies must be monitored. Monitoring, logging, backup strategies, networking, and access management all remain necessary. Without addressing these aspects, containerization cannot be operated professionally in production environments. The same is true for virtualized workloads.

Kubernetes also introduces a new vocabulary. Instead of servers, there are nodes. Instead of reverse proxies and load balancers, there are ingress controllers. This can feel intimidating and make the transition appear like a complete restart. However, many operational responsibilities remain exactly the same. Applications still need to be deployed, monitored, updated, and secured. Access controls, configurations, networking, and responsibilities still need to be managed. Containerization does not eliminate these topics; it moves them into a more standardized and automatable operating model. The transition is therefore not trivial, but neither is it starting from scratch. Existing operational expertise remains valuable and simply needs to be translated into a new framework.

So what does this complexity mean in practice? If you are operating a small application on a single virtual machine, rarely updating it and having no significant requirements around scaling or automation, containerization may offer limited benefits. In such cases, a more sophisticated technology stack can introduce more effort than value.

However, as the number of applications, teams, and environments grows, managing different configurations and deployment approaches becomes increasingly difficult. This is where containerization becomes attractive. The question is no longer whether containerization adds complexity. Instead, it becomes a way to make existing complexity more manageable.

Containerization is therefore not an automatic cost-saving measure. It initially requires investments in platforms, operations, and expertise. Cost benefits only emerge when standardization and automation outweigh those investments.

We Will Lose Control Over Our Infrastructure

This concern comes in several forms. The first is the feeling of losing operational control. Rather than knowing exactly which server an application runs on and how it is configured, teams interact with an abstraction layer. Containers are restarted, moved to different hosts, and managed by the platform itself. This can create the impression that the platform controls the application rather than the other way around. To a certain extent, this perception is correct. Declarative platforms such as Kubernetes are specifically designed to rely on automation instead of manual intervention.

Another concern is the loss of familiar structures. Administrators who previously managed virtual machines may suddenly have to work with Helm charts, container registries, and entirely new workflows. This transition is significant and should not be underestimated. The appropriate response is not to dismiss the concern but to support teams through training, structured migration strategies, and hybrid operating models that allow existing VM environments to continue operating while new skills and processes are gradually introduced.

A third concern revolves around dependency on Kubernetes itself. However, containerization is much broader than Kubernetes. More importantly, the concern about dependency is often less straightforward than it appears. Every organization depends on technology providers in some form, whether that is VMware, a hyperscaler, or Kubernetes. The real difference lies in the type of dependency. Many platforms tie customers to a specific vendor, licensing model, and product roadmap. Kubernetes, in contrast, is based on open standards and supported by a large open-source ecosystem. Organizations can choose between multiple distributions, service providers, or even operate upstream Kubernetes independently.

The more honest answer is therefore: Yes, Kubernetes creates dependencies. But many organizations prefer depending on an open ecosystem rather than on a single vendor. Looking beyond that, containerization can reduce dependencies that were previously taken for granted. Applications that run independently of a specific infrastructure create new options. They can run in an on-premises data center, a private cloud, a public cloud, or hybrid environments while maintaining a largely consistent operational model. This becomes particularly relevant in multi-cloud strategies, cloud-exit scenarios, and regulated industries. Digital sovereignty is not achieved by avoiding modern technology. It is achieved by keeping future options open.

Containers Are Insecure

Security is often cited as a weakness of containerization. In practice, the reality is usually different. Containerization does not necessarily make systems less secure. It makes security issues more visible.

Dependencies, images, and software versions must be managed explicitly in containerized environments. This may initially feel unfamiliar because many of these aspects remain hidden in traditional environments. Furthermore, many security risks are not unique to containers. While container platforms introduce additional attack surfaces and configuration requirements that must be managed professionally, many vulnerabilities result from uncontrolled software sources, missing updates, or weak operational processes. The same issues would also be security problems in VM-based environments.

The difference is that modern platforms make many of these aspects easier to standardize, automate, and audit. Security scans, reproducible deployments, and controlled software supply chains are often easier to implement than in highly customized infrastructures. Containerization does not eliminate security challenges. It makes managing them more systematic. Whether this advantage outweighs the additional operational complexity depends on the specific use case. Blanket statements that containers are inherently insecure simply do not reflect reality.

Our Legacy Applications Do Not Fit into Containers

Many organizations automatically associate containerization with a complete application modernization initiative. This often leads to the assumption that everything must be rewritten first. In reality, modernization projects are usually far less dramatic. Existing applications continue running while the operating model is modernized first. Technical changes often come later. This makes containerization a tool for gradual transformation rather than radical change. A common example is an internal business application that has been running reliably on a virtual machine for years. The application itself still fulfills its purpose. The actual challenge often lies in operations. Updates are applied manually, environments differ from one another, and documentation has gradually become outdated.

In situations like this, a complete redevelopment may not be necessary. In suitable cases, containerizing the application and integrating it into standardized operational processes can be sufficient. Further modernization can then happen step by step without disrupting ongoing operations. Of course, not every legacy application can be containerized immediately. Applications with strong dependencies on specific hardware, proprietary operating system components, or outdated runtime environments may still pose challenges. Nevertheless, far more applications can be integrated successfully than many organizations initially assume.

Kubernetes Is Just Another Trend That Will Eventually Disappear

The skepticism is understandable. The technology industry has seen countless trends arrive with great promises only to fade away later. However, there are strong reasons to view Kubernetes differently. Kubernetes is not controlled by a single vendor. It is developed by one of the largest open-source communities in the technology industry. Its future is therefore not tied to the strategy of a single company. At the same time, numerous platform vendors, cloud providers, and infrastructure solutions are built on the same foundation. This alone makes it highly likely that Kubernetes will remain relevant for years to come.

Another strong indicator is the maturity of the ecosystem. Many technology trends disappear before a sustainable ecosystem emerges. Around Kubernetes, there are now extensive solutions for security, monitoring, logging, storage, software supply chains, platform operations, training, certifications, and managed services. Such breadth rarely develops around short-lived trends. It usually emerges around technologies that establish themselves as foundational infrastructure. This does not mean every organization should immediately adopt Kubernetes. Simpler operating models may remain perfectly adequate for small and stable workloads.

The real question is not whether Kubernetes is a trend. The real question is whether your future requirements increasingly point toward automation, standardization, hybrid operating models, and reproducible infrastructure. For these challenges, Kubernetes has already established itself as a durable and widely adopted operating model.

The Real Question

Perhaps this is where most discussions ultimately lead. Containerization is often treated as a technology decision and therefore given more weight than necessary. The most important question is usually not:

“Should we containerize?”

Instead, it is:

“Which problem would containerization actually solve for us?”

Organizations that aim for standardized platforms, hybrid infrastructure models, digital sovereignty, and reduced vendor dependency will almost inevitably encounter containerization. Not because it is a silver bullet, but because it often provides the practical foundation needed to achieve these goals. At the same time, it remains entirely reasonable to continue using simpler operating models for small and stable workloads. Fear of containerization rarely disappears because of technical arguments alone. It disappears when organizations clearly understand which problems containerization can solve, which it cannot, and where it genuinely creates value. Containerization is neither a goal in itself nor a passing trend. It is a powerful tool that should be applied where it delivers the greatest benefit.