Module 8: Capstone Andes Cargo On Kubernetes
6. The continuity correction this guide leaves for the ecosystem
Description
This lesson closes a thread Module 1, lesson 3, and Module 6, lesson 1, opened and promised to close here: two sibling guides in this ecosystem, written before this cluster existed, state that "Andes Cargo has no containers." That sentence was true when it was written. It stopped being true the day this very lab loaded andes-cargo-status-api:latest inside andes-cargo-cluster, in Module 1. This lesson documents, with evidence verified line by line against those guides' real files, which correction already got applied and which one is still pending — without editing any file outside this guide.
Connection to the module
This is, in a sense, this entire capstone's least technical lesson — it applies no manifest, it runs no command against kind — and at the same time the one that most honors the hard rule that carried the aws-cloud-ecosystem ecosystem's eight guides: never leave an outdated premise unnamed.
The original premise, and why it was true when written
Through aws-serverless-and-containers-guide's Module 6, the Andes Cargo case had a single component that responded to events: process-shipment-manifest, a Lambda handler packaged in .zip, with no Docker image involved. When cloud-security-and-guardrails-guide and finops-and-cost-guardrails-guide were designed, the sentence "Andes Cargo has no containers in this ecosystem" was an exact description of the case's real state at that time.
That picture changed in that same guide's Module 6 (aws-serverless-and-containers-guide): andes-cargo-status-api got built for real — a five-instruction Dockerfile, an image run locally with docker run, published to a local registry. The containerized component already existed from that point in the ecosystem — the only thing it lacked was an orchestrator to actually run it, something neither that guide (due to LocalStack Hobby's limit with ECS) nor any later guide resolved until this one. This guide's Module 1, lesson 3, already documented that complete recap.
The real state, verified file by file, today
This lesson assumes nothing — it verified, against each sibling guide's real content, whether the correction has already been applied or is still pending.
cloud-security-and-guardrails-guide — CORRECTED
Its capstone (Module 8, lesson 7, "What Andes Cargo still needs") no longer repeats the old premise. It says, word for word:
"Andes Cargo's Lambda handler gets packaged in
.zip, not a container image; this guide's scanning and signing are of deployment artifacts and IaC, not of images. **The case's only containerized component —andes-cargo-status-api, the imageaws-serverless-and-containers-guidebuilt but never got to orchestrate — gets its runtime and its runtime security (admission control, image scanning, NetworkPolicy) inkubernetes-and-eks-in-production-guide".
This is exactly the sentence that accurately recognizes what this ecosystem built: Lambda's .zip is still true for process-shipment-manifest, and andes-cargo-status-api — the containerized component — now has an explicit place where its runtime security gets built: this guide.
finops-and-cost-guardrails-guide — STILL NOT CORRECTED
Its capstone (Module 8, lesson 7, the same equivalent section) still states, word for word, at the time this lesson was written:
"The boundary, already named in this guide's Module 7: this guide's rightsizing is of Lambda, DynamoDB, and S3 — Andes Cargo has no containers in this ecosystem."
This sentence is still the uncorrected old premise. It doesn't invalidate that guide's content — its rightsizing scope (Lambda, DynamoDB, S3, no Kubernetes) is still correct point by point — but the literal premise should say, with the same precision cloud-security-and-guardrails-guide already achieved, something equivalent to "Andes Cargo has a containerized component (andes-cargo-status-api), whose Pod-level requests/limits rightsizing falls outside this guide's scope, covered instead by kubernetes-and-eks-in-production-guide."
sre-and-incident-response-guide — STILL NOT CORRECTED
Its capstone (Module 8, lesson 7, the same section) also still states the old premise, word for word:
"Andes Cargo, across this entire ecosystem, has no containers — this guide's SLI measures a Lambda and an API, never a pod."
Same as with finops-and-cost-guardrails-guide, this doesn't invalidate that guide's content — its SLI/SLO/error budget discipline over Lambda and API is still exactly what it promises — but the premise should reflect that the containerized component does exist, with its own reliability discipline (which that same guide correctly names as something that would apply "with completely different signals" if Andes Cargo migrated to Kubernetes) built in this guide.
The status table, in one place
| Sibling guide | "Andes Cargo has no containers" premise | Status, verified against the real file |
|---|---|---|
cloud-security-and-guardrails-guide | Corrected — recognizes andes-cargo-status-api by name, points to this guide | ✅ Up to date |
finops-and-cost-guardrails-guide | Uncorrected — repeats the original premise, word for word | ⚠️ Pending |
sre-and-incident-response-guide | Uncorrected — repeats the original premise, word for word | ⚠️ Pending |
Why this lesson documents, and doesn't correct
This guide (kubernetes-and-eks-in-production-guide) has a hard rule, declared since its own design: it doesn't edit any other guide's file. Every guide in the aws-cloud-ecosystem ecosystem is responsible for its own content, and the right mechanism to propagate a continuity correction like this is for whoever audits the complete ecosystem — not an individual guide, acting on its own — to decide when and how to update each file. This lesson does exactly what falls to it: leave the complete, verified evidence in one place, so that audit doesn't have to rediscover it from scratch.
It's also worth noting the real correction isn't symmetric in difficulty: finops-and-cost-guardrails-guide and sre-and-incident-response-guide don't need to rewrite any of their technical content — the fix is, in both cases, a boundary sentence, the same size and precision as the one cloud-security-and-guardrails-guide already achieved.
Analogy: the note in the margin of the shared blueprint
Eight guides in this ecosystem share one case — Andes Cargo — like eight different teams working on the same blueprint of an expanding building. When one team adds a new wing to the building (the andes-cargo-status-api container, built in aws-serverless-and-containers-guide), the other teams' blueprints, drawn before that expansion, stay outdated in that single detail — they weren't done wrong, they simply didn't see the expansion in time. This lesson is the note someone leaves in the margin of two of those blueprints, in pencil, with nothing erased or redrawn: "this part of the blueprint no longer reflects the current building — review when appropriate." It's not the note-leaver's responsibility to redraw someone else's blueprint; it's the responsibility of whoever reads it, the next time they open that blueprint, to take it into account.
Common mistakes
Reading this lesson as a criticism of finops-and-cost-guardrails-guide or sre-and-incident-response-guide (tone). What happens: someone reads the status table and concludes those two guides are "poorly made." How to spot it: if your reaction is "those guides have a mistake." How to fix it: review the "Why this lesson documents, and doesn't correct" section — both guides' technical content (Lambda/DynamoDB/S3 rightsizing, the SLI/SLO discipline over Lambda and API) is still completely correct. The only outdated thing is a boundary sentence, written at a point in the ecosystem when it was accurate, and that stopped being so because of another guide's later development — the same kind of staleness any living documentation accumulates over time.
Assuming this guide should have corrected the files directly (misdirected urgency, the same pattern lesson 4 of this module warned about regarding kubectl apply --force). What happens: someone asks why this lesson doesn't just edit finops-and-cost-guardrails-guide's file to fix it. How to spot it: if your reaction to this lesson is "why haven't they fixed it already?" How to fix it: every guide in the ecosystem is responsible for its own content — the right discipline, the same one that upholds the integrity of all nine guides, is to document the finding with verifiable evidence and let the ecosystem's audit process decide when to apply the change, not for one individual guide to rewrite another's content on its own.
Not distinguishing "imprecise boundary premise" from "incorrect guide scope" (rushed reading of the table). What happens: someone reads that two guides have an uncorrected premise and assumes their entire scope boundaries are poorly defined. How to spot it: if your summary is "FinOps's rightsizing doesn't cover what it should" instead of "one specific sentence in that guide needs updating." How to fix it: the section for each guide cited in this lesson makes clear the scope itself (Lambda/DynamoDB/S3 for FinOps; Lambda/API for SRE) is still the correct boundary — the only imprecise thing is the premise that "there are no containers at all" in the ecosystem.
Exercises
Exercise 1 — Rebuild the status table from memory. Without going back to this lesson, state, for each of the three sibling guides mentioned, whether its premise is corrected or pending, and with what exact quote you verified it.
See solution
cloud-security-and-guardrails-guide — corrected: its capstone names andes-cargo-status-api explicitly and points to this guide for its runtime security. finops-and-cost-guardrails-guide — pending: its capstone still says "Andes Cargo has no containers in this ecosystem," uncorrected. sre-and-incident-response-guide — pending: its capstone still says "Andes Cargo, across this entire ecosystem, has no containers," uncorrected.
Exercise 2 — Explain, in one sentence, why this correction doesn't invalidate the pending guides' technical content. Without copying this lesson's text, explain to a colleague why "Andes Cargo has no containers" being an imprecise premise doesn't mean finops-and-cost-guardrails-guide's Lambda rightsizing is wrong.
See solution
A reasonable explanation: "That guide's scope — comparing PAY_PER_REQUEST against PROVISIONED, tuning Lambda memory with real Infracost data — never depended on whether Andes Cargo had a containerized component or not; it's a complete, correct discipline over the resources it does analyze. The only imprecise thing is the sentence describing the entire ecosystem as 'containerless,' which stopped being true after another guide built one — but that imprecision lives in a single boundary sentence, not in the guide's core technical work."
Exercise 3 — Design the exact correction you'd apply to finops-and-cost-guardrails-guide, without editing the file. Based on how cloud-security-and-guardrails-guide already resolved this same correction, write (in your notebook, not in the real file) the replacement sentence you'd propose for finops-and-cost-guardrails-guide's premise.
See solution
A reasonable proposal, following the same pattern cloud-security-and-guardrails-guide used: "This guide's rightsizing is of Lambda, DynamoDB, and S3. The case's only containerized component — andes-cargo-status-api, the image aws-serverless-and-containers-guide built but never got to orchestrate — gets its own Pod-level requests/limits rightsizing in kubernetes-and-eks-in-production-guide, outside this guide's scope." This proposal changes only the premise, without touching a single word of that guide's real technical content — exactly the kind of surgical correction this lesson describes as pending.
Summary and next step
This lesson closed the continuity thread Module 1, lesson 3, and Module 6, lesson 1, left open: it verified, against three sibling guides' real content, that cloud-security-and-guardrails-guide already corrected its premise about "Andes Cargo has no containers," while finops-and-cost-guardrails-guide and sre-and-incident-response-guide still repeat it, with that not invalidating either one's technical content. The correction stays documented here, with a verifiable exact quote, so the ecosystem's audit process — not this guide on its own — decides when to apply it.
Before moving on you should be able to: rebuild the status table for the three cited guides; explain why an imprecise boundary premise doesn't invalidate a guide's technical content; and propose the exact correction you'd apply, with no need to edit any file outside this guide.
Next lesson: what Andes Cargo still needs. There the map opens forward — what disciplines of the aws-cloud-ecosystem ecosystem already exist, ready for whoever wants to keep building on andes-cargo-status-api beyond this guide.
Resources
cloud-security-and-guardrails-guide(NIEVA), Module 8, lesson 7 — the correction already applied, quoted textually in this lesson.finops-and-cost-guardrails-guide(NIEVA), Module 8, lesson 7 — the pending premise, quoted textually in this lesson.sre-and-incident-response-guide(NIEVA), Module 8, lesson 7 — the second pending premise, quoted textually in this lesson.kubernetes-and-eks-in-production-guide(NIEVA), Module 1, lesson 3, and Module 6, lesson 1 — the two points where this guide first promised to close this thread in the capstone.