Module 07: Choosing Your Deployment Target

Why this matters

You've done all the app-side work: a clean image (module 00), a stateless disposable container (module 01), a CI pipeline that produces a trustworthy artifact (module 02), safe deployment and migration patterns (modules 03-04), externalized config (module 05), and probes plus scaling signals (module 06). The last decision is where that container actually runs — and it's a genuine decision, not a default. A backend service can run on a plain VM, on a container orchestrator (self-managed Kubernetes or managed AKS), on a PaaS/container platform (Azure Container Apps), or as serverless functions. Each choice trades operational control against operational burden, and picking wrong means either drowning a small team in Kubernetes it doesn't need or hitting a serverless wall a real workload can't fit.

This is a decision-framework module, not a hands-on-with-each-platform module. The point isn't to teach you AKS or Container Apps — the learn/ curriculum does that in depth, and this module's whole job is to tell you which learn/ track to go deep in for the target you choose. What you own as the backend engineer is the reasoning: understanding what each target demands of your app, what it does for you, and how to match the target to your team's size, the workload's shape, and how much operational surface you can afford to own. Because you built the app to be 12-factor-clean (stateless, config-in-env, disposable, port-binding), it can run on any of these targets — that portability is exactly what makes the choice a free one rather than a forced one.

Concepts

The control-vs-burden spectrum

Every deployment target sits on one axis: how much of the operational stack you control, versus how much the platform manages for you. More control means more flexibility and fewer constraints — and more that you must operate, patch, secure, and get paged for. Less control means less to operate — and more constraints on what your app can do and how it behaves. From most-control/most-burden to least:

• VM (IaaS): you get a machine; you own everything above the hypervisor — OS patching, the container runtime (or running the process directly), the load balancer, scaling, health-checking, deploys. Maximum control, maximum toil.
• Self-managed Kubernetes: you run the orchestrator yourself. You get Kubernetes' full power (any workload, fine-grained control) but you also operate the control plane, nodes, upgrades, networking, and add-ons. Enormous burden.
• Managed Kubernetes (AKS): the cloud runs the control plane; you run your workloads and (to varying degrees) the node pools. Full Kubernetes API, much less of the cluster to babysit — but still real Kubernetes complexity to understand.
• PaaS / managed container platform (Azure Container Apps): you hand the platform a container and a bit of config; it runs, scales (including to zero), load-balances, and does rolling deploys for you. Much of Kubernetes' benefit, little of its operational surface — at the cost of some flexibility.
• Serverless functions (Azure Functions, Lambda): you hand the platform code (or a small container) and it runs it per-request/per-event, scaling automatically, billing per execution. Minimum burden, maximum constraint — the platform dictates the execution model.

  MORE control / MORE burden ◄───────────────────────► MORE managed / LESS burden
  ┌────────┬────────────────┬─────────────┬───────────────┬──────────────┐
  │  VM    │ self-managed   │ managed k8s │  PaaS         │  serverless  │
  │ (IaaS) │  Kubernetes    │  (AKS)      │ (Container    │  functions   │
  │        │                │             │  Apps)        │              │
  └────────┴────────────────┴─────────────┴───────────────┴──────────────┘
   you patch OS,             you run       you hand it     you hand it code;
   run everything            workloads     a container     it runs per-event
                                           + config
      ◄── flexibility, fewer constraints        constraints, near-zero ops ──►
              default bias: start here ─────────────────────┘ (move left only if forced)

The core judgment: push as far toward "managed" as your workload's constraints allow, because operational burden is a real, ongoing cost that a small team pays in attention it could spend on the product. You move back toward control only when a specific constraint forces you to. Kubernetes is not the default; it's what you choose when you've outgrown the simpler options or genuinely need its power.

What each target demands of your app (and gives back)

The 12-factor work you did makes your app portable, but each target still has a distinct contract:

• VM: you must supply the process manager (systemd), reverse proxy, and deploy scripting yourself, or run your own Docker. Nothing enforces statelessness or disposability — which is a trap: it's the easiest place to accidentally rely on local state. Suits legacy workloads, things needing unusual OS access, or a single simple service where a scheduler is overkill.
• Orchestrator (AKS / self-managed k8s): consumes exactly the contract this track built — a container image, liveness/readiness probes (module 06), a SIGTERM drain (module 01), config via env/Secrets (module 05), and metrics for the HPA (module 06). In return: rolling deploys, self-healing, horizontal autoscaling, service discovery, and the ecosystem (Istio, ArgoCD, etc.). Best fit when you have many services, need fine control over networking/scheduling, or are standardizing a platform for multiple teams — and can afford the complexity.
• Container Apps (PaaS): wants the same clean container but hides Kubernetes; you get scale-to-zero, revisions with built-in blue/green/canary traffic splitting, managed ingress, and Dapr/KEDA integration without writing YAML for a cluster. Best fit for most individual backend services and small teams that want container flexibility without operating a cluster.
• Serverless functions: demands your work fit an event/request-triggered handler with a short execution limit and (classically) no long-lived connections or in-memory state between invocations — and imposes cold starts (latency when scaling from zero). In return: true scale-to-zero, per-execution billing, and near-zero ops. Best fit for spiky/event-driven/low-baseline workloads, glue, and webhooks — a bad fit for steady high-throughput services, long-running work, or anything latency-sensitive that can't absorb cold starts.

