← Back to Blog

Docker vs docker-compose vs Kubernetes — A Small-Business Decision Tree

Docker vs docker-compose vs Kubernetes — A Small-Business Decision Tree

The pattern I keep seeing: a small business reads an article about Kubernetes, assumes they should be on it, spins up a cluster, spends two weekends configuring Ingress and cert-manager, and ends up with the same WordPress site they had before. Only now they can't debug it.

The Container Visualizer exists to make the decision visible. Three diagrams, three stages, one honest answer about which one fits your business.

Stage 1. Plain Docker. One service on one VM. docker run --restart unless-stopped ... and systemd or Watchtower handles auto-updates. Covers maybe 80% of small-business workloads. A blog. An API. Ollama running local LLM inference. If you have one of these, you don't need compose.

Stage 2. Docker-compose. Three or more interdependent services. WordPress + database + Redis + backups. One YAML file, one docker compose up -d, done. Single-host, so when that VM dies everything is down until rebuild. But for 99% of small-business workloads, the one-in-five-years outage is tolerable. Run nightly volume backups to S3 and you're covered.

Stage 3. Kubernetes. Multi-node failover, zero-downtime rolling updates, autoscaling under traffic, many services, a team. Every concept above (pods, deployments, services, ingress, configmaps, secrets, RBAC, network policies) is another thing to configure. Don't jump here without a specific reason beyond "should be."

The diagram that makes it click

Each stage has an annotated diagram. Stage 1 shows your server, the Docker engine, two containers, a volume, port mapping. Stage 2 shows how compose ties services together with shared networks and auto-HTTPS via Traefik. Stage 3 shows the pod-per-node distribution that's the actual point of Kubernetes. Things move between nodes, and one node can die.

The comparison table in the diagrams shows the trade-offs explicitly: what each tier gets you, what you pay for it in operational complexity.

When people pick the wrong tier

The most common mistake is starting at Stage 3. The less common mistake is staying at Stage 1 when a real database needs managed backups and a real cache needs its own process. Compose is the middle answer for both.

Pair with the Docker Generator to generate the actual compose file once you've picked Stage 2, and the Kubernetes Audit if you genuinely do belong on Stage 3.

Methodology: Chapter 6 of The $100 Network, The Provider Stack. The book's bias is toward the simplest stack that runs the workload. Same philosophy this tool encodes.

← Back to Blog

Accessibility Options

Text Size
High Contrast
Reduce Motion
Reading Guide
Link Highlighting
Accessibility Statement

J.A. Watte is committed to ensuring digital accessibility for people with disabilities. This site conforms to WCAG 2.1 and 2.2 Level AA guidelines.

Measures Taken

  • Semantic HTML with proper heading hierarchy
  • ARIA labels and roles for interactive components
  • Color contrast ratios meeting WCAG AA (4.5:1)
  • Full keyboard navigation support
  • Skip navigation link
  • Visible focus indicators (3:1 contrast)
  • 44px minimum touch/click targets
  • Dark/light theme with system preference detection
  • Responsive design for all devices
  • Reduced motion support (CSS + toggle)
  • Text size customization (14px–20px)
  • Print stylesheet

Feedback

Contact: jwatte.com/contact

Full Accessibility StatementPrivacy Policy

Last updated: April 2026