Containers on Cloud
Intermediate 13 min read Containers on Cloud

Managed Container Services

Containers without the control plane

ECS, Azure Container Apps, and Cloud Run run containers without you running the control plane. They trade full workload autonomy for deployment, scaling, and patching simplicity.

ECSAWS FargateAzure Container AppsCloud Runmanagedserverless containers
Prerequisites: Container Fundamentals
Before we start

What you will learn

  • Place container services on the managed spectrum (ECS → Cloud Run)
  • Choose service type by control vs simplicity
  • Deploy and scale a container service
In 60 seconds

Managed services let you say 'here's the image, how I want it scaled' and get autoscaling, LB, rollouts, and patching. ECS/Fargate is closer to infrastructure; Cloud Run/ACA are closer to 'serverless container'.

Introduction

What is this?

Spectrum: ECS (ECS EC2 asks to pin your own nodes vs Fargate serverless hosting), Azure ACI/ACA (Container Apps), Cloud Run (fully-managed, scale-to-zero). Platform abtractions: task/service (ECS), container app with revisions (CAApp), Cloud Run service/revisions/environments. Key behaviors: horizontal autoscaling by CPU/mem/req+concurrency, App Ready checks / run lifecycle, revision traffic splits (Cloud Run 100→0%, CA Apps weights). Pricing: per vCPU/mem/sec (Fargate, Cloud Run), request-based on CAAs clean/plan-based. Whole management: LB, DNS, secrets mounts, IAM/role injection handled by provider.

Motivation

Why do you need it?

  • No master nodes, no node pools, no kubelet to patch — operational surface shrinks hard.
  • Scale-to-zero options cut idle cost for variable traffic.
  • Deployment is a revision + traffic switch: cheap rollbacks and canaries.
  • Less boilerplate than full Kubernetes for a single container workhorse.
Think about it

Mental model

Imagine

Ordering pizza at a restaurant vs hauling the whole kitchen

Think of

Managed container service

The kitchen (production infra) runs itself; you order what you want (image + scale), they cook it (provision + scale). You don't inspect their ovens (control plane).

Mechanics

How it works

  • You define the service: image, port, resources, min/max instances, probes.
  • Platform provisions capacity (Fargate/ACA host/Cloud Run managed) and starts instances.
  • Router sends traffic per service; probes gate readiness.
  • Autoscaler adjusts instance count by metric (CPU, memory, request count/concurrency).
  • Revisions enable fractional traffic + rollbacks.

Managed container lifecycle.

Deploy
Platform
Router
Autoscale
Traffic split
Hands-on

Examples

Cloud Run service shape (YAML)

Cloud Run service shape (YAML)
apiVersion: serving.knative.dev/v1
kind: Service
metadata: { name: checkout }
spec:
  template:
    spec:
      containers:
        - image: gcr.io/acme/checkout:1.2
          resources: { requests: { cpu: "1", memory: 512M } }
          startupProbe: { timeoutSeconds: 1 }
      containerConcurrency: 80   # scale on inflight requests

This is the whole operational contract: image, resources, concurrency → platform handles the rest.

Real world

In production

  • HTTP microservices with autoscaling and canary rollouts (Cloud Run/ACA).
  • Batch/long-running jobs on Fargate/ECS with independent scaling.
  • Mixed fleet: ECS for network-heavy or latency-sensitive when you need node affinity.
Guidelines

Best practices

  • Set startup/readiness/liveness probes — rollouts and scaling depend on them.
  • Pin revision traffic for canaries; eliminates (almost) all deploy risk.
  • Give every service a min-scaling floor for p95; scale-to-zero for best-effort queues.
  • Mount secrets via provider mechanisms, never baked into images.
  • Match containerConcurrency to handling capacity measured, not guessed.
Watch out

Common mistakes

  • Choosing EKS (K8s) because 'everyone says so' for a single stateless worker.
  • Missing health probes → autoscaler and LB flap blindly.
  • Forgetting idle min-scale keeps paying while no requests arrive.
  • Zero-starting a latency-sensitive API behind an LB with tight timeouts.
When things break

Debugging tips

  • Container loops restarting → check startupProbe first, then logs (side or log sink).
  • Scale doesn't follow load → verify the replica count metric and min/max bounds.
  • Traffic split flapping → ensure sticky/traffic-per-revision settings align.
  • Compare platform instance type vs your CPU/mem bounds when pricing surprises appear.
Interviews

Interview checkpoint

Practice

Hands-on lab

Deploy a Managed Container Service
40 min · intermediate
In progress
Objectives
  • Deploy a container image to a managed service
  • Configure scaling bounds and health probes
  • Do a weighted canary to a new revision

Deploy a Managed Container Service

40 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Which is fully scale-to-zero by default among these?

2

The platform-owned surface area in managed containers is:

Go deeper

Official documentation

Amazon ECS
docs
Azure Container Apps
docs
Cloud Run
docs