When Should You Use Docker? A Practical Guide to Containers, VMs, and Orchestration

The article, originally presented in the DBAplus community, examines the decision‑making process for using Docker containers versus traditional virtual machines, emphasizing how company size, workload characteristics, cloud strategy, and DevOps practices influence the choice.

When to Use Docker

Docker is beneficial when applications are high‑concurrency, frequently updated, or need to be split into independent micro‑services. Traditional, low‑update, single‑process applications (e.g., slow‑starting legacy services) often do not justify containerization.

When to Consider Containers

Rapidly changing business logic or traffic spikes.

Micro‑service architectures requiring many small, independently deployable units.

Need for consistent environments across development, testing, and production.

Desire to shift configuration management from operations to developers (DevOps).

Organizational Impact

Adopting containers reduces operational workload (≈200% less effort) while adding only ~5% extra work for developers. However, this shift requires cultural changes, clear responsibility boundaries, and a DevOps mindset.

Deployment Modes

Mode 1: Public‑Cloud Virtual Machines

Best for early‑stage startups with limited IT staff and no strict security requirements.

Outsource low‑level resource management to the cloud provider.

Deploy a small number of VMs (≤20) using simple scripts or Ansible.

Pay‑as‑you‑go pricing supports rapid scaling.

Mode 2: Bare Containers without IaaS

Suitable for startups that need on‑premises deployment for compliance or security reasons but lack a full IaaS platform.

Replace manual or simple script deployments with docker run commands.

Achieve port and configuration isolation.

Leverage container images to standardize OS and package dependencies.

Mode 3: Bare Containers with IaaS

Targeted at larger companies that already own IaaS and run innovation projects requiring fast iteration.

Develop Dockerfiles to embed runtime environments, reducing the need for operations to manage configurations.

Enable rapid roll‑backs and consistent environments across dev/test/prod.

Mode 4: Docker Swarm Mode

Appropriate for mid‑size clusters (≈50‑200 nodes) where a lightweight orchestration solution is desired.

No external services like Zookeeper or etcd required.

Built‑in service discovery, DNS, and overlay networking.

CLI compatible with Docker commands.

Mode 5: Marathon and Mesos

Designed for large clusters (hundreds of nodes) needing custom scheduling and high scalability.

Two‑level scheduler: resource allocation at the Master, then per‑Framework scheduling.

Allows multiple frameworks (e.g., multiple Marathon instances) to coexist without conflict.

Highly extensible for bespoke modules.

Mode 6: Open‑Source Kubernetes

Fits thousand‑node clusters where modularity and ecosystem support are priorities.

Fine‑grained resource objects: Pods, Deployments, Services, ConfigMaps, etc.

Rich ecosystem (network plugins, storage drivers, monitoring).

Steeper learning curve due to many concepts.

Mode 7: Advanced Kubernetes Usage

Addresses scaling challenges for very large clusters.

APIServer pressure mitigated by watch‑cache and sharding.

Scheduler optimizations: pre‑filtering nodes, custom predicates.

Controller improvements: prioritized event queues (ADD > UPDATE > DELETE > SYNC) to reduce latency.

Mode 8: Advanced DC/OS

Extends Marathon/Mesos with additional components (e.g., API gateway, service discovery, CNI plugins) to approach Kubernetes functionality while retaining Mesos’ scalability.

Mode 9: Big‑Data Platforms – Kubernetes vs. Mesos

Mesos can run Spark in coarse‑grained or fine‑grained modes; fine‑grained offers better resource utilization but may suffer performance penalties. Kubernetes treats containers as resource placeholders, typically using a coarse‑grained approach for big‑data workloads.

Mode 10: Hybrid Container & VM Deployment

For large, non‑internet enterprises transitioning gradually to containers.

Run containers inside VMs to avoid double‑virtualization overhead.

Use networking plugins (Flannel, Calico) only for bare‑metal containers; otherwise, integrate container NICs directly with the virtual network (e.g., via OpenStack Kuryr).

Maintain compatibility with existing VM‑based services while incrementally containerizing workloads.

Overall, the article stresses that containers, micro‑services, and DevOps are tightly coupled; the appropriate technology stack depends on business scale, security posture, existing infrastructure, and the organization’s willingness to adopt new operational models.