The decision framework

Rather than "which is best" (there is no best), work through the constraints in order — the first one that bites narrows your choice:

1. Workload shape. Is it a long-running HTTP service, or short event/request- triggered bursts with a low baseline? Bursty/event-driven with idle periods → serverless or scale-to-zero PaaS is compelling. Steady, latency-sensitive, high-throughput → containers on a PaaS or orchestrator; serverless cold starts and execution limits fight you.
2. Team size & operational capacity. Can you afford to operate a Kubernetes cluster (upgrades, networking, on-call for the platform itself)? A small team almost always should not run self-managed k8s, and often shouldn't run AKS either if a PaaS fits — the burden buys nothing they need.
3. Scale & number of services. One or a few services → PaaS/serverless. Many interdependent services needing shared networking, policy, service mesh, and a standardized deploy platform across teams → an orchestrator starts earning its complexity.
4. Control & special needs. Do you need specific networking, GPUs, custom schedulers, particular OS access, or ecosystem tools (a service mesh, custom operators)? That pulls toward AKS/k8s. Do you have legacy/unusual-OS needs a container can't express? That may pull to a VM.
5. Cost model. Spiky low-baseline traffic → per-execution/scale-to-zero billing (serverless/Container Apps) can be dramatically cheaper than always-on replicas. Steady high traffic → always-on containers are usually cheaper than per-execution.

The framework's spirit: start from the most-managed option that fits and move toward control only when a constraint forces it. Most individual backend services are best on a PaaS like Container Apps; you graduate to an orchestrator when scale, service count, or control needs justify the burden — not by default or by résumé.

Mapping each choice to where you go deep

This module deliberately does not teach you to operate these platforms — it tells you which learn/ track to work through once you've chosen:

• Containers themselves (building/running images, registries, the fundamentals under every option) → learn/02-docker. Foundational to all the container targets; do this regardless.
• Kubernetes concepts (Pods, Deployments, Services, probes, rolling updates — the model behind AKS and Container Apps) → learn/03-kubernetes. Even if you deploy to a PaaS, this explains what it's doing for you.
• Managed Kubernetes on Azure (standing up, securing, and operating a real cluster) → learn/07-aks.
• The PaaS / managed-container option (deploy, scale, network, and operate workloads on the managed alternative to AKS) → learn/06-azure-container-apps.
• The full path to production (CI/CD pipelines, GitOps, promotion) → learn/10-cicd-and-gitops; and the broader platform that ties targets, IaC, and self-service together → learn/24-platform-engineering.
• Provisioning any of it declaratively (VNets, clusters, registries as code) → learn/09-terraform-on-azure.

The division of labor for this whole track, restated: you make the app deployable and choose the target; learn/ is where you learn to operate that target. Both curricula are meant to be worked roughly in parallel — this module is the map that connects your app-side decision to the operational deep-dive.

Portability is the payoff — and its limits

Because you built a 12-factor container, the same artifact can move between these targets: a service that runs on Container Apps today can move to AKS when you outgrow the PaaS, with no code change — the deployment target is (mostly) a release-time concern, not an app-design one. That's the dividend of everything this track insisted on: statelessness, config-in-env, disposability, port-binding, and health probes are the common contract every target consumes.

