What is Serverless — Cloud Functions & Cloud Run in Google Cloud?

5 / 24

Google Cloud

Serverless — Cloud Functions & Cloud Run

Run event-driven functions (Cloud Functions) or any container serverlessly (Cloud Run).

Two serverless options, and on GCP the container one is usually the better default.

Cloud Functions is a single-task gadget that springs to life for one job and switches off. Cloud Run is a pop-up shop in a standard shipping container: you can stock it with anything (any container), it opens more units when queues form, and it shuts entirely when the street is empty — paying rent only while open.

Key Concepts

    Cloud Functions  a single function, one trigger
    Cloud Run        any container that listens on a port

Cloud Run is the standout. Because it runs a container, nothing constrains your language, dependencies or binaries — and the same image runs locally, in CI and in production.

    gcloud run deploy api --image gcr.io/proj/api:1.4

Concurrency is the property that changes the economics.

    Cloud Functions   one request per instance
    Cloud Run         up to 1000 concurrent requests per instance

An I/O-bound service handling 80 concurrent requests per instance needs a fraction of the instances, and you pay for instance time. This is the single most important Cloud Run setting, and leaving it at 1 is a common and expensive mistake.

Revisions and traffic splitting are built in.

    deploy --no-traffic --tag=canary
    update-traffic --to-tags canary=5     # then 50, then 100

Blue/green and canary with no extra tooling, and rollback is shifting traffic back.

Scale to zero means an internal service costs nothing overnight. The cost is a cold start on the next request — mitigated with minimum instances, or with startup CPU boost.

Two execution environments. Gen2 gives full Linux compatibility, more memory and CPU, and network file system support; gen1 starts marginally faster.

Cloud Run jobs run to completion rather than serving requests — batch work, migrations, scheduled tasks — which removes the old reason to keep a VM around.

Cloud Functions still fits small event handlers and glue, especially with Eventarc triggers, and 2nd gen is built on Cloud Run anyway.

Both authenticate as a service account with no key, and both should restrict ingress so only the load balancer or gateway can reach them.

What the interviewer is probing.1. "Why is Cloud Run usually the better default?" Probing: the container advantage. Stalls: "It is newer." Moves up: it runs any container, so language, dependencies and binaries are unconstrained and the same image runs locally, in CI and in production.

2. "What is the single most impactful Cloud Run setting?" Probing: concurrency. Stalls: "Memory." Moves up: concurrency — up to 1000 requests per instance, so an I/O-bound service needs a fraction of the instances; leaving it at 1 is expensive.

3. "How do you do a canary on Cloud Run?" Probing: revisions. Stalls: "Deploy twice." *Moves up:* deploy with --no-traffic and a tag, then shift a percentage of traffic to it and increase — rollback is shifting it back.

4. "How do you reduce cold starts?" Probing: the options. Stalls: "You cannot." Moves up: minimum instances to keep some warm, and startup CPU boost; scale to zero is the trade you are accepting.