Module 12 · Operate and grow · 30 min · You are: Platform and product

Reference architecture and the road to production

Each module added a layer. This one puts them on one page: infrastructure, bootstrap, repositories, workflows, Argo CD, ApplicationSets, platform resources, product namespaces, product applications and operations visibility.

Open this module in the interactive course to track progress and switch tracks.

Concepts

Infrastructure

Terraform from the inventory: clusters, Argo CD, registrations, root app.

Platform

ApplicationSets for add-ons, guardrails, observability and the product translation.

Products

One declaration per product; baseline and apps per environment and cluster; promotion by pull request.

Operations

Required checks, plan comments, production approvals, deployment records, trace, logs, drills.

Files to know

Open them in your editor or on GitHub; the bullets say what to look at.

• docs/fleet-architecture.md (reference, your repo): Everything on one page, plus the production checklist.
  1. The architecture you built L5–53
  2. Each layer, its files, when it changes, who owns it L55–66
  3. What to do before real users L85–102
• README.md (reference, your repo): What the workshop simplifies, and what production does instead.
  1. The trade-offs in one table L111–120

Steps

1. Compare your repo with the reference

Everything you built should match the reference except your URLs, your owners, and the changes you made in the exercises.

cd ~/work/fleet-gitops && git fetch -q reference

List the files that differ from the reference. Expect only your URLs, owners and the exercises you made. Anything else is worth a look. The :! parts leave out the catalog product you added.

git diff --stat reference/main -- . ':!products/catalog' ':!product-deployments/catalog'

2. Draw it from memory

Before opening the diagram, sketch the architecture: GitHub, your repo, Terraform, the hub, the spokes, the three product ApplicationSets, the change journey. Then compare with docs/fleet-architecture.md.

3. Pick your first three production items

Go through the checklist in the graduation page and open one issue per item you will do first.

4. Tear down (kind)

Delete everything you created, so nothing keeps running or costing money. Your repo keeps the whole fleet as code.

cd ~/work/fleet-gitops/infrastructure/kind && terraform destroy

infrastructure/cloud/<cloud>/down.sh

Quiz

1. What is the single source of truth for which clusters exist?
   • clusters/*.yaml (read by Terraform and the ApplicationSets)
   • Argo CD, because it holds the list of clusters it is currently connected to
   • The kubeconfig on the platform engineer's laptop, which Terraform reads on every run
2. Which layer would you split out first as the organisation grows?
   • Policies, because they change the fastest, so they should always live in a repository of their own from the very first day of the fleet
   • Products into team repositories, or infrastructure into its own repository, depending on which ownership boundary hurts first
   • Nothing ever: one repository is the right shape at every size, and splitting it only adds work, extra pull requests and more places to look
3. What makes this a GitOps operating model rather than a set of commands?
   • Argo CD, because it is the tool that applies every manifest to every cluster in the fleet, so using it is what makes the model GitOps
   • Kubernetes, because every object in the fleet is finally stored and reconciled there, which is the part that makes it an operating model
   • Every change, by any team, travels the same journey: issue, PR, checks, approval, merge, reconcile, healthy

Field note

Thanks for building it. If a step did not work on your track, that is a bug in the course, not in you: open an issue on the reference repo.

Report a problem with this module