Containerization: Stable operation, secure scaling
Containers have long been more than just a “dev tool.” Used correctly, they accelerate deployment and changes—without compromising operations and governance. In practice, it is not the Dockerfile that determines success, but whether ownership, update discipline, and observability are established as operational standards – including clear rules for stateful services. At the same time, dependence on platform and supply chain components is becoming increasingly apparent: registry failures, provider disruptions, or compromised build and update paths are not theoretical, but real operational risks.
This is precisely why container security belongs as a baseline in architecture and operations – not as a downstream measure. Those who understand containerization as an operational concept – with versioned artifacts, clear roles, restart and recovery routines, and security baselines – gain speed without losing transparency and control. The core is an architecture that works even when teams change, services grow, and updates no longer happen “sometime” but reliably in step with operations.
Deliverability & Operations (Time-to-Change Becomes a Key Performance Indicator)
Containerization pays off in everyday life, especially in terms of predictability: deployments become repeatable, rollbacks reproducible, and environments can be operated more consistently than “hand-built” server states. This has a direct impact on throughput times, downtime, and internal coordination costs – especially where multiple services have to be rolled out together (web, worker, database, proxy, jobs).
Many teams are also currently realizing how dependent modern supply chains are on a few platform services: The Docker Hub outage on October 20, 2025 (in the context of a larger AWS outage) showed that even “just pulling images” can be a real production and delivery stopper if mirroring, caching, and emergency paths are missing.
Risk profile & dependencies (security is runtime + supply chain)
Containers are not a security problem – but they do make security assumptions visible. Anyone who containerizes cleanly must inevitably clarify: Who is allowed to do what? Which capabilities? Which network paths? Which baseline images? In the long term, this reduces the risk posed by “implicit knowledge” and historically grown rights.
At the same time, the threat situation is very concrete, especially in container ecosystems: runC vulnerabilities (container escape/breakout)were published in November 2025 – affecting the core of most container stacks (Docker/Podman/Kubernetes). This is a good example of why update capability and baselines (e.g., rootless, restrictive mounts) are relevant from a business perspective: if left unpatched, an app vulnerability can quickly become a host issue.
Trainings
Specific trainings and current topics can be found in the Comelio GmbH course catalog.
Whether in-house at your company, as a webinar, or as an open event – the formats are flexibly tailored to different requirements.
Operating model & ownership
Who operates the stack on a daily basis? Ownership is particularly crucial in containerization because platform standards (images, registries, policies) affect all teams. Clear roles are crucial: platform/ops responsibility, product teams, on-call, and a definition of what “done” means (including recovery). This is currently becoming more important because audit and verification requirements cannot be left to the discretion of individual persons.
Update & Security Capability
How can updates be reliably rolled out? This includes build and release pipelines, versioned base images, fixed patch routines, and a security baseline at runtime (e.g., minimum rights, network segmentation, policies). In practice, it often turns out that if updates are not automated and scheduled, they get postponed – and this comes back to haunt you at the latest when the next wave of vulnerabilities hits.
Integration, data & lifecycle
How clean are network paths, secrets, certificates, observability, and persistence? The lifecycle is just as important: What happens when images, frameworks, or platform components reach EOL – and how does the stack remain interchangeable? Vendor lock-in is not just about the cloud, but also about tooling: Defining standards, migration paths, and lifecycle rules early on helps avoid bottlenecks later on.
Common misconceptions
“Containers replace virtualization”
Containers solve a different problem: packaging and delivery at the process/OS level. Virtual machines continue to be useful for client separation, heterogeneous operating systems, or hard isolation. In practice, the combination is crucial – and with the current provider and lifecycle reality (LTS strategies, support windows, skill availability), the goal should always be a maintainable operating model, not a war of beliefs.
“If it runs, it’s ready for production.”
A start command is not an operating concept. Production readiness begins where restart strategies, health checks, log and metric paths, backup/restore, and incident routines are defined. Especially with recurring ransomware patterns and compromised dependencies, it is important that restart and recovery are practiced – not just documented. Without clean monitoring & logging, health checks, capacity limits, and error patterns too often remain pure guesswork.
“Security is a scanner problem.”
Image scans are important, but they are only one component. More common causes are privileges, open network paths, or missing policy standards. Modern container security is a combination of minimal images, runtime restrictions, and a traceable supply chain (including signing/SBOM approaches), as is now required or at least expected in many organizations.
“Stateful doesn’t work in containers.”
It does—if data storage, volumes, rights, and backup strategies are designed cleanly. The typical mistake is to solve persistence “on the side.” Databases and queue systems in particular need clear responsibilities and lifecycle rules, otherwise migration will be expensive later on.
Initial consultation / project initiation
If a specific stack, migration, or platform project is already on the table, a brief initial consultation helps to classify the target vision, operating model, and risks – especially before audit or program phases, in which traceability and operational readiness are examined more closely.
Frequently asked questions about containerization
This FAQ covers the topics that come up most often in consulting and training sessions. Each answer is kept brief and refers to further content where necessary. Can’t find your question? We’re happy to help you personally.
Docker or Podman – which makes more sense?
Either can be suitable. The decisive factor is not so much the tool as the operating standards: rights model, integrations (CI, registry, scanner), supportability, and team skills. A pragmatic choice often makes sense as long as artifacts remain OCI-compliant.
Compose or Kubernetes?
Compose is strong for manageable stacks on a single host and as a clean entry point. Kubernetes is worthwhile if multi-host, policies, tenant separation, and operational automation are needed at the platform level. It is important to design artifacts in such a way that a later transition does not fail due to structural errors.
How do containers become truly “secure”?
Not through a single feature, but through a bundle: minimal images, restrictive rights, clear network paths, runtime policies, and a traceable supply chain. In many environments, it is also important to embed security checks in build and release processes instead of “slapping them on” afterwards.
How do I deal with databases and other stateful services?
With explicit persistence design: volumes, rights, backup/restore, and lifecycle rules. The most common mistake is to treat persistence as a minor issue and only realize during an incident that recovery is unclear. For many teams, it is precisely this clarity that makes containerization a convincing long-term solution for operations.