Where Containers and Kubernetes Fit

Build the mental model

A container packages an app and its dependencies into one portable unit — that part is covered thoroughly in the Docker tutorial, and this lesson assumes you already have a container to run. The question here is where to run it.

The simplest point is a single container on a PaaS-style platform — you push a container image, the platform handles running it, restarting it, and giving it a URL, with almost no orchestration knowledge required. That's enough for most small to medium apps.

The next point is a managed container service on a major cloud provider — still managed, but with more configuration surface: you can tune scaling rules, networking, and resource limits more precisely than a simple PaaS allows, at the cost of more setup and more concepts to learn.

The furthest point is a full Kubernetes cluster, which gives you the most control over scheduling, networking, scaling, and multi-service orchestration — and asks for the most operational expertise in return.

Move right as a response, not a default

Moving further right on this progression should be a response to genuine complexity you've already hit, not a default. The Kubernetes tutorial on this site covers orchestration depth in full; this lesson is only about deciding where a container should run before you get there.

text

CONTAINER PLATFORM PROGRESSION
------------------------------
SIMPLEST                                          MOST COMPLEX
   |                                                    |
   v                                                    v
SINGLE CONTAINER   -->  MANAGED CONTAINER   -->   KUBERNETES
   ON A PaaS              SERVICE (cloud)           CLUSTER

  push image           more config surface       most control,
  platform handles      (scaling, network,        most ops skill
  run/restart/url        resource limits)          required

  fits: 1 app,          fits: a few services,     fits: dozens of
  small/med traffic      finer scaling control     interdependent
                                                    services, real
                                                    orchestration need

  MOVE RIGHT ONLY WHEN COMPLEXITY YOU HIT DEMANDS IT

Connect it to a real scenario

Team 1: a single web service, modest and fairly predictable traffic, no dedicated ops person — a PaaS-style platform is the natural fit
Team 2: three services that talk to each other, traffic spikes unpredictably, wants finer autoscaling control — a managed container service fits better
Team 3: a few dozen interdependent services, needs coordinated scaling, already has people who understand cluster operations — a legitimate Kubernetes case

Notice the progression isn't about which platform is "best" in the abstract; it's about matching operational complexity to actual need. Starting with Kubernetes for team one's single service would mean carrying real operational weight with nothing to show for it. Starting with a simple PaaS for team three would mean fighting the platform's limits daily.

There's a three-point progression for running a container: PaaS, managed container service, Kubernetes
Moving right gives more control but demands more operational complexity
Kubernetes should be a response to genuine orchestration complexity you've hit, not a default starting point

Try the working example

javascript

function recommendContainerPlatform(workload) {
  const {
    numberOfServices = 1,
    needsAutoscaling = false,
    needsComplexOrchestration = false,
    teamHasOpsExpertise = false,
  } = workload;

  // Real orchestration needs plus the expertise to run them: Kubernetes is justified.
  if (needsComplexOrchestration && numberOfServices > 5 && teamHasOpsExpertise) {
    return "kubernetes-cluster";
  }

  // Several services or finer scaling control, but not full orchestration complexity yet.
  if (numberOfServices > 1 || needsAutoscaling) {
    return "managed-container-service";
  }

  // A single service with modest needs: start simple.
  return "single-container-on-paas";
}

const examples = [
  { name: "Solo dev, one API service", workload: { numberOfServices: 1 } },
  { name: "Startup, 3 services, wants finer autoscaling", workload: { numberOfServices: 3, needsAutoscaling: true } },
  { name: "Platform team, 12 services, real orchestration need, has SREs", workload: { numberOfServices: 12, needsComplexOrchestration: true, teamHasOpsExpertise: true } },
];

for (const ex of examples) {
  console.log(ex.name, "->", recommendContainerPlatform(ex.workload));
}

You should see

Solo dev, one API service -> single-container-on-paas
Startup, 3 services, wants finer autoscaling -> managed-container-service
Platform team, 12 services, real orchestration need, has SREs -> kubernetes-cluster

5-minute try-it

Try a workload with 12 services but teamHasOpsExpertise: false — see what recommendation comes back and think about why that's the sensible default

One important caution

Treating Kubernetes as the default choice simply because it's the most advanced option

Skipping the managed container service option and assuming it's only a PaaS-or-Kubernetes choice

Kubernetes docs: Overview — Cloud Providers & Platforms