← Back to the course home

⏮️ Before & trade-offs

Every tool replaced something worse — and is itself the wrong tool somewhere. For each big idea in this course: what life was like before it, its honest merits ✅ and demerits ❌, and where to use it 👍 vs where not 👎.

☸️ Kubernetes itself — the whole course

⏮️ Before Kubernetes (open-sourced 2014)

Fleets of hand-fed VMs: one app per VM, deploys via SSH + shell scripts or Ansible, load balancers edited by hand, scaling = a ticket to the infra team, and a pager going off at 3 AM because a process died and nothing restarted it. Google ran an internal answer (Borg) for a decade; Kubernetes is that idea, public. The middle era also had Heroku-style PaaS — wonderfully simple, but constrained and pricey at scale — and "docker-compose on one big VM", a single point of failure wearing a trench coat.

✅ Merits

  • self-healing — crashed pods return without humans
  • declarative desired state (the course's big idea)
  • rolling deploys, autoscaling, service discovery built in
  • runs anywhere — EKS, GKE, on-prem, laptop

❌ Demerits

  • steep learning curve (hence… 14 lessons 😄)
  • costs money to exist (EKS ≈ $73/mo before nodes)
  • YAML sprawl; day-2 ops: upgrades, add-ons, CVEs
  • massive overkill for one small app

👍 Use when

  • several services/teams, or real scaling needs
  • uptime matters enough to pay for redundancy
  • you're already containerized and outgrowing one box

👎 Think twice when

  • one app, small team → Cloud Run / App Runner / compose
  • nobody has ops time — a managed PaaS is honest
  • a static site or a cron job (seriously, don't)

Diagrams ↗

🏫 Ingress — lesson 10

⏮️ Before Ingress

Either one cloud load balancer per service — at real money each, times every service, times every environment — or a hand-managed nginx VM that one brave person understood. Ingress made "one gate, many rooms" a declarative object.

✅ Merits

  • ONE load balancer for many services (one bill)
  • path/host routing + TLS in one declared place
  • adding a service = one more rule, not more hardware

❌ Demerits

  • needs a controller add-on (ALB controller, nginx…)
  • annotation zoo differs per controller
  • HTTP(S)-shaped; raw TCP/UDP needs other doors

👍 Use when

  • 2+ HTTP services share one domain/LB
  • you want central TLS and routing rules in git

👎 Think twice when

  • exactly one service → a LoadBalancer Service is simpler
  • non-HTTP protocols (databases, game servers)

Diagram ↗

🚌 Autoscaling (HPA) — lesson 09

⏮️ Before autoscaling

Capacity-planning meetings. You guessed peak load, bought that many servers, and paid for them at 3 AM on a Tuesday. Guessed wrong? Either an outage on results day or a rack of idle metal. "Scaling" was a human clicking things during the cricket final.

✅ Merits

  • capacity rides the actual load curve
  • pay for quiet nights instead of provisioning for peaks
  • no 3 AM human scaling

❌ Demerits

  • needs metrics-server + honest resource requests
  • reacts in minutes — instant spikes still hurt
  • can mask leaks (scaling up instead of fixing)
  • fights anyone else who sets replicas (GitOps: ignore that field)

👍 Use when

  • traffic genuinely varies (day/night, seasons, events)
  • CPU/memory tracks load reasonably well

👎 Think twice when

  • flat traffic — fixed replicas are simpler and predictable
  • scale-to-zero dreams → that's serverless/Knative territory
  • spiky-in-seconds load → pre-warm or queue instead

Diagram ↗

🚪 Namespaces (vs separate clusters) — lesson 05

⏮️ Before namespaces

Isolation meant a whole cluster (or VM fleet) per team/project — maximum separation, maximum bills, and an ops team drowning in cluster upgrades. Namespaces bought lightweight rooms inside one building.

✅ Merits

  • isolation without buying another cluster
  • per-room quotas and access rules
  • clean blast radius: delete the room, not the school

❌ Demerits

  • shared control plane — one cluster upgrade risks all rooms
  • noisy neighbors share nodes unless you add quotas/taints
  • NOT a hard security boundary for hostile tenants

👍 Use when

  • teams/environments within one trusting org
  • dev/staging sharing a cluster to save money

👎 Think twice when

  • compliance demands hard isolation → separate clusters
  • running untrusted third-party workloads

Diagram ↗

📚 Managed database (RDS) vs in-cluster — lesson 12

⏮️ Before managed databases

A DBA (or the unluckiest developer) hand-tended database servers: installs, patches, backups nobody tested, and failovers performed live with sweaty hands. RDS-style services (2009+) turned that into a rented, automated librarian.

✅ Merits (managed)

  • backups, patching, failover — someone else's 3 AM
  • cluster stays stateless = every k8s lesson stays simple
  • encryption, snapshots, restore drills built in

❌ Demerits (managed)

  • costs more than raw compute
  • less control (versions, extensions, exotic tuning)
  • some vendor coupling

👍 Managed, when

  • production data + a small team (this repo's choice)
  • you can't staff real database operations

👎 In-cluster, when

  • dev/test environments (cheap, disposable)
  • a skilled team + an operator (CloudNativePG etc.)
  • the database isn't offered as a managed service

Diagram ↗