The limits are worth naming honestly, so portability doesn't become a fantasy of "never commit": serverless's execution model (short-lived, stateless-per-invocation, cold starts) is a genuinely different shape that a steady HTTP service can't always be poured into without rework; and deep coupling to one platform's proprietary features (a specific managed queue, a platform-specific autoscaler trigger, a vendor identity model) creates real lock-in even with a portable container. The pragmatic stance is avoid gratuitous lock-in (keep the app 12-factor and the config externalized so a move is possible) while using the managed features that genuinely save you operational burden (don't self-host a queue to stay "portable" if the managed one is right) — a judgment call, exactly like module 04's "normalize first, denormalize with a measured reason." Portability is insurance, not a mandate to run everything yourself.

Command reference

The decision, as a checklist you run top-down (first constraint that bites wins):

1. Workload shape?     bursty/event-driven + low baseline → serverless / scale-to-zero PaaS
                       steady/latency-sensitive/high-throughput → PaaS or orchestrator
2. Team capacity?      small team / no platform on-call → PaaS (avoid self-managed k8s)
3. Scale & # services? one/few → PaaS; many interdependent + shared platform → orchestrator
4. Control/special?    mesh/GPU/custom networking/OS access → AKS or VM
5. Cost model?         spiky low-baseline → per-execution/scale-to-zero; steady → always-on

Default bias: start most-managed that fits (usually Container Apps for a single
service); move toward control only when a constraint above forces it.

The same 12-factor container across two targets (the artifact doesn't change — only the release wrapper does; mechanics live in the learn/ tracks named):

# ---- Container Apps (PaaS): hand it the image + config; it scales/ingresses/deploys ----
# properties: image, env (incl. secretRef), targetPort, minReplicas: 0, scaleRule (concurrency)
#   → learn/06-azure-container-apps

# ---- AKS (orchestrator): the same image, but you declare the k8s objects ----
# Deployment(image, envFrom, readinessProbe /readyz, livenessProbe /livez) + Service + HPA
#   → learn/03-kubernetes, learn/07-aks

Hands-on exercises

These are decision and mapping exercises — the operating-the-platform practice is in the learn/ tracks. Use a real service you've carried through this track.

1. Place five services on the spectrum

For each, pick a target and justify it in one sentence: (a) a steady internal REST API, ~200 req/s all day; (b) a webhook receiver that fires a few times an hour; (c) a nightly batch job; (d) a platform of 15 interdependent microservices for 4 teams; (e) a legacy app needing a specific kernel module. Name which learn/ track you'd go deep in for each.

2. Run the framework on your own service

Take the service you built across this track and walk it top-down through the 5-question framework. Write your answer to each question and the target the first binding constraint points to. Note whether the "most-managed that fits" default lands you somewhere different from where you'd have guessed.

3. Cost-model a spiky workload

For a workload that's idle 20 hours a day and busy 4, sketch (roughly) the cost of always-on replicas vs scale-to-zero/per-execution. Identify the crossover: at what baseline utilization does always-on become cheaper than per-execution? State which target each side of the crossover favors.

4. Map the app-side contract to the target

List the artifacts this track produced (image, /livez + /readyz, SIGTERM drain, env/Secret config, /metrics). For AKS and for Container Apps, say which of these each platform consumes and how — and confirm the image itself is identical for both. This is the portability payoff made concrete.

5. Find the serverless wall

Take a steady, latency-sensitive HTTP service and list the specific reasons it's a poor serverless-functions fit (cold starts, execution limits, connection management, cost at steady load). Then take a bursty event handler and list why it's an excellent fit. Articulate the shape difference in one sentence.

6. Justify graduating from PaaS to orchestrator

Describe a concrete point at which a service/team should move from Container Apps to AKS — what specific constraint (from the framework) triggers it — and, just as important, describe a case where reaching for Kubernetes would be over-engineering. Point to learn/06 and learn/07/learn/03 respectively.

7. Diagnose and fix: the target mismatch

A four-person startup runs its single moderate-traffic FastAPI API on a self-managed Kubernetes cluster they stood up themselves. They spend most of their week on cluster upgrades, node issues, and platform on-call; feature work has stalled; the service itself is a plain stateless web app with no special needs. Separately, they moved a latency-critical, steady-throughput synchronous API onto serverless functions "to save money" and now users complain about intermittent 1-second delays. Diagnose both mismatches and prescribe the right target for each, with the learn/ track to go deep in.

Independent challenge

No code given. Write a deployment-target decision document for the service you've carried through this entire track. Run it top-down through the five-question framework (workload shape, team capacity, scale/number of services, control/special needs, cost model), state which target the first binding constraint selects, and justify why you did not pick each of the other four — explicitly naming the operational burden or constraint that ruled each out. Then demonstrate the portability payoff: show that the artifact from module 00 (Containerizing a backend app) and the app-side contract from module 06 (Health checks, readiness, and scaling signals) and module 01 (The 12-factor app in a container) would be consumed by both your chosen target and one alternative with no change to the image — and name the specific learn/ track you'd work through to operate each (learn/06-azure-container-apps, learn/07-aks, learn/03-kubernetes, or learn/02-docker). Close with an honest paragraph on lock-in: which managed features you'd adopt for the operational savings even though they create some coupling, and which you'd keep at arm's length to preserve the ability to move — framing it as the same measured-tradeoff judgment, not a dogmatic "never commit."

Common mistakes & troubleshooting

• Kubernetes by default (or by résumé). Running a cluster for a single simple service buries a small team in operational burden that buys nothing. Start most-managed; graduate to an orchestrator only when a constraint forces it.
• Serverless for a steady, latency-sensitive service. Cold starts and execution limits fight a workload that needs warm, predictable, long-running handlers, and it's not even cheaper at steady load. Serverless is for spiky/event-driven work.
• Choosing a target before knowing the workload shape. The shape (bursty vs steady, short vs long) is the first question; picking the platform first backwards-rationalizes the fit.
• Ignoring operational capacity. A powerful target you can't operate is a liability. Weigh the ongoing burden (upgrades, on-call for the platform) against team size honestly.
• Cost-modeling only one dimension. Per-execution looks cheap until steady load makes always-on cheaper (and vice versa). Model your actual traffic profile.
• Confusing "portable" with "must self-host." Refusing every managed feature to stay portable costs more burden than the lock-in it avoids. Use managed features that save real toil; avoid gratuitous coupling.
• Trying to learn to operate the platform here. This module is the decision; the operational depth is the named learn/ track. Go there for hands-on.

Checkpoint quiz

Write down your answer to each question before expanding it — checking without attempting first is the single easiest way to fool yourself into thinking you've learned this.

1. What single axis organizes all the deployment targets, and what's the default bias the framework recommends along it?
2. Give the five questions of the decision framework in order, and explain why you run them top-down and stop at the first constraint that binds.
3. Why is serverless a great fit for a bursty webhook receiver and a poor fit for a steady, latency-sensitive API? Name the two serverless properties that drive each verdict.
4. A four-person team is running its single stateless service on self-managed Kubernetes. What's the mismatch, and what target (and learn/ track) would you move them to?
5. Name the learn/ track you'd go deep in for each: containers/images; the Kubernetes model itself; managed Kubernetes on Azure; the managed-container PaaS.
6. What makes the same container portable across VM, PaaS, and orchestrator, and what are the two honest limits on that portability?

Cumulative review

Closed-book. Don't reopen modules 00-07 while attempting these — the point is to find out what actually stuck.

1. A one-line code change triggers a four-minute Docker build that reinstalls every dependency and produces a 1.1 GB image that runs as root and is unreachable when published. Name every fault and the fix (module 00), and state the build-cache rule in one sentence.
2. "Works on one replica, breaks on three": inconsistent counts and lost uploads. Name the factor (module 01), the two sub-causes and their fixes, and explain why this same property is what makes both the rolling deploys of module 03 and the autoscaling of module 06 possible.
3. Design the two-lane CI pipeline for a backend service (module 02): what each lane runs, what gates vs informs, why the image is tagged by commit SHA, and which later capability that tagging enables.
4. You must rename a DB column used by both the API and still-running old replicas, with zero downtime. Give the full expand/contract sequence of deploys and migrations (modules 03-04), the ordering rule for the additive vs the destructive migration, and the single invariant that must hold at every step.
5. Walk a single replica from a rolling-deploy SIGTERM to a clean exit, naming: what makes uvicorn receive the signal (module 00), the readiness/drain sequence (modules 01, 06), the pre-stop-delay race it addresses, and why readiness must fail before draining.
6. For each probe, state its question, the platform action on failure, and whether it may check a dependency (module 06): liveness, readiness, startup. Then explain why a DB check in the liveness probe causes a fleet-wide restart storm.
7. A service is misconfigured in three ways (module 05): staging wiped prod's DB, a live key was printed in logs, and turning off a broken feature needed a 40-minute redeploy. Give the fix for each and the general principle ("fail early and loud, not late and quiet").
8. Run the deployment-target framework (module 07) for: (a) a spiky event handler idle most of the day; (b) a steady latency-sensitive API for a four-person team; (c) a 15-service platform for multiple teams. Give the target and the learn/ track for each.

Further reading & sources

• AWS: Types of cloud computing (IaaS / PaaS / serverless) - A vendor-neutral framing of the control-vs-managed spectrum this module organizes targets along.
• Azure Container Apps: Overview - The managed-container PaaS: scale-to-zero, revisions, and built-in traffic splitting without operating a cluster.
• Azure Kubernetes Service (AKS) documentation - Managed Kubernetes for when service count and control needs justify the orchestrator's complexity.
• Google Cloud: Serverless vs containers - The workload-shape trade-offs (cold starts, execution limits) that decide serverless fit.
• AWS Lambda: Cold starts and execution model - Why serverless suits bursty/event-driven work and fights steady latency-sensitive services.

Next

08-capstone-project — you can now containerize a backend service well, build it in CI, deploy it without downtime, migrate its database safely, configure it across environments, expose the signals a platform needs, and choose where to run it. The capstone integrates all of it: take a real FastAPI service from code to a documented, deployable, operable whole — a proper image, a CI pipeline, and a deployment runbook covering migration ordering, health checks, and rollback for a rolling deploy.