Module 1: Why Kubernetes And The Continuity Challenge
2. Why Kubernetes when ECS was already enough
Description
aws-serverless-and-containers-guide left you with a criterion installed: ECS/Fargate is "the simplest container orchestrator AWS offers" — no control plane to administer, no kubectl, no Kubernetes YAML manifests. And it worked: status-api-service with desiredCount: 2, in an awsvpc, behind a narrow security group, is a perfectly reasonable design for a read-only service. So why this entire guide? The answer isn't technical in the sense of "ECS can't do this" — in many cases, it can. The answer is a market answer: the real platform work companies are hiring for in 2026 assumes Kubernetes as the common ground, and that's a decision that doesn't depend on which orchestrator is "better" in the abstract.
Connection to the module
This lesson installs the criteria before you touch a single command. Lesson 3 picks up this same criterion to explain why this guide doesn't rebuild anything from scratch — it just gives andes-cargo-status-api the orchestrator this lesson's criteria justifies.
The market evidence, unedited
src/paths/aws-cloud-ecosystem/VALIDACION.md (market audit, 44 agents, July 19, 2026, "high" confidence) is unusually blunt on one specific point — blunt enough that it reverses a decision this ecosystem's own STRATEGY.md had made before the evidence arrived:
"It's the ecosystem's most serious gap, and it's not an oversight: STRATEGY explicitly excludes it ('Kubernetes in depth → EKS is covered as a managed service; K8s as a platform is a different scope'). That boundary was drawn backward from what the market says."
The finding, with figures and literal quotes from real job postings:
"None of the 10 guides cover ingress, cert-manager, external-dns, CNI, autoscaling, or GitOps. ~11 of 13 postings (~85%) ask for Kubernetes in production: CookUnity 'Kubernetes cluster deployment, management, and troubleshooting (EKS focus)' + 'Establish GitOps workflows through ArgoCD'; VirtualVocations 'EKS or ECS clusters at scale'; Apptiva (Spain) 'Helm template expertise for OpenShift 4.X'; MediaStream 'cluster management (cloud AND on-premise)'."
Notice something important: none of those four postings says "ECS." Two mention Kubernetes/EKS by explicit name, one asks for Helm on top of OpenShift (a Kubernetes distribution), and one asks for cluster management both in the cloud and on-premise — something only Kubernetes offers, because ECS is an AWS proprietary service, with no equivalent outside that cloud. That last posting, by itself, is this lesson's portability argument turned into a real hiring requirement.
What Kubernetes gains over ECS
1. Portability — the same YAML runs on any cloud, or nowhere in particular
A Kubernetes Deployment is an object that Kubernetes understands — not AWS, not Google Cloud, not a VM in your office. The same manifest that runs in kind, on your laptop, runs — with infrastructure adjustments around it, not to the resource definition itself — on EKS (AWS), on GKE (Google Cloud), on AKS (Azure), or on an on-premise cluster. An ECS task definition, on the other hand, is an object that only ECS understands: the full JSON (networkMode: awsvpc, requiresCompatibilities: [FARGATE]) means nothing outside an AWS account. This isn't an academic detail — it's exactly what MediaStream's posting from the evidence above explicitly asks for: someone able to operate "cloud AND on-premise," something ECS, by design, cannot offer.
2. An ecosystem of add-ons the market takes for granted
When a company says "we need GitOps with ArgoCD" or "we need cert-manager to renew TLS certificates automatically," it's assuming Kubernetes as the base — those tools are Kubernetes projects, built on top of its extensible API model (CustomResourceDefinition). ECS doesn't have an equivalent third-party ecosystem of the same size: it's a closed service, maintained solely by AWS, with the extension surface AWS decides to expose. Module 5 of this guide installs real ArgoCD; Module 6 installs two real admission control engines (Gatekeeper and Kyverno) — neither has a direct equivalent in the ECS world.
3. Native GitOps — Kubernetes' own API model is designed for this
Every Kubernetes object is, at bottom, a declarative document (YAML/JSON) describing a desired state, plus an internal control loop (controller-manager) that reconciles reality against that document without anyone triggering it by hand — you'll see this up close in Module 2. An operator like ArgoCD extends that exact same mechanism: instead of a CI pipeline that runs kubectl apply (push-based GitOps, what cicd-and-gitops-on-aws-guide teaches), a process inside the cluster itself watches a Git repository and converges the cluster toward what that repository declares (pull-based GitOps, this guide's Module 5). ECS has a "desired state" concept (desiredCount), but no extensible API model to build a third-party operator on top of that reacts to arbitrary changes.
4. Richer primitives for different kinds of workloads
ECS has, essentially, a single workload concept: the task, running inside a service. Kubernetes distinguishes Deployment (stateless services, like andes-cargo-status-api), StatefulSet (workloads with persistent identity and storage, like a database), DaemonSet (one Pod per node, for infrastructure agents), and Job/CronJob (work that runs to completion, once or scheduled). This guide only needs Deployment for the Andes Cargo case — but the full vocabulary is, literally, what a platform role needs to master to operate any real system, not just a read-only one.
What that gain costs: Kubernetes is not batteries included
This is where this lesson gets just as honest as the rest of the ecosystem. An engineer with real experience, in a Hacker News thread about exactly this topic, puts it plainly:
"it's not at all batteries included... you're still going to be installing a bunch of additional controllers (ingress, cert-manager, external dns to start)" — mikeocool, Hacker News (discussion 48548137).
That quote isn't an isolated complaint — it's an accurate description of what a freshly created Kubernetes cluster does not come with by default:
- No
Ingresscontroller.kind create clustergives you a functional cluster, but with no way to receive external HTTP traffic until you install one yourself (ingress-nginx, in Module 4 of this guide — the exact same real friction the quote describes). - No
cert-manager. Automatically renewing TLS certificates isn't out-of-the-box behavior — it's a separate project someone has to install and configure. - No external DNS. Having a real domain name point at your
Ingressrequires an additional controller (external-dns), not included. - No policy admission control. Nothing stops you, out of the box, from deploying a Pod with no CPU/memory limits, or with the
:latesttag — you need to install Gatekeeper or Kyverno yourself (Module 6 of this guide). - No GitOps. ArgoCD doesn't ship with the cluster — it is, again, something you install.
ECS, by contrast, solves several of these pieces by design, within the AWS ecosystem: load balancing integrates with AWS's native ALB with no additional controller to install; certificates are managed with ACM with no third-party project. That's ECS's real gain, and it's exactly what makes the choice not "Kubernetes is objectively better" — it's "the market, for the most part, expects you to install and operate those pieces yourself, with Kubernetes as the common base."
The decision table, unadorned
| Axis | ECS/Fargate | Kubernetes (kind / EKS) |
|---|---|---|
| Portability outside AWS | None — an AWS proprietary object | Total — the same YAML, adjusting infrastructure around it |
| Initial learning curve | Lower — a three-concept model (cluster, task, service) | Higher — an extensible API model with dozens of object types |
| Third-party add-ons (GitOps, admission control, service mesh) | Practically none native | Full CNCF ecosystem, most projects mature modern infrastructure |
| Pieces you have to install and operate yourself | Few — AWS handles load balancing, certificates, DNS in an integrated way | Several — ingress, cert-manager, external-dns, admission control, all separate |
Demand in platform/cloud job postings 2026 (VALIDACION.md) | Minority, not cited by name in the reviewed evidence | ~85% of reviewed postings (~11 of 13) |
| Operating cost of a small cluster | Lower — no control plane to pay for separately | Higher on real EKS (the control plane has its own cost) — Module 7 |
No row in this table says "ECS is bad." It says, with the same honesty that's held up this whole ecosystem so far, that Kubernetes wins on portability and on the ecosystem the market takes for granted, and loses on operational simplicity — the same kind of trade-off you already saw between serverless and containers in the previous guide, applied one level up.
The orchestra conductor, again: why this guide doesn't say "ECS lost"
Picking back up lesson 1's analogy: ECS is a conductor capable of leading a quartet — perfect for a small hall, with a limited repertoire, and with no need to hire more staff than the conductor themself. Kubernetes is a symphony orchestra conductor — capable of coordinating entire sections of instruments that other composers (the open-source community) keep adding, but that demands a bigger hall, more rehearsal, and — being honest — more people behind the scenes (the add-ons mikeocool's quote describes). No hall always needs the full symphony. The question the 2026 hiring market answers, with VALIDACION.md's evidence, isn't "which orchestra sounds better?" — it's "what kind of conductor are concert halls hiring right now?" And the answer, with 85% of reviewed postings asking for Kubernetes, is clear.
Common mistakes
Concluding "so ECS is useless" (conceptual, the opposite extreme, equally wrong). What happens: someone, after seeing the market evidence favoring Kubernetes, concludes that ECS was a waste of time in the previous guide, or that no real company uses it. Why it happens: it's easy to overcorrect when a figure like "85%" appears so bluntly. How to spot it: if your takeaway from this lesson is "I'd never use ECS," with no nuance. How to fix it: ECS remains, today, a perfectly reasonable choice for small teams, with no need for portability outside AWS, who prefer fewer pieces to operate — this lesson's table makes that explicit. The market evidence says which skill is more in demand for platform roles, not that the alternative is invalid in every context.
Thinking that "installing Kubernetes" and "learning Kubernetes" are the same as "installing and operating the add-ons" (expectation, the mistake mikeocool's quote prevents). What happens: someone assumes that once kind create cluster works (lesson 5), this guide's heavy lifting is already behind them. Why it happens: creating a cluster with kind takes under a minute — it feels like "that's it." How to spot it: if you expect Module 4 (Ingress) or Module 6 (admission control) to be trivial, one-line steps. How to fix it: this lesson's quote is literal — those modules exist exactly because installing and configuring each additional piece (ingress-nginx, Gatekeeper, Kyverno, ArgoCD) is real work, each with its own hands-on lesson.
Comparing real EKS cost against kind without clarifying the difference (communication issue, relevant already because Module 7 picks it back up). What happens: someone, when justifying why this guide uses kind instead of EKS from the start, just says "because it's free," without mentioning that kind is real Kubernetes, not a reduced or fake version. Why it happens: "free" sounds like "simulated" or "toy." How to spot it: if you describe what you're going to do in this guide as "practice with a simplified version of Kubernetes." How to fix it: kind runs the exact same kube-apiserver/kubelet/etcd binaries that run inside an EKS node — packaged in Docker containers, with no pedagogical shortcut. What changes on EKS isn't "real Kubernetes" — it's who administers the control plane and how the compute behind it is obtained, exactly Module 7's topic.
Exercises
Exercise 1 — Quote the evidence without looking. Without re-reading the "The market evidence" section, write from memory: (a) the approximate percentage of platform job postings asking for Kubernetes in production, per VALIDACION.md; (b) the name of at least one company cited; (c) mikeocool's literal quote about "batteries included."
See solution
(a) ~85% (approximately 11 of 13 reviewed postings). (b) CookUnity ("Kubernetes cluster deployment, management, and troubleshooting (EKS focus)" + "Establish GitOps workflows through ArgoCD"), or VirtualVocations ("EKS or ECS clusters at scale"), or Apptiva/MediaStream, any of the four counts. (c) "it's not at all batteries included... you're still going to be installing a bunch of additional controllers (ingress, cert-manager, external dns to start)".
Exercise 2 — Apply the decision table to a new case. A fictional company needs to deploy an internal service that will only ever run on AWS, with no multi-cloud plan whatsoever, with a two-person team that has never operated Kubernetes. Using only this lesson's table (not your intuition), argue whether ECS or Kubernetes is the more reasonable choice, and why.
See solution
With that specific description — no portability need, small team, no prior experience — the table points strongly toward ECS: the portability row adds no value (they're never leaving AWS), the learning-curve row weighs heavily with a two-person team with no experience, and the "pieces you have to install and operate yourself" row would be a real operational burden for such a small team. The only reason to choose Kubernetes in this specific case would be a bet on the future (team growth, an eventual multi-cloud need) — not a current need. This exercise exists to show that this lesson's criteria is a decision tool, not an absolute verdict in favor of Kubernetes in every scenario.
Exercise 3 — Explain the trade-off to a skeptical colleague. A colleague says: "if Kubernetes wins in 85% of postings, then it's objectively better than ECS, full stop." Correct them in two or three sentences, without denying the market evidence.
See solution
A complete answer sounds roughly like this: "The market evidence is real, but '85% of postings ask for it' isn't the same as 'it's objectively better' — it's 'it's what platform companies are hiring for the most today,' which is a different question. Kubernetes wins on portability and on the add-on ecosystem the market takes for granted, but that comes with more pieces you have to install and operate yourself — ingress, cert-manager, admission control, all separate — something ECS solves in a more integrated way within AWS. The right decision depends on context: for a team that's never leaving AWS and prioritizes simplicity, ECS remains reasonable."
Summary and next step
In this lesson you installed the whole guide's central criterion: Kubernetes wins over ECS on portability (the same YAML runs on any cloud), on the add-on ecosystem the 2026 hiring market takes for granted (~85% of platform postings, per VALIDACION.md), on native GitOps (its own API model is designed for declarative reconciliation), and on richer primitives for different kinds of workloads — but that gain costs more pieces you have to install and operate yourself, exactly what mikeocool's quote about not being "batteries included" describes. Neither option is objectively superior; they're different trade-offs for different contexts.
Before moving on you should be able to: quote the market figure and at least one concrete job posting from memory; explain, without the table in front of you, at least two axes where Kubernetes wins and one where ECS wins; and decide, for a new scenario, which of the two orchestrators makes more sense.
Lesson 3 applies this same criterion to Andes Cargo's concrete case: why the image aws-serverless-and-containers-guide built gets picked up as-is, with nothing new invented, and what "giving it, for the first time, a real orchestrator" means.
Resources
src/paths/aws-cloud-ecosystem/VALIDACION.md(NIEVA, market audit, July 19, 2026) — the complete source of the evidence cited in this lesson.- Hacker News — discussion 48548137 — the original thread where mikeocool describes the real experience of "not batteries included."
- Kubernetes — Why Kubernetes? — the project's official stance on portability and the declarative model.
- AWS — What is Amazon ECS? — official reference for the model this lesson uses as its point of comparison.
aws-serverless-and-containers-guide(NIEVA), Module 7 — the complete ECS/Fargate model this lesson treats as already known.