Module 8: Capstone The Andes Cargo Pipeline
7. What Andes Cargo still needs
Description
Lessons 5 and 6 traced two boundaries of honesty: what couldn't run under act, and what security this guide never set out to build. This lesson closes the complete map with a third boundary, different from the previous two: not what's missing inside this pipeline, but what Andes Cargo, as a complete system, would still need to operate in real production, beyond CI/CD. Three pieces, each with its own dedicated guide in this ecosystem: compute at scale with Kubernetes and the pull-based GitOps Module 7 already named, the operational discipline of what to do when something fails in production, and cost control for the infrastructure this pipeline deploys.
Connection to the module
This lesson executes nothing — it's this guide's last purely conceptual piece before lesson 8's final project. It revisits, without repeating in detail, what Module 7 already named about ArgoCD/Flux and pull-based GitOps, and adds two domains no earlier lesson in this guide mentioned yet: the deployment's own SRE, and infrastructure FinOps.
Analogy: the factory already built, and the three questions that follow
Think of Andes Cargo, as this guide left it, as a newly opened factory: the assembly line works (the pipeline), it has quality review at every station (ci.yml, the guardrail), and a clear protocol for applying approved changes (apply.yml). Opening the factory isn't the end of the story — it's the point where three different questions begin, each with its own team specialized in a real operation: what happens if demand grows beyond what this line can produce? (scale), what happens the night something breaks and nobody was watching? (incident operations), and how much is running this factory costing, and could it cost less without losing capacity? (cost control). This lesson names, without building, this guide's answer to each one.
1. Compute at scale: EKS and pull-based GitOps
Module 7, lessons 3 and 4, already named the technical piece: ArgoCD and Flux are operators that run inside a Kubernetes cluster, continuously watching a Git repository and applying any difference automatically — the pull-based model, different in mechanism (though not in principle) from the push-based one this guide built with apply.yml.
What this lesson adds is context on when Andes Cargo would need to make that leap. This guide's project has a single Lambda function —process-shipment-manifest—, with no application server running continuously. If Andes Cargo grew to need, for example, an API service with multiple replicas, automatic load-based scaling, and application deployments with strategies like blue/green or canary (named, without building, in Module 7, lesson 5), Kubernetes —and with it, kubernetes-and-eks-in-production-guide— would be the next logical step. That guide's GitOps wouldn't replace apply.yml — it would coexist with it: apply.yml would keep managing the base infrastructure (the EKS cluster itself, the tables, the buckets), while ArgoCD would manage which application version runs inside that cluster.
THIS PIPELINE (push-based) ARGOCD/FLUX (pull-based, another guide)
GitHub Actions PUSHES the change An operator INSIDE the cluster
toward AWS (terraform apply) watches Git and PULLS the change
Manages: base infrastructure Manages: which app version runs
(buckets, tables, roles, functions) inside the cluster (Deployments, Pods)
Still necessary even with Gets added ON TOP of the infrastructure
Kubernetes in the picture this pipeline already knows how to deploy2. The deployment's own SRE
No earlier lesson in this guide mentioned what happens after a successful apply leaves infrastructure running in production — Module 6 covered what to do if the apply itself goes wrong (rollback with git revert), but not what to do if the infrastructure, already correctly applied, starts failing in production for a reason no plan could have anticipated: a Lambda function that starts running out of memory under real load, a DynamoDB table that starts throwing throttling because traffic exceeded expectations, a bucket receiving more traffic than its network configuration tolerates.
This is, precisely, SRE's discipline (Site Reliability Engineering): defining SLIs/SLOs (service level indicators and objectives — for example, "99.9% of process-shipment-manifest invocations must complete in under 3 seconds"), having an on-call process for when that objective breaks outside business hours, and writing a blameless postmortem after every real incident, so the same mistake doesn't repeat. sre-and-incident-response-guide is the ecosystem guide that builds that complete discipline — something this guide's CI/CD pipeline makes possible (every change stays on record and is reversible) but doesn't replace at all.
3. Infrastructure FinOps
This guide's Module 1 was explicit about its own cost: act runs on local Docker, LocalStack simulates AWS at no cost — this guide's complete pipeline costs $0 by design. That same honesty demands saying, at the guide's close, that real Andes Cargo infrastructure, running against a genuine AWS account, does have a cost, and that cost needs its own control discipline: how much each Lambda function invocation costs, how much the bucket's storage costs as it grows, how much scaling the pipeline itself would cost if it moved from local act to hosted GitHub runners with billable minutes (an awareness mention, not a built guardrail, already flagged in this guide's DISENO.md). finops-and-cost-guardrails-guide is the guide that builds that discipline: budgets with alerts, cost tagging by project (the same kind of tag you added in this module's lesson 3, CostCenter, is exactly the kind of data a real FinOps system would use to attribute spend), and automated guardrails that block an apply if a change's estimated cost exceeds a threshold.
The complete ecosystem map, with Andes Cargo at the center
terraform-and-iac-guide
(HCL, state, modules — ALREADY COMPLETE)
│
▼
cicd-and-gitops-on-aws-guide (THIS GUIDE)
(Infrastructure CI/CD, push-based GitOps)
│
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
kubernetes-and-eks- sre-and-incident- finops-and-cost-
in-production-guide response-guide guardrails-guide
(EKS, ArgoCD/Flux, (SLI/SLO, on-call, (budgets,
pull-based GitOps) postmortems) tagging, alerts)
│
▼
cloud-security-and-guardrails-guide
(real OIDC, SAST/DAST, SBOM/cosign/
Trivy, Sentinel/OPA — this guide's Module 6)Four sister guides, each solving a problem this guide names but doesn't build, each with Andes Cargo —or the same kind of system— as a continuing case. None of the four is a mandatory "chapter 2" of this guide — they're independent paths, each relevant depending on what a real project needs to grow first: more compute scale, more incident discipline, more cost control, or more security depth.
Common mistakes
Thinking there's a single correct order to complete the four sister guides (conceptual). What happens: someone looks for a recommended sequence, assuming kubernetes-and-eks-in-production-guide has to come before finops-and-cost-guardrails-guide, or some similar order. How to fix it: all four are independent of each other — a real project might need FinOps well before Kubernetes (if cost is already a problem but compute scale isn't), or OIDC security before SRE (if the risk of a leaked credential is more urgent than incident discipline). The choice depends on what your own Andes Cargo needs, not a fixed syllabus.
Confusing SRE with "fixing the apply when it fails" (conceptual, revisit Module 6). What happens: someone thinks Module 6's git revert rollback already covers what SRE does. How to fix it: Module 6's rollback answers "the change we applied was wrong" —a problem with the apply itself—; SRE answers "the change we applied was correct, but the infrastructure, already running in production, started failing for an operational reason" —unexpected traffic, a service limit reached, a downed external dependency—. They're two different problems, with two different disciplines.
Assuming Andes Cargo "needs" all four pieces to be a legitimate portfolio project (expectation-based). What happens: someone, seeing the ecosystem's complete map, feels this guide's project is incomplete without all four extensions. How to fix it: a complete infrastructure CI/CD pipeline, tested end-to-end with an accepted change and a rejected one, is a real, independently defensible deliverable — exactly what this module's lesson 8 is going to demonstrate. The four sister guides are the growth path, not a retroactive requirement for what's already built to count.
Exercises
Exercise 1 — Locate this lesson's three pieces in the factory analogy. Without looking at the text, explain in your own words what question each of the three pieces (EKS/ArgoCD, SRE, FinOps) answers in the factory analogy that opened this lesson.
See solution
EKS/ArgoCD answers "what happens if demand grows beyond what this line can produce?" — the compute scale question. SRE answers "what happens the night something breaks and nobody was watching?" — the production incident operations question, after the infrastructure is already running. FinOps answers "how much is running this factory costing, and could it cost less?" — the continuous cost control question, not a single design decision.
Exercise 2 — Explain why lesson 3's CostCenter tag connects directly to this lesson. What relationship does the HCL change you made in this module's lesson 3 have with the FinOps piece you just read about?
See solution
The CostCenter = "logistics-andes" tag you added in lesson 3 is, exactly, the kind of metadata a real FinOps system would use to attribute that specific bucket's cost to a concrete business area —it lets an AWS cost analysis tool group spend by CostCenter, instead of seeing an aggregate number with no way of knowing which team generated it—. It's a small, isolated piece of what finops-and-cost-guardrails-guide would build in depth: a complete system of budgets, alerts, and automatic guardrails based on that same kind of tagging.
Exercise 3 — Decide which sister guide you'd choose first for your own project, and justify it. With no single correct answer: if you had to choose just one of this lesson's four sister guides to continue with today, which would you choose, and what concrete need of a real project would justify that choice?
See solution
There's no single answer, but a complete justification should name a concrete need, not an abstract preference. Example: "I'd choose cloud-security-and-guardrails-guide first, because any project that's going to touch a real AWS account needs to solve the long-lived credential problem before anything else —it's the piece that, if done wrong, has the widest, most immediate blast radius—." Or, in a different context: "I'd choose finops-and-cost-guardrails-guide first, because my team already has a real runaway-cost incident, and I need visibility before any other improvement." What matters is that the choice answers a real need, not a fixed order.
Summary and next step
In this lesson you closed this guide's complete honesty map with the third and final boundary: not what didn't run under act (lesson 5), not the security this guide didn't build (lesson 6), but the rest of the operational lifecycle Andes Cargo would still need in real production — compute at scale with Kubernetes and pull-based GitOps, the SRE discipline for when something fails after a successful apply, and FinOps to control the ongoing cost of the infrastructure this pipeline deploys. You saw the ecosystem's complete map, with the four sister guides as independent paths, not a mandatory sequence.
Before moving on you should be able to: explain what question each of this lesson's three pieces answers; connect lesson 3's CostCenter tag with FinOps's discipline; and justify, for a hypothetical real project, which sister guide you'd choose first.
With the three boundary-honesty lessons complete —Module 8, lessons 5, 6, and 7—, lesson 8 closes the complete guide: Andes Cargo's entire repository, turned into a portfolio piece you can defend without hesitation.
Resources
- This guide's Module 7 (
03-gitops-for-kubernetes-argocd-and-flux.md) — ArgoCD/Flux's and the pull-based model's complete origin, revisited here in a scale context. - Google SRE Book — Service Level Objectives — the canonical SLI/SLO reference, the conceptual basis for this lesson's SRE piece.
- AWS Well-Architected Framework — Cost Optimization Pillar — official AWS documentation on cost optimization, the basis for this lesson's FinOps piece.
kubernetes-and-eks-in-production-guide,sre-and-incident-response-guide,finops-and-cost-guardrails-guide(NIEVA) — the three sister guides that each build, end-to-end, the pieces named in this lesson.