Choosing where to run a container

Many ways to run the same image

Once your app is a container image, you have choices. The image does not change; what changes is how much the cloud manages for you, how you pay, and how much control you have. More control usually means more work. The right answer depends on your team and your traffic more than on technology fashion.

Serverless containers in more detail

Cloud Run and Azure Container Apps scale on incoming requests and can scale to zero, so a service with no traffic costs little or nothing. The trade-off is a cold start: the first request after a quiet period waits while a container starts. If that delay matters, keep a minimum number of instances warm, which costs some money all the time.

ECS on Fargate is also serverless in the sense that you manage no servers, but a service keeps its desired number of tasks running all the time. It does not wake up on a request the way Cloud Run does. You can scale it with metrics or schedules, including down to zero tasks at night.

gcloud run deploy orders-api --image asia-south1-docker.pkg.dev/shop-prod/apps/orders-api:1.0.0 --region asia-south1 --min-instances=1 --max-instances=20

Decision factors

1. Team size and skills: Kubernetes needs people who understand networking, upgrades and its many tools. A team of three developers rarely has that time.
2. Number of services: two or three services are easy anywhere. Thirty services with shared policies, service-to-service security and custom tooling start to benefit from Kubernetes.
3. Traffic pattern: spiky or quiet traffic suits scale to zero. Steady, heavy traffic can be cheaper on reserved nodes.
4. Scale to zero: needed for many small internal tools and test environments. Cloud Run and Container Apps do it natively.
5. Cost: compare the whole bill, including load balancers, the Kubernetes control plane fee, idle capacity and the people time to run it.
6. Portability: a container image runs anywhere. Kubernetes manifests move between clouds; Cloud Run settings do not, but they are small to rewrite.

A Bengaluru startup grows up

A two-person startup in Bengaluru builds a home-services booking app. They have one API and one worker, little traffic at night and spikes on weekends. They choose Cloud Run in asia-south1: no servers, scale to zero overnight, and a monthly bill small enough to sit inside their credits. Deploys are one gcloud command from CI.

Two years later they have 20 engineers and 28 services, need network policies between services, a service mesh for mutual TLS, and background jobs with GPUs for image checks. Two engineers now specialise in the platform. They move to a regional GKE cluster in Autopilot mode, where the image-check jobs simply request GPUs in their pod specs. The same images are deployed with Kubernetes manifests. Simple, low-traffic internal tools stay on Cloud Run, because there is no reason to move them.