A position paper arguing that operating-system-level containerization, of which Docker is the canonical exemplar, is not merely a useful tooling choice but a foundational technology for the convergence of operational and information technology. The argument engages directly with the strongest objections and concludes that they are tractable rather than disqualifying.
Preamble
A persistent skepticism attends the introduction of containers into industrial environments. The objections are familiar: industrial systems have lifecycles measured in decades, not deployment cycles measured in minutes; real-time performance demands cannot tolerate the unpredictability of a general-purpose runtime; the security implications of running a Linux kernel exposed to dozens of containers are insufficiently understood; the operational maturity of the operations technology (OT) workforce does not match the operational complexity of modern cloud-native tooling.
Each of these objections has a kernel of truth. None of them, this paper argues, withstands serious examination.
The thesis is direct: operating-system-level containerization — of which Docker is the canonical exemplar — is the right foundational substrate for industrial software. Its adoption is not a matter of fashion but of architectural necessity. The alternatives are worse. The objections, while real, identify engineering problems with known solutions rather than fundamental incompatibilities.
This paper proceeds in eight sections. The first establishes what Docker technically is, distinguishing the technology from the marketing surface. The second situates containers within their historical lineage to dispel the impression that this is novel and unproven technology. The third characterizes the industrial software deployment problem that containers are particularly well-suited to address. The fourth advances the affirmative case. The fifth confronts the principal objections. The sixth describes the architectural patterns that have emerged in production industrial deployments. The seventh examines open problems and the conditions for responsible adoption. The eighth restates and defends the central claim.
The intended audience is the architect or engineering leader weighing whether to commit an industrial product line to containerized infrastructure. The argument is intended to be useful precisely because it does not flatter the technology.
What Docker Actually Is
A clean argument requires a clean object. Docker is a heavily overloaded term, and substantial confusion in industrial discussions of containers traces directly to imprecision about what is being discussed.
In the strict sense, Docker refers to a particular implementation of operating-system-level virtualization on Linux, originally released in 2013 by dotCloud (later Docker, Inc.) [1]. In current practice, the term encompasses several distinguishable components: a container runtime (originally libcontainer, later containerd and runc), an image format and registry protocol, a command-line tool, and a daemon architecture.
The underlying technical primitives are kernel features, not Docker-specific inventions:
Linux namespaces [2] provide process-level isolation of system resources. The seven namespace types — PID, network, mount, UTS, IPC, user, and cgroup — collectively allow a group of processes to operate within an isolated view of process identifiers, network interfaces, filesystem mounts, hostname and domain, inter-process communication channels, user and group identifiers, and control group hierarchies. A container is, at the kernel level, a process tree whose visible system state is constrained by these namespaces.
Control groups (cgroups) [3], originally developed at Google and merged into the Linux kernel in 2007, provide resource accounting and limiting. CPU shares, memory limits, I/O bandwidth, and device access can be bounded per process group. cgroups v2, the unified hierarchy introduced in kernel 4.5 (2016) and made the default in most distributions by 2021, materially improved the resource control model.
OverlayFS [4] and similar union filesystems enable the layered image model that distinguishes Docker from earlier container systems. An image is a stack of read-only layers; a running container adds a writable layer on top. Identical layers are shared across containers and across hosts, yielding substantial storage and network efficiency.
Content-addressable storage of image layers, identified by cryptographic hash, enables a guarantee that has no equivalent in traditional deployment models: byte-for-byte reproducibility of the deployed artifact. The image identified by sha256:abc... on a developer's workstation is bit-identical to the image identified by the same hash on a production gateway, regardless of when or where it is pulled.
These primitives are not Docker's inventions. They are Linux kernel features that Docker assembled into a product. Their existence and stability long predate the popular adoption of containers, and they are now governed by an open specification.
Since 2015, the container ecosystem has been standardized under the Open Container Initiative (OCI) [5], producing three specifications: the runtime specification, the image specification, and the distribution specification. The practical consequence is that Docker the company is now one implementer among several of an open standard, and the container runtimes used in production — containerd, CRI-O, Podman — interoperate via these specifications. To "use Docker" in 2025 is to use OCI containers; the brand and the technology have decoupled.
This disambiguation matters because objections to Docker frequently address either the company, the historical daemon architecture, or peripheral tooling — rather than the underlying technical primitives, which are the durable substance of the argument.
The Historical Lineage of Containerization
Containers are not new. The popular narrative that places their origin at Docker's 2013 release obscures a four-decade lineage that materially affects how the technology should be assessed for industrial use. Mature technology with a long pedigree deserves a different evidentiary standard than emergent technology, and containers are unambiguously the former.
The lineage begins with chroot, introduced in Version 7 Unix in 1979 [6]. chroot allowed a process to be confined to a subtree of the filesystem, the first systematic filesystem-level isolation primitive in widespread use. Its security limitations were recognized early — chroot was never designed as a security boundary — but it established the conceptual foundation for filesystem virtualization.
FreeBSD Jails [7], introduced in 2000 by Poul-Henning Kamp and Robert Watson at the request of a hosting provider, extended chroot with process and network isolation, producing what was recognizably a container in the modern sense. Jails were designed as a security boundary from the outset, and have been used in production for nearly a quarter century. Their adoption in network appliances — pfSense, opnSense, NetApp — provides a long track record of containers in mission-critical roles.
Solaris Zones [8], released in 2004, provided commercial-grade containerization with strong isolation guarantees, integrated with the Solaris Service Management Facility, and used in enterprise production from launch. The Sun Microsystems engineering investment in Zones was substantial, and the technology was deployed in environments — telecommunications switches, financial transaction systems — at least as critical as typical industrial deployments.
Linux Containers (LXC) [9], emerging from approximately 2008 onward, brought container functionality to Linux through the namespaces and cgroups primitives discussed above. LXC was the direct technical antecedent of Docker; the early versions of Docker were, in effect, a developer experience layer over LXC.
Docker's contribution in 2013 was not technical novelty in the kernel sense. The namespaces had existed for years; cgroups had been merged in 2007. Docker's contribution was the image format, the registry protocol, and a developer experience that made the existing kernel primitives accessible to ordinary application developers. The technology was thirty-five years old when Docker made it usable.
Google's Borg system [10], the precursor to Kubernetes, had been running Google's entire production fleet on containers since approximately 2003 — a decade before Docker existed. By the time Docker reached version 1.0 in 2014, Google was running billions of containers per week. The argument that container technology is unproven in production at scale collides with this empirical record.
For industrial adoption, the relevant question is not whether the technology is mature — it manifestly is — but whether the industrial-specific deployment patterns are mature. That question is addressed in Section 6.
The Industrial Software Deployment Problem
To make the affirmative case for containers in industry, the problem that containers solve must be characterized precisely. Industrial software deployment has historically been afflicted by a set of pathologies that are not incidental to the industrial context but flow directly from its structural characteristics.
Long equipment lifecycles produce dependency drift. An industrial controller deployed in 2010 may still be operational in 2030 — a service life of two decades. The software environment of 2010, however, is not the software environment of 2030. Library versions, compiler toolchains, runtime interpreters, and operating system kernels all evolve. The conventional response — freeze the entire stack at deployment time — produces an unmaintainable artifact: the controller can run its original software, but cannot be safely updated, patched, or modified without risk of breaking dependencies in unpredictable ways. This is the dependency drift problem.
Heterogeneous deployment targets multiply integration complexity. A piece of industrial software may be required to run on a half-dozen target platforms: different SoC architectures, different Linux distributions, different kernel versions, different glibc versions. The combinatorics of testing every software change against every target platform are intractable without strong isolation between the application and its host environment. Without isolation, integration testing must be exhaustive; with isolation, it can be selective.
Update mechanisms have historically been brittle. The conventional industrial update — a firmware image flashed to flash storage, with rollback typically requiring physical access — does not support the granular, frequent, observable updates that modern security postures demand. Critical vulnerabilities now appear and require patching on timescales of days to weeks; industrial firmware update cycles measured in months or years are increasingly inadequate to threat models.
Reproducibility is operationally essential but technically elusive. When an industrial system fails, the diagnostic process requires reproducing the failure in a controlled environment. If the production system's software environment cannot be exactly reproduced — because it was built from a particular combination of library versions, configuration files, and runtime state that no one fully documented — diagnosis becomes archaeology. This is the reproducibility crisis applied to industrial software, and it has cost the industry dearly in incident response time.
The boundary between application and operating system has eroded. Modern industrial applications depend on a substantial slice of the operating environment: specific libraries, specific kernel modules, specific systemd units, specific filesystem layouts. The historical model — "deploy the application, the OS is someone else's problem" — does not match the operational reality, where applications and their dependencies are intertwined and must be deployed together.
Each of these pathologies is, in principle, addressable by careful engineering discipline alone. In practice, the empirical record of industrial software shows that the engineering discipline is insufficient on its own, because the pathologies are structurally produced by the gap between the application and its environment. Containers close that gap by deploying the application together with its dependencies as a single immutable artifact. This is not a stylistic preference; it is a structural remedy for a structural problem.
The Affirmative Case
With the problem characterized, the affirmative case for containers in industrial software can be made on six grounds.
Container suitability for industrial software criteria
bar chart4.1 Cryptographic Reproducibility
The image identified by a specific SHA-256 digest is bit-identical on every host that pulls it. This is a stronger guarantee than any conventional deployment mechanism provides. When an incident occurs in production, the exact software environment in which the incident occurred can be reproduced — on a developer workstation, in a test environment, in a regulatory audit — with mathematical certainty.
The diagnostic value of this guarantee is difficult to overstate. The cost of "could not reproduce" diagnoses in industrial incident response is, in the experience of every practitioner, substantial. Cryptographic reproducibility eliminates this failure mode for the software layer, leaving only the genuinely difficult-to-reproduce environmental factors — sensor noise, electromagnetic interference, mechanical wear — as the remaining sources of irreproducibility.
The same guarantee supports compliance and audit. Where an industrial deployment must demonstrate, for regulatory purposes, that the software running in the field is exactly the software that was validated and approved, the image digest provides that demonstration in a form that cryptographically resists tampering.
4.2 Atomic Deployment and Rollback
Conventional industrial updates have the property that they cannot be straightforwardly rolled back. A firmware update that proves problematic in production requires either physical access for re-flashing or a complex update mechanism that includes A/B partitions and explicit rollback support — and even these mechanisms are typically all-or-nothing at the firmware level.
Container deployment is atomic at the granularity of the individual workload. A new container image is pulled, validated, and started; the old image is stopped. If the new image fails any of its health checks, the transition is reverted. The system's state at the conclusion of a failed deployment is identical to its state at the beginning of the deployment.
This property has substantial operational consequences. It permits aggressive update cadences without proportional increases in operational risk. It permits canary deployments — testing a new image on a subset of the fleet before broader rollout. It permits automated rollback in response to telemetry signals. None of these patterns is feasible with conventional firmware update mechanisms.
4.3 Dependency Isolation
Each container carries its own dependencies. Two containers on the same host may depend on incompatible versions of the same library, and both will function correctly. The host operating system need only provide the kernel; the userspace dependencies are encapsulated in the image.
The industrial significance of this property is that an industrial gateway can host multiple applications — perhaps developed by different vendors, perhaps deployed at different times, perhaps depending on different versions of common libraries — without the integration complexity that historically attended such co-residency. The deployment of a new application does not risk breaking existing applications, because the dependencies do not interact.
This is the structural enabler of the application marketplace model that has been attempted, with limited success, for industrial controllers for several decades. Container-based application distribution makes the marketplace feasible because the integration problem — historically the principal obstacle — is mostly dissolved.
4.4 Workload Portability
A container image that runs in a developer's local environment runs, with high fidelity, on a production gateway. The same image runs on an x86 server in a data center or on an ARM-based industrial gateway, given a multi-architecture image. The execution environment is largely invariant across deployment contexts.
This portability has two important consequences for industrial software. First, it eliminates a substantial class of integration bugs — those caused by differences between development and production environments. Second, it makes the boundary between cloud and edge a deployment decision rather than an architectural decision. The same workload can run in either location, and the location can be changed without code modification. This is the practical enabler of edge-cloud co-design [11], in which workloads migrate between tiers according to operational need.
4.5 Security Improvements Over Bare-Metal Deployment
A frequent misconception treats containers as a weaker security boundary than virtual machines, and concludes that containers represent a security regression. The comparison is correct but the conclusion is wrong, because the relevant comparison is not container-vs-VM but container-vs-no-container — that is, the historical alternative to containerized industrial deployment is not virtualized deployment; it is bare-metal deployment with no isolation.
Against this historical baseline, containers are unambiguously an improvement. They provide:
NIST Special Publication 800-190 [12] provides an authoritative reference for container security configuration in regulated environments. Properly configured containers, with rootless execution, capability dropping, seccomp filtering, and image scanning, represent a substantially stronger security posture than the bare-metal industrial deployments they replace.
The legitimate concern — that the kernel is a larger attack surface than a hypervisor — applies in narrow circumstances and is addressed in Section 5.
- Process isolation via namespaces, preventing accidental or malicious interference between co-resident applications.
- Resource limits via cgroups, preventing a single application from exhausting host resources.
- Capability dropping, removing dangerous Linux capabilities from container processes by default.
- Read-only root filesystems, eliminating a major class of post-exploitation persistence.
- Seccomp filters, restricting the system calls available to a containerized process.
- AppArmor and SELinux integration, providing mandatory access controls.
4.6 Operational Convergence with Modern Software Practice
The final element of the affirmative case is perhaps the most consequential, although it is the most difficult to quantify. Containers bring industrial software into the same operational toolchain as the broader software industry. The continuous integration pipelines, the supply chain security tooling, the observability stacks, the deployment automation systems — all of them are container-native.
The implication is that industrial software development can recruit from the broader software engineering labor market, can adopt practices and tooling validated at hyperscaler scale, and can integrate with the cloud-native ecosystem without bespoke adaptation. The historical isolation of industrial software development from the broader software ecosystem — with its attendant talent shortages, tooling gaps, and security posture deficits — is dissolved by the adoption of containers.
This effect is structural and long-term. Its consequences will play out over a decade or more, but the direction of travel is clear: industrial software development is becoming indistinguishable, in tooling and practice, from modern application development.
Confronting the Objections
A serious advocacy must engage with the strongest forms of the objections it confronts, not the weakest. This section addresses the four objections most frequently raised against industrial containerization.
5.1 The Real-Time Performance Objection
Containers introduce non-deterministic scheduling and resource contention that disqualifies them from real-time industrial workloads.
The objection has merit in its strongest form, but the form in which it is usually made is too sweeping. Real-time industrial workloads are not monolithic; they range from hard real-time motion control (deadlines in microseconds, missed deadline equals safety incident) to soft real-time process control (deadlines in tens of milliseconds, occasional misses tolerable) to non-real-time analytics (no deadline).
For hard real-time workloads, containers are indeed unsuitable — but so is conventional Linux. Hard real-time on Linux requires a kernel patched with PREEMPT_RT [13] or equivalent, careful CPU affinity, isolation of real-time cores from the scheduler, and exclusion of non-real-time workloads from the real-time domain. These requirements are independent of containerization. A properly configured real-time Linux system can host real-time workloads in containers with full real-time guarantees, provided the configuration discipline is observed.
Quantitative measurements substantiate this. Benchmarks of containerized real-time workloads on PREEMPT_RT Linux [14] show latency overhead in the low single microseconds versus bare-metal execution — well within the tolerance of even demanding industrial workloads. The overhead is largely from cgroup accounting, which can be selectively disabled for real-time cgroups where deterministic latency is more important than fine-grained resource accounting.
For soft real-time and non-real-time workloads — which encompass the vast majority of industrial software — containers introduce overhead on the order of 1-3% for CPU-bound workloads and statistically negligible overhead for I/O-bound workloads. This is not a serious obstacle.
5.2 The Security Boundary Objection
Container escape vulnerabilities are routinely discovered; containers cannot be trusted as a security boundary for high-value industrial workloads.
The objection conflates two distinct claims. The first — that container escape vulnerabilities exist — is true. The second — that this disqualifies containers from industrial use — does not follow, because virtual machine escapes also exist, and bare-metal deployments have no boundary to escape at all. The relevant question is the security posture relative to alternatives, not relative to perfection.
The historical record of container escape vulnerabilities is informative. The major CVEs — runc CVE-2019-5736, Dirty Pipe CVE-2022-0847, CVE-2024-0132 in NVIDIA Container Toolkit — have, in each case, been patched within days of disclosure and propagated through the ecosystem within weeks. The exposure window for properly maintained systems has been short.
For workloads requiring hypervisor-grade isolation, lightweight VM-based container runtimes — Kata Containers [15], Firecracker [16], gVisor [17] — provide it while preserving the container interface. These technologies enable a hybrid deployment in which most workloads run in conventional containers while specifically sensitive workloads run in microVMs, all managed by the same orchestration layer.
The serious security challenge for industrial containerization is not the kernel attack surface; it is the supply chain. A container image built from untrusted base images, from packages pulled from compromised repositories, from build pipelines without provenance, is a vector for compromise that container isolation will not address. The response to this challenge — addressed in Section 6 — is the adoption of supply chain security frameworks such as SLSA [18] and signed image distribution via Sigstore [19].
5.3 The Stateful Workload Objection
Containers were designed for stateless workloads. Industrial applications are deeply stateful, and forcing them into a stateless model produces bad architectures.
The premise is partially correct — early container guidance did emphasize statelessness — but the conclusion is not. The container model accommodates stateful workloads through volume mounts, persistent volumes in orchestrated environments, and explicit data management primitives. The discipline required is to make state externally addressable and explicitly managed, rather than implicit in the application's runtime memory.
This discipline is, in fact, a benefit for industrial applications, not a cost. A stateful industrial application whose state is implicit, undocumented, and entangled with runtime memory is precisely the kind of application that is impossible to debug, impossible to migrate, and impossible to recover after failure. The containerization process forces the externalization and explicit management of state — producing applications that are more resilient, not less.
For genuinely stateful industrial workloads — historian databases, calibration data, configuration stores — the container ecosystem provides mature tooling: persistent volumes with appropriate filesystem backing, operator patterns for managing database lifecycles, and backup primitives integrated with the storage layer.
5.4 The Operational Complexity Objection
Container orchestration introduces operational complexity that OT teams are not prepared to manage. The alternative — simple firmware updates — is operationally simpler, even if technically inferior.
The objection has substantial empirical support. Kubernetes is widely regarded as operationally complex, and the skills required to operate it are not commonly resident in OT teams.
However, two observations qualify the objection. First, container deployment does not require Kubernetes. For single-node industrial deployments — which describe the vast majority of edge gateway scenarios — Docker Compose, Podman, or systemd-managed container units provide an operational surface that is comparable in complexity to conventional service management. The full orchestration stack is needed only for fleet-scale deployments, and at that scale the orchestration complexity is offset by the operational benefits.
Second, lightweight orchestration — K3s [20], KubeEdge [21], MicroK8s — has materially reduced the operational complexity for fleet-scale edge deployments. The historical Kubernetes complexity profile reflected its origins in hyperscaler workloads; the lightweight variants are explicitly designed for the operational realities of edge deployment.
The deeper response to the operational complexity objection is that the operational complexity of non-containerized industrial software has been understated for decades. The undocumented dependencies, the irreproducible incidents, the deployment processes that exist only as tribal knowledge in particular engineers' heads — these are forms of operational complexity that are not measured because they are not visible. The visible complexity of container orchestration replaces invisible complexity that was always present. Whether this is a net increase or decrease in operational burden depends on the specific deployment, but the assumption that the non-containerized baseline is operationally simple does not survive scrutiny.
Architectural Patterns for Industrial Deployment
The transition from theoretical defensibility to deployable practice depends on the maturity of the architectural patterns. The patterns that have emerged in production industrial deployments warrant explicit description.
6.1 Single-Node Gateway Deployment
The most common pattern is the single-node gateway: an industrial gateway running a small number of containerized applications, with Docker Compose or systemd-managed container units providing the orchestration surface. Updates are pulled from a central registry, optionally on a schedule defined by a Watchtower-like reconciliation loop. State is persisted to local volumes with backup to central infrastructure.
This pattern's strength is operational simplicity. Its weakness is that fleet-scale management is not directly supported — each gateway is independently managed. For deployments of tens to low hundreds of gateways, this is acceptable. For larger fleets, the next pattern is more appropriate.
6.2 Fleet-Scale Orchestration
For fleet-scale deployments, lightweight Kubernetes distributions (K3s, KubeEdge) provide orchestration across the fleet. Each gateway becomes a node — either as a single-node cluster or as a worker node in a larger cluster — and workloads are scheduled, updated, and observed via standard Kubernetes tooling.
The pattern's strength is fleet-scale management with a mature ecosystem. Its weakness is the operational complexity discussed in Section 5.4, which justifies the pattern only at sufficient scale.
6.3 GitOps for Edge Configuration
In either pattern, the configuration of the gateways — what containers run, what images are deployed, what resources are allocated — is described declaratively in a version-controlled repository. A reconciliation controller (Flux, Argo CD, Fleet) running on the gateway, or on a controller in the cloud, observes the gap between observed and desired state and applies the changes required to close it.
This pattern's strength is auditability and atomicity at the fleet level. The full history of fleet configuration is captured in Git. Rollback is a Git operation. The pattern has been borrowed nearly without modification from cloud-native operations and translates well to the edge.
6.4 Supply Chain Security
For industrial deployments, the supply chain security of container images is operationally essential. The mature pattern includes:
This is not optional for industrial deployments. The supply chain attacks that have occurred against software packaging ecosystems over the past five years — SolarWinds, the various npm and PyPI compromises — establish that the threat is real and the defenses are necessary.
- Image building in trusted CI infrastructure with documented provenance (SLSA framework [18])
- Image signing with Sigstore [19] or equivalent
- Provenance attestation following the in-toto specification [22]
- Software bill of materials generation following SPDX [23] or CycloneDX
- Continuous vulnerability scanning with Trivy, Grype, or commercial equivalents
- Admission control at the gateway level that refuses unsigned or vulnerable images
6.5 Hardware Access Patterns
Industrial workloads frequently require access to physical hardware: serial ports, GPIO pins, CAN buses, industrial fieldbuses, GPU accelerators. The container model accommodates this through device cgroups and explicit device mounts.
The disciplined pattern is to expose specific devices to specific containers rather than running privileged containers with full host access. The kernel's device cgroup controller permits fine-grained access control. udev rules can map physical devices to stable names that containers reference. For GPU access, the NVIDIA Container Toolkit and equivalent provide hardware access without privilege escalation.
6.6 Real-Time Augmentation
For deployments with real-time requirements, the pattern combines a PREEMPT_RT kernel, CPU isolation via isolcpus boot parameter, dedicated real-time cgroups, and careful workload placement. The container interface is preserved, but the underlying scheduler is configured for real-time workloads.
This is engineering work, not a feature flag, but it is well-documented engineering work [13][14] that delivers latency profiles meeting the requirements of all but the most demanding hard real-time workloads.
Open Problems and Responsible Adoption
The case for industrial containerization is strong but not unqualified. Several open problems warrant explicit acknowledgment.
Image size discipline. Container images frequently grow to gigabytes through accumulated dependencies, debug tooling, and base image bloat. For bandwidth-constrained industrial deployments — where image pulls occur over cellular or satellite links — this is operationally costly. Disciplined practices (distroless base images [24], multi-stage builds, careful dependency management) keep production images under 100 MB for most workloads, but the discipline is not automatic.
Skills development. The container ecosystem assumes a level of operational sophistication that is not uniformly present in industrial engineering teams. Closing this gap requires explicit investment in training, in tooling that reduces the operational surface, and in patterns that allow OT teams to operate container infrastructure without becoming Kubernetes specialists.
Observability at fleet scale. Telemetry from a thousand containerized gateways generates telemetry of its own. Selecting which metrics to emit, at what granularity, and how to aggregate them is an unsolved engineering problem at the edge. OpenTelemetry [25] has improved the situation, but edge-specific patterns remain underdeveloped.
Long-term image preservation. A container image deployed today must remain runnable on hardware deployed today, fifteen years from now, after the registry that originally hosted the image has changed ownership or ceased to exist. Industrial deployments require explicit image preservation — local registries, archived images, documented dependencies — that is not the default operational mode of the broader container ecosystem.
Hardware abstraction limits. Some industrial hardware — particularly FPGAs, specialized I/O cards, and hardware with proprietary kernel drivers — does not abstract cleanly into the container model. For these workloads, containerization is partial: the userspace component is containerized while the kernel driver remains a host-level concern. This is acceptable but introduces a coupling that disciplined deployment must explicitly manage.
These problems are real and require ongoing engineering investment. They do not invalidate the affirmative case; they qualify it.
Concluding Argument
The argument may be stated compactly. Industrial software has historically suffered from a structural problem: the gap between application and operating environment is uncontrolled, producing dependency drift, reproducibility failures, deployment brittleness, and security postures that are difficult to defend. Containers close this gap by deploying the application together with its dependencies as a cryptographically reproducible, atomically updatable, isolatable artifact. The technology is four decades old in its conceptual foundations, governed by open standards, and operationally validated at hyperscaler scale. The objections raised against industrial adoption are real but tractable — they identify engineering problems with known solutions, not structural incompatibilities.
The structural alternative to containerization is the continuation of historical practice: bespoke deployment per platform, irreproducible production environments, brittle update mechanisms, and operational isolation from the broader software ecosystem. This alternative is not a stable equilibrium. It is the status quo whose limitations are now sufficiently visible that the industry is moving away from it, and the question is not whether to adopt containers but how to adopt them well.
The recommendation that follows is direct. Industrial product lines should be designed for containerized deployment from the outset. The investments required — in supply chain security, in observability tooling, in skills development, in image preservation discipline — should be planned and budgeted explicitly. The patterns described in Section 6 should be adopted, adapted, and evolved as the practice matures.
The alternative is to remain in an architectural regime that has outlived its viability. The transition will not be costless. It will be substantially less costly than not making it.
References
[1] S. Hykes. "The future of Linux Containers." PyCon US, 2013.
[2] E. W. Biederman. "Multiple Instances of the Global Linux Namespaces." Linux Symposium, 2006.
[3] P. B. Menage. "Adding Generic Process Containers to the Linux Kernel." Linux Symposium, 2007.
[4] N. Brown. "Overlay Filesystem." Linux kernel documentation, 2014.
[5] Open Container Initiative. Runtime Specification, Image Specification, and Distribution Specification. 2017–present. https://opencontainers.org
[6] D. M. Ritchie and K. Thompson. Unix Programmer's Manual, Seventh Edition. Bell Laboratories, 1979.
[7] P.-H. Kamp and R. N. M. Watson. "Jails: Confining the Omnipotent Root." Second International SANE Conference, 2000.
[8] D. Price and A. Tucker. "Solaris Zones: Operating System Support for Consolidating Commercial Workloads." USENIX LISA, 2004.
[9] D. Lezcano et al. Linux Containers (LXC) Project. 2008–present. https://linuxcontainers.org
[10] A. Verma et al. "Large-scale Cluster Management at Google with Borg." EuroSys, 2015.
[11] B. Burns et al. "Borg, Omega, and Kubernetes." Communications of the ACM, 59(5), 2016.
[12] National Institute of Standards and Technology. Application Container Security Guide. NIST Special Publication 800-190, 2017.
[13] T. Gleixner and I. Molnar. PREEMPT_RT: Real-Time Preemption Patches for the Linux Kernel. https://wiki.linuxfoundation.org/realtime/
[14] L. Abeni et al. "Container-Based Real-Time Scheduling in the Linux Kernel." ACM SIGBED Review, 16(3), 2019.
[15] Kata Containers Project. Kata Containers: The Speed of Containers, the Security of VMs. https://katacontainers.io
[16] A. Agache et al. "Firecracker: Lightweight Virtualization for Serverless Applications." USENIX NSDI, 2020.
[17] gVisor Project. gVisor: Application Kernel for Containers. Google, 2018. https://gvisor.dev
[18] Google et al. Supply-chain Levels for Software Artifacts (SLSA). Open Source Security Foundation, 2021–present. https://slsa.dev
[19] Linux Foundation. Sigstore: Software Signing for Everybody. https://sigstore.dev
[20] Rancher Labs / SUSE. K3s: Lightweight Kubernetes. https://k3s.io
[21] CNCF. KubeEdge: A Kubernetes-Native Edge Computing Framework. https://kubeedge.io
[22] S. Torres-Arias et al. "in-toto: Providing Farm-to-Table Guarantees for Bits and Bytes." USENIX Security, 2019.
[23] Linux Foundation. Software Package Data Exchange (SPDX) Specification. ISO/IEC 5962:2021.
[24] Google. Distroless Container Images. https://github.com/GoogleContainerTools/distroless
[25] OpenTelemetry Project. OpenTelemetry Specification. CNCF, 2019–present. https://opentelemetry.io
[26] C. Fowler. "Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components." 2013.
[27] J. Cappos et al. "Survivable Key Compromise in Software Update Systems." ACM CCS, 2010. (The Update Framework / TUF.)
[28] International Electrotechnical Commission. IEC 62443-4-1: Secure Product Development Lifecycle Requirements. 2018.
[29] B. Cantrill and J. Bonwick. "Real-World Concurrency." Communications of the ACM, 51(11), 2008.
[30] M. Souppaya, J. Morello, and K. Scarfone. NIST SP 800-204C: Implementation of DevSecOps for a Microservices-based Application with Service Mesh. 2022.
This article is part of the Modibus technical series. The Modibus MB213 industrial gateway is engineered as a first-class containerized computing platform, supporting Docker, Podman, and lightweight Kubernetes distributions out of the box, with hardware acceleration accessible to containerized workloads via the patterns described in Section 6. For technical discussion or platform inquiries, contact [info@modibus.com](mailto:info@modibus.com).