Run code without managing servers: deploy a Cloud Function, expose it over HTTP, trigger it from storage events and schedules, set environment variables and a service account, and read its logs.
A Cloud Function is code that runs on demand — Google spins up the environment, runs your function, then tears it down. Why: there is no server to provision, patch, or pay for while idle; you pay per invocation. Perfect for event-driven work and lightweight APIs with uneven traffic.
A tiny HTTP handler — save this as index.js
exports.hello = (req, res) => {
const name = req.query.name || 'world';
res.send('Hello, ' + name + '!');
};An HTTP-triggered function becomes a callable URL — the basis of a serverless API. Why "2nd gen": it is the current platform (built on Cloud Run) with better performance and concurrency. The deploy uploads your code, builds it, and returns the URL.
Deploy index.js as a public 2nd-gen HTTP function
gcloud functions deploy hello \
--gen2 --runtime nodejs20 \
--region us-central1 \
--source . --entry-point hello \
--trigger-http --allow-unauthenticatedThe deploy output prints the function's URL to curl.
Functions can run in response to events instead of HTTP — a file landing in Cloud Storage, a Pub/Sub message, a Firestore change. Why event-driven: a new upload runs your image-resizing function automatically, with no server polling for work.
Run the function whenever an object is finalized in a bucket
gcloud functions deploy on-upload \
--gen2 --runtime nodejs20 --region us-central1 \
--source . --entry-point onUpload \
--trigger-event-filters="type=google.cloud.storage.object.v1.finalized" \
--trigger-event-filters="bucket=learn-uploads-7f3k"To run a function on a timer (a cron job without a server), Cloud Scheduler calls it on a schedule. Why: nightly cleanups, hourly reports, periodic pings — all without keeping a VM running just to watch the clock. The schedule uses standard cron syntax.
Create a scheduler job that hits the HTTP function daily at 02:00
gcloud scheduler jobs create http nightly-hello \
--location us-central1 \
--schedule "0 2 * * *" \
--uri "https://us-central1-learn-gcp-7f3k.cloudfunctions.net/hello" \
--http-method GETEnvironment variables hold config (feature flags, endpoints) without hardcoding it. A service account gives the function least-privilege access to other Google Cloud services. Why: keep config outside the code, and let the function authenticate with no key files.
Deploy with an env var and a dedicated service account
gcloud functions deploy hello \
--gen2 --runtime nodejs20 --region us-central1 \
--source . --entry-point hello --trigger-http \
--set-env-vars GREETING=hello \
--service-account app-runner@learn-gcp-7f3k.iam.gserviceaccount.comWhen a function misbehaves you need its output. Why: the logs show each invocation, its result, and any errors — the fastest way to debug during development. They flow into Cloud Logging like everything else.
Show the most recent logs for the function
gcloud functions logs read hello --region us-central1 --limit 50