← 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 👎.

📮 CI/CD pipelines — lesson 03

⏮️ Before CI/CD

FTP Fridays. One anointed "deploy person", a printed release checklist, a maintenance window at midnight, and tests run "when there's time". Integration happened once a month and was named "integration hell" for a reason. CI (2000s) made every push tested; CD made every good build shippable.

✅ Merits

  • every change tested, built, and traceable
  • no human steps to forget
  • deploys become boring (the goal!)

❌ Demerits

  • pipelines are code you must maintain
  • push-style: cluster keys live in CI (lesson 04)
  • blind between runs — drift goes unnoticed

👍 Use when

  • honestly: almost always — any team, any repo
  • at minimum: CI (tests + builds) from day one

👎 Think twice when

  • a throwaway prototype you'll delete next week
  • …that's about it. CI earns its keep everywhere.

Diagram ↗

📖 GitOps — lesson 05

⏮️ Before GitOps (term coined 2017)

Ops knowledge lived in wiki runbooks, shell history and heads. Clusters were changed imperatively (kubectl by hand, CI push), so "what's running?" and "who changed it?" had no reliable answer — Part 1 of this course is a museum tour of exactly that world.

✅ Merits

  • git = single source of truth; audit for free
  • drift detected and reverted continuously
  • rollback = git revert; DR = re-apply the repo
  • changes reviewed like code (PRs)

❌ Demerits

  • ceremony: every change rides through git (hotfix latency)
  • secrets need extra machinery (below)
  • "break glass" emergencies need an agreed process
  • one more mental model for the team

👍 Use when

  • Kubernetes + more than one env/cluster/team
  • compliance/audit questions actually get asked

👎 Think twice when

  • no Kubernetes — GitOps tooling is k8s-shaped
  • solo prototyping where speed beats ceremony

Diagram ↗

🤖 ArgoCD (the tool) — lessons 06–10

⏮️ Before ArgoCD (2018, CNCF-graduated 2022)

GitOps existed as scripts: Jenkins jobs running kubectl-apply on a timer, or early Flux (the other great GitOps agent — same loop, no UI). Heavyweight deploy platforms like Spinnaker did more but cost an ops team to run. ArgoCD won hearts with the visual app-tree UI.

✅ Merits

  • the UI: see every app, diff, sync state at a glance
  • app-of-apps + multi-cluster from one place
  • SSO/RBAC for teams; huge community

❌ Demerits

  • one more controller to run, upgrade and secure
  • k8s-only — it deploys nothing else
  • misconfigured UI perms can bypass git review

👍 Use when

  • several apps/envs/clusters, humans want visibility
  • teams need RBAC'd, self-service deploys

👎 Think twice when

  • one app, one cluster → Flux (lighter) or CI push is fine
  • non-k8s targets (Lambda, VMs) → different tools

Diagrams ↗

📚 Helm & Kustomize — lesson 11

⏮️ Before templating

Copy-paste YAML per environment — dev/staging/prod folders that started identical and drifted apart typo by typo (copy-paste drift is lesson 02's disease wearing YAML). Or worse: sed scripts in CI rewriting manifests nobody could preview.

✅ Merits

  • one source of truth + small per-env diffs
  • the difference between envs is readable in git
  • ArgoCD renders both natively

❌ Demerits

  • Helm templating can become {{ unreadable }} soup
  • Kustomize gets verbose for big variance
  • you debug the RENDERED output, not the source

👍 Use when

  • 2+ environments of the same app (the classic case)
  • installing third-party software (Helm charts)

👎 Think twice when

  • one env, a handful of files — plain YAML wins
  • templating for hypothetical future envs (YAGNI)

Diagram ↗

🔐 GitOps secrets: Sealed Secrets vs External Secrets — lesson 12

⏮️ Before proper GitOps secrets

Either secrets were pasted into git (published forever — git never forgets), or they lived outside GitOps entirely (hand-applied Secret files the robot couldn't manage — drift by design). Both ended in incident reports.

✅ Sealed Secrets shine

  • self-contained: just one controller, no vault needed
  • encrypted blob lives IN the repo — pure GitOps
  • simple mental model (locked box in the book)

❌ Their limits

  • rotation = re-seal and re-commit every secret
  • cluster rebuilt = new key = re-seal everything
  • no central place to see/rotate all secrets

👍 External Secrets shine

  • secrets live in AWS SM / Vault — rotation built in
  • one vault serves many clusters and apps
  • git holds only harmless pointers

❌ Their limits

  • depends on an external store + one more operator
  • the vault becomes critical infrastructure
  • slightly less "everything is in the repo"

Rule of thumb: small/self-hosted → Sealed Secrets · cloud with a secret manager → External Secrets. Diagram ↗