Google Cloud Run: Serverless Containers & Scaling

Q: How is Cloud Run different from Cloud Functions?

Cloud Run deploys any container image and handles full HTTP services with your choice of language, runtime, and dependencies. Cloud Functions runs individual function snippets in supported runtimes, ideal for small event handlers. Cloud Run gives more control and portability (it's just a container); Functions is simpler for tiny event-driven logic. For most APIs, Cloud Run is the more flexible default.

Q: How do I reduce cold starts?

Set min instances above zero to keep a warm pool for latency-sensitive endpoints (this adds baseline cost). Also shrink your image, minimize startup work (lazy-load heavy dependencies), and keep the container's boot fast. For bursty but tolerant workloads, scaling from zero is fine and cheapest.

Google Cloud Run

Google Cloud Run is a serverless container platform: you deploy a container image and Cloud Run runs it with automatic scaling, including scaling to zero when idle. It's the sweet spot when you want serverless operations but the packaging model of containers — no Kubernetes to manage, but full control over your runtime and dependencies.

You pay per request and compute time, and the platform handles routing, scaling, and infrastructure. The design discipline is the usual serverless one: stateless request handling, with all state pushed to managed databases, caches, or object storage.

TL;DR

Great for APIs and web services packaged as containers.
Pay per request/compute time; scales to zero.
Design for stateless requests — externalize state.
Tune concurrency, min instances, and max instances for latency and cost.

Quick Example

Deploy straight from source — Cloud Run builds the container for you:

How Cloud Run Works

You build a container image (or deploy from source).
Deploy it as a service.
Cloud Run routes HTTP requests to instances.
Instances scale up and down automatically (to zero when idle).

The knobs you'll tune:

Concurrency — how many simultaneous requests one instance handles.
Min instances — keep some always warm to cut cold starts (raises baseline cost).
Max instances — cap scaling to protect downstream systems.

Common Use Cases

REST APIs
Webhooks
Internal microservices
Lightweight HTTP-triggered background processing (with care — see gotchas)

Best Practices

Stateless — never store state on local disk; use a managed DB/cache/object storage.
Clear request timeouts — keep handlers fast and reliable.
IAM-based auth for service-to-service calls; validate JWT/OIDC on public endpoints (see OAuth & OpenID Connect).
Reproducible builds — build in CI for environment parity.
Observability from day one — structured logs, metrics/alerts, tracing across services.

Common Mistakes

Relying on the local filesystem

Running long jobs inside a request

FAQ

How is Cloud Run different from Cloud Functions?

Cloud Run deploys any container image and handles full HTTP services with your choice of language, runtime, and dependencies. Cloud Functions runs individual function snippets in supported runtimes, ideal for small event handlers. Cloud Run gives more control and portability (it's just a container); Functions is simpler for tiny event-driven logic. For most APIs, Cloud Run is the more flexible default.

What concurrency setting should I use?

Cloud Run can send multiple concurrent requests to one instance (default up to 80), unlike Lambda's one-request-per-instance model. Higher concurrency improves efficiency and cost for I/O-bound services, but set it lower for CPU-heavy or memory-hungry workloads so instances aren't overwhelmed. Load-test to find the right value.

How do I reduce cold starts?

Set min instances above zero to keep a warm pool for latency-sensitive endpoints (this adds baseline cost). Also shrink your image, minimize startup work (lazy-load heavy dependencies), and keep the container's boot fast. For bursty but tolerant workloads, scaling from zero is fine and cheapest.

Can Cloud Run run background workers, not just HTTP services?

It's primarily request-driven, but you can run background-style work triggered by HTTP/Pub/Sub push, and Cloud Run Jobs exist for run-to-completion tasks. For long-running or queue-consuming workers, pair Cloud Run with Pub/Sub or Cloud Tasks rather than holding work inside a single request.