Cloud Functions
Cloud Functions is Google's function-as-a-service platform. You upload a function written in Python, Node.js, Go, Java, Ruby, PHP, or .NET; the platform runs it in response to an HTTP trigger or an event from another Google Cloud service.
First vs Second Generation
Gen 1 runs at a concurrency of one — an instance serves a single request at a time (instances are reused between requests, not spun up per request). Gen 2 — also called Cloud Run functions in current documentation — runs on Cloud Run infrastructure and inherits its concurrency model, longer timeouts (up to 60 minutes for HTTP), larger memory limits (up to 32 GB), and broader event support via Eventarc. Prefer gen 2 for new functions unless a specific gen 1 constraint applies; gen 1 is legacy but still supported.
Triggers
- HTTP triggers: a public or private HTTPS endpoint.
- Pub/Sub: messages published to a topic. Delivery is at-least-once.
- Cloud Storage: object creation, deletion, or metadata update events.
- Firestore: document create/update/delete events.
- Eventarc: events from 90+ Google Cloud sources and Cloud Audit Logs.
- Cloud Scheduler: scheduled invocation via Pub/Sub or HTTP.
Cold Starts
A cold start occurs when a new instance is initialized: loading the runtime, importing dependencies, executing top-level code. Cold starts add 200ms to several seconds of latency. For background or event-driven functions, cold starts are usually acceptable. For user-facing HTTP endpoints, set minimum instances to eliminate them. Reduce cold start duration by keeping functions small, minimizing top-level imports, and choosing faster-starting languages like Go or Node.js.
Cloud Functions vs Cloud Run
At gen 2, the two services share infrastructure. The difference is in what you give the platform: Cloud Functions accepts source code and handles the build for you; Cloud Run accepts a container image that you build.
Choose Cloud Functions (gen 2) for a single function in a supported runtime where you do not need a custom base image and want Google to handle the build.
Choose Cloud Run when you need a custom container image, run a full HTTP server, want to test the production artifact locally, or are deploying anything larger than a single function.
Idempotency
Pub/Sub and Storage-triggered functions receive at-least-once delivery — the same event may arrive more than once. Functions must be idempotent: processing an event twice has the same effect as once. Track processed event IDs in Firestore or Cloud SQL, or structure operations as upserts rather than inserts.
In 2024 Google renamed the entire product to Cloud Run functions: gen 2 carries the new name outright, and gen 1 is now "Cloud Run functions (1st gen)". The docs live under Cloud Run, reflecting that gen 2 runs on Cloud Run infrastructure. This course keeps the shorter classic name; you will see both in the wild — treat them as identical.
- Functions that grow into large applications — move them to Cloud Run when the codebase outgrows a few hundred lines.
- Not handling event deduplication — missing idempotency causes duplicate inserts, double charges, or duplicate notifications.
- Not setting timeout and memory limits explicitly.
- Ignoring cold start latency for user-facing endpoints without setting minimum instances.
- Deploying gen 1 for a new project — gen 2 (Cloud Run functions) is the right default, and gen 1, while still supported, is no longer recommended for new work.
- Storing secrets as plain environment variables — mount them from Secret Manager so they do not appear in deployment configs or build logs.
- Always use gen 2 for new deployments.
- Keep functions small and single-purpose.
- Write all event-triggered functions to be idempotent from day one.
- Load secrets from Secret Manager, not via embedded environment variable values.
- Set explicit timeouts, memory allocations, and instance limits.
- Test locally with the Functions Framework before deploying.
- Use minimum instances for user-facing paths where cold start latency is unacceptable.
Knowledge Check
Which generation of Cloud Functions should all new deployments use?
- Gen 1, for maximum compatibility with existing tooling
- Gen 2
- Either — there is no meaningful difference between generations
- Gen 3, the most recent release
For a user-facing HTTP Cloud Function, how do you eliminate cold start latency?
- Choose a compiled language like Go or Java
- Increase the function's memory allocation
- Set minimum instances to keep at least one instance always warm
- Enable concurrency mode to handle multiple requests per instance
What does "at-least-once delivery" mean for Pub/Sub-triggered Cloud Functions?
- Every message is guaranteed to arrive exactly once
- The same event may be delivered more than once, so functions must be idempotent
- Messages arrive in the order they were published
- At least one message per minute is guaranteed to arrive, sustaining a steady minimum throughput rate
What is the main difference between Cloud Functions gen 2 and Cloud Run?
- Gen 2 runs on its own infrastructure that is fully separate from the Cloud Run platform
- Gen 2 accepts source code and builds it; Cloud Run takes a container image you build yourself
- Cloud Run cannot handle event-driven workloads and must be invoked through HTTP requests
- Gen 2 supports more programming languages and runtime versions out of the box than Cloud Run ever can
What does it mean for a Cloud Function to be idempotent?
- It is guaranteed to run only once per trigger event
- It returns the same output for the same input
- Processing the same event twice produces the same final state as processing it once
- It cannot be invoked concurrently by multiple triggers, since the platform serializes every invocation
You got correct