Lesson 12 · Senior containers & local dev

Compose vs kind: the fidelity trade-off

Choosing the right local stack is a testing-design decision: what question are you trying to answer, and how much realism do you need to answer it?

Your win: explain why the repo keeps both local stacks, what each one is for, and how to justify your choice in an interview or debugging session.

In plain English Plain English: local stacks are not competitors; they are instruments with different accuracy and cost.

The tempting wrong question

The tempting wrong question is: “which local stack is better?” That sounds sensible, but it is not actually the useful question. The useful question is: “what am I trying to learn, and what is the cheapest stack that can answer that honestly?”

Once you ask it that way, the repo’s two-stack design stops looking redundant and starts looking deliberate.

The senior framing Compose for process-level speed. kind+Skaffold for Kubernetes-level fidelity.

Why speed and realism pull apart

Compose is fast because it is just containers and process wiring. kind+Skaffold is slower because it includes Kubernetes machinery, rendered manifests, and cluster semantics.

That is the trade-off in plain form: the more production-like your local runtime becomes, the more time and machinery you usually pay for. Senior local-dev judgment is about paying that price only when the question genuinely needs it.

What makes the kind stack worth it

You need the kind stack when the thing you are validating only exists in the Kubernetes path: deployment behavior, rendered Helm values, cluster naming, rollout behavior, or other cluster-specific interactions. If the question is only “does my service binary behave correctly against local dependencies?”, Compose often wins.

Anchor — why they still share one truth The important repo insight is that the stacks are not drifting by design: run.bash uses sk.bash -- render to generate compose-side configs. So even though the runtimes differ, configuration truth still flows through the Helm/Skaffold path.
Why this matters beyond this course This lesson is really the on-ramp to Kubernetes and Helm. Once you understand why the kind stack exists, Course 2 stops feeling like a jump into a different universe and starts feeling like a deeper layer of the same system.
Common mistake Picking the higher-fidelity stack by habit even when the question is simpler, or picking Compose when the failure only exists in the cluster/rendered-manifest world.
Read this next

kind + Skaffold docs

Use the official tools docs for the generic model, then map them back onto the repo’s sk.bash flow. That back-and-forth is what turns recognition into understanding.

→ kind
→ Skaffold

Check yourself (from memory)

Q1. The most senior way to choose between Compose and kind is…

Stack choice is a testing-design decision, not just a habit.
What is the clean one-line contrast between Compose and kind here?
recall, then click to reveal
Compose is the fast process/container loop; kind+Skaffold is the slower but more production-like Kubernetes loop. Use the one that matches the question you are testing.
Want me to turn this into a stack-choice decision tree? Ask me.

Sources. kind docs; Skaffold docs; in-repo scripts.