I treat containerization as a tool with a cost, not a default. A container is just a Linux process with namespaces and cgroups around it, and it shares the host kernel. That one fact explains most of the cases where I'd say no. The benefits (reproducible packaging, fast startup, density, a uniform deploy artifact) have to outweigh the extra layer you now own: image builds, base-image patching, registry, runtime, networking, storage drivers and logging.

1
Kernel- or hardware-coupled workloads: anything needing custom kernel modules, a specific kernel version, DPDK or kernel-bypass networking, hard real-time guarantees, or heavy raw device access. The container cannot bring its own kernel, so you end up with --privileged and host mounts, which defeats the point.
2
Hostile multi-tenant or untrusted code: namespaces are not a security boundary equal to a hypervisor, because one kernel bug can mean escape. For running customer code I'd choose microVMs (Firecracker, Kata Containers) or a user-space kernel like gVisor, not plain Docker.
3
Stateful, I/O-sensitive systems without the operational maturity to run them: databases can run in containers, and many teams do it well. But if you have one host, bind mounts, no tested backup and restore, and no one who understands storage drivers and volume lifecycle, a managed database or a VM is safer. The risk is the operations, not the container itself.
4
Very simple deployments: a single static Go or Rust binary on a VM you already manage with systemd gets little from Docker. You add a daemon, an image pipeline and a CVE-patching burden for no real gain.
5
GUI, desktop and legacy Windows applications: Docker is built for headless Linux services. Windows containers work but are heavy, version-locked to the host OS, and poorly supported by most tooling.
6
Developer machines where file-sharing performance dominates: on Docker Desktop for macOS and Windows, containers run inside a Linux VM, and bind mounts crossing the VM boundary can make npm, Maven or Gradle workloads much slower than native.
7
Organizational constraints: no one owns image patching, no registry or scanning policy, regulated environments that mandate VM-level isolation, or Docker Desktop licensing that doesn't fit your company size.

javascript

On alternatives and trade-offs: if the real need is stronger isolation, I'd keep the container workflow but change the runtime (Kata, gVisor, Firecracker). If the need is just reproducible deploys without runtime overhead, a VM image built with Packer, or a static binary plus systemd, can be simpler. For databases I'd usually pick a managed service unless I have a platform team, tested backups and a real reason (cost, portability, data locality). I'd pick Docker back up the moment the app is stateless, has several environments or teams, or needs a consistent CI-to-prod artifact.

Common mistakes I see: treating containers as lightweight VMs and assuming VM-grade isolation; the opposite dogma that databases must never run in containers, when the real question is whether you can operate the storage; and containerizing by default, which leaves teams maintaining a Dockerfile, base-image upgrades and a registry for a service that did not need any of them.

Version-dependent points: Docker Desktop file-sharing performance has improved a lot in recent releases (VirtioFS is now the default on macOS), so older advice like 'bind mounts are unusably slow' may be outdated. Rootless mode and user-namespace remapping reduce, but do not remove, the shared-kernel risk. Docker Desktop's licensing terms (paid tier for larger companies) have also changed over time, so check current terms before standardizing on it. I'd also say that avoiding Docker is not always the same as avoiding containers, since Podman and containerd-based runtimes may fit better in some environments.

Scenario Questions

0-2 years experience

1A teammate on a MacBook says npm install and test runs are several times slower inside your Docker dev container than natively. What would you check first, and what would you change?
2You have a single static Go binary running on one VM under systemd, and a colleague wants to containerize it. What questions do you ask before agreeing?

2-5 years experience

1Your team runs PostgreSQL in a container on a single EC2 host with a bind mount. You see occasional latency spikes, and once lost data after a host reboot. How do you investigate, and would you keep it containerized?
2A vendor ships a network agent that must load a kernel module and access host devices, and product wants it deployed in your Kubernetes cluster. How do you respond?

5-8 years experience

1You are building a platform that executes customer-submitted code. Security asks whether Docker containers give enough isolation. What do you recommend and why?
2A latency-critical trading service uses CPU pinning and kernel-bypass networking, and the platform team wants it containerized as part of a migration. How do you evaluate that proposal?

8+ years experience

1Leadership mandates that every workload must run in containers within a year. How would you design the decision framework, define exemption criteria, and operate the exceptions?
2Your company has 400 developers on Docker Desktop and the licensing renewal is coming up. How would you evaluate staying, switching to alternatives, or moving to remote dev environments?

Follow-up Questions

How would you run untrusted customer workloads more safely than with default Docker containers?
If a stateful service has to run on Kubernetes, what do you put in place to make it production-safe?

Sharethis question

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.

When should we avoid containerizing an application with Docker?

Difficulty: 5/10

Containerization Trade-offs, Container Isolation and Security, Stateful Workloads in Containers

When Docker is the wrong tool: kernel coupling, isolation needs, stateful I/O, and operational cost

1
Kernel- or hardware-coupled workloads: anything needing custom kernel modules, a specific kernel version, DPDK or kernel-bypass networking, hard real-time guarantees, or heavy raw device access. The container cannot bring its own kernel, so you end up with --privileged and host mounts, which defeats the point.
2
Hostile multi-tenant or untrusted code: namespaces are not a security boundary equal to a hypervisor, because one kernel bug can mean escape. For running customer code I'd choose microVMs (Firecracker, Kata Containers) or a user-space kernel like gVisor, not plain Docker.
3
Stateful, I/O-sensitive systems without the operational maturity to run them: databases can run in containers, and many teams do it well. But if you have one host, bind mounts, no tested backup and restore, and no one who understands storage drivers and volume lifecycle, a managed database or a VM is safer. The risk is the operations, not the container itself.
4
Very simple deployments: a single static Go or Rust binary on a VM you already manage with systemd gets little from Docker. You add a daemon, an image pipeline and a CVE-patching burden for no real gain.
5
GUI, desktop and legacy Windows applications: Docker is built for headless Linux services. Windows containers work but are heavy, version-locked to the host OS, and poorly supported by most tooling.
6
Developer machines where file-sharing performance dominates: on Docker Desktop for macOS and Windows, containers run inside a Linux VM, and bind mounts crossing the VM boundary can make npm, Maven or Gradle workloads much slower than native.
7
Organizational constraints: no one owns image patching, no registry or scanning policy, regulated environments that mandate VM-level isolation, or Docker Desktop licensing that doesn't fit your company size.