What Is Cloud Functions?
Cloud Functions is GCP's Functions-as-a-Service (FaaS) platform: you write a single function in a supported language (Node.js, Python, Go, Java, .NET, Ruby, PHP), and GCP handles everything else — provisioning, scaling, and tearing down the execution environment per invocation. Unlike Cloud Run, where you package and deploy an entire container, Cloud Functions only needs your source code and a declared entry point; the platform builds the container for you using Buildpacks, making it the fastest path from a code snippet to a running, scalable HTTP or event-driven endpoint.
Cricket analogy: Cloud Functions is like a specialist death-bowling super-sub who's called in just to bowl the final over in a crunch T20 finish, then leaves — you don't manage his entire training camp, you just define the exact task and he's there for that specific moment.
Trigger Types: HTTP and Event-Driven
Cloud Functions supports two broad trigger categories. HTTP functions respond directly to HTTP requests and are useful for webhooks or lightweight APIs. Event-driven functions (2nd gen, built on Eventarc) respond to events from over 90 GCP sources — a new object uploaded to Cloud Storage, a message published to Pub/Sub, a Firestore document write, or an audit log entry — letting you build reactive pipelines like automatically generating a thumbnail whenever an image lands in a Storage bucket, without polling or writing custom event-listening infrastructure.
Cricket analogy: HTTP functions are like a player responding directly when a journalist asks a question at a press conference, while event-driven functions are like the DRS system automatically reviewing every lbw appeal the instant the umpire's finger goes up, without anyone manually requesting it.
1st Gen vs 2nd Gen and Cold Starts
Cloud Functions 2nd generation is built on top of Cloud Run and Eventarc, giving it longer request timeouts (up to 60 minutes for HTTP versus 9 minutes in 1st gen), larger instance sizes, concurrency support (multiple requests per instance, unlike 1st gen's one-request-per-instance model), and traffic splitting between revisions. Because 2nd gen functions are ultimately Cloud Run services under the hood, they inherit the same cold-start behavior — an idle function scaled to zero instances incurs startup latency on the next invocation, which you can mitigate with a minimum instance count just as you would for a Cloud Run service.
Cricket analogy: 2nd gen functions are like a franchise upgrading from single-format-only contracts (1st gen, one request per instance) to multi-format player deals that let a star handle both T20 and ODI duties concurrently (concurrency), all while still needing a warm-up net session before a long-idle player is match-fit again (cold start).
# main.py - a 2nd gen Cloud Function triggered by a Cloud Storage upload event
import functions_framework
from cloudevents.http import CloudEvent
@functions_framework.cloud_event
def generate_thumbnail(cloud_event: CloudEvent) -> None:
data = cloud_event.data
bucket = data["bucket"]
name = data["name"]
print(f"New object uploaded: gs://{bucket}/{name}")
# ... download, resize, and upload a thumbnail here ...
# Deploy with:
# gcloud functions deploy generate-thumbnail \
# --gen2 \
# --runtime=python312 \
# --region=us-central1 \
# --source=. \
# --entry-point=generate_thumbnail \
# --trigger-bucket=my-uploads-bucket \
# --memory=512MiBecause Cloud Functions 2nd gen is built on Cloud Run, many concepts transfer directly: revisions, traffic splitting, concurrency, and minimum instances all work the same way, so skills learned for one platform largely carry over to the other.
Cloud Functions execution is stateless between invocations — global variables can persist across warm invocations of the same instance as an optimization, but you must never rely on this for correctness, since a new instance (with fresh state) can be created at any time, especially during scale-out.
- Cloud Functions is a FaaS platform where you supply only source code; GCP builds and runs the container automatically.
- HTTP functions respond to direct requests; event-driven functions react to over 90 GCP event sources via Eventarc.
- 2nd gen functions are built on Cloud Run and Eventarc, offering longer timeouts, larger instances, and concurrency.
- 1st gen functions handle one request per instance; 2nd gen supports multiple concurrent requests per instance.
- Cold starts occur when an idle function scales to zero and must start a new instance for the next invocation.
- Minimum instance counts mitigate cold starts at the cost of paying for idle capacity, same as Cloud Run.
- Functions are stateless between invocations; never rely on in-memory state persisting across instances.
Practice what you learned
1. What is the key difference between deploying to Cloud Run versus Cloud Functions?
2. What technology underlies Cloud Functions 2nd generation event-driven triggers?
3. What is a key capability difference between 1st gen and 2nd gen Cloud Functions?
4. Why should you avoid relying on global in-memory state persisting across Cloud Functions invocations?
5. What is the benefit of an event-driven Cloud Function triggered by a Cloud Storage upload?
Was this page helpful?
You May Also Like
Cloud Run Basics
Learn how Cloud Run runs stateless containers as fully managed, autoscaling, pay-per-request services on GCP.
Compute Engine Basics
Learn how Google Compute Engine provisions virtual machines, machine types, disks, and networking so you can run workloads on GCP infrastructure.
Google Kubernetes Engine Basics
Learn the fundamentals of GKE, Google's managed Kubernetes service, including clusters, nodes, workloads, and Autopilot mode.