3.2. Container-Orchestrated Solutions
💡 First Principle: One container is a process; production is a population — replicas that must scale with demand, roll out new versions without downtime, and heal when they die. Orchestration is population management, and Azure offers it at two abstraction levels: Container Apps (population management as a service, Kubernetes invisible) and AKS (the full Kubernetes control plane, manifests and all).
Why care? Because AI back-ends are the textbook case for orchestration: embedding workers that should number zero at midnight and fifty at noon, inference APIs needing gradual rollouts because a bad model prompt is a silent failure, queue consumers that scale on backlog rather than CPU. This section is also where the exam's sharpest service-selection line runs — the ACA-versus-AKS boundary from 1.2.1, now in operational detail.
The mental model for Container Apps, which carries the whole section: a revision is an immutable snapshot of your app's template — image, environment variables, scale rules — like a git commit for your deployment. You never edit a running revision; you create a new one and shift traffic. AKS, by contrast, hands you the raw Kubernetes objects and lets you compose the behavior yourself.
⚠️ Common Misconception: "Container Apps runs on Kubernetes, so kubectl and manifests work against it." The substrate is Kubernetes; the API is not. No kubectl, no manifest files, no custom controllers — those requirements route to AKS. The reverse cut also scores points: needing only KEDA scaling and revisions, without cluster operations, routes to ACA.
