Building a Serverless Application on GCP with Cloud Functions & Cloud Run
A complete, practical guide for architects and developers: when to pick Cloud Functions vs Cloud Run, end-to-end architecture, secure connectivity to databases, CI/CD, cost optimization, and real-world use cases.
1. Introduction to Serverless Computing on GCP
Serverless computing is an operational model where the cloud provider manages server provisioning, scaling, and runtime. Developers deploy code or containers and pay for execution time and resources used — not idle servers. Key benefits include:
- Auto-scaling: scale to zero and up automatically with demand.
- Pay-per-use: cost aligns with actual traffic and compute duration.
- No infrastructure management: focus on code and business logic.
On Google Cloud Platform (GCP), the main serverless compute offerings are Cloud Functions, Cloud Run, and App Engine. This guide focuses on Cloud Functions and Cloud Run and how they complement each other in modern serverless architectures.
Author note: Throughout this article key terms like Cloud Functions, Cloud Run, Pub/Sub, Firestore, and Cloud SQL are linked back to CloudKnowledge for your reference.
2. Overview of Google Cloud Functions
Cloud Functions is GCP's Function-as-a-Service (FaaS) offering — event-driven single-purpose functions that respond to triggers like HTTP requests, Pub/Sub messages, Cloud Storage events, or other platform events. Cloud Functions supports multiple runtimes (Node.js, Python, Go, Java, and more) and is ideal for short-lived tasks and glue logic between services.
Key attributes:
- Event-driven triggers: HTTP, Pub/Sub, Cloud Storage, Firebase, Firestore, _and many more_.
- Short startup and execution times — best for single-purpose tasks.
- Automatic scaling per-trigger concurrency model.
Important note from GCP docs: Cloud Functions (v2) is built on Cloud Run and Eventarc; many users are advised to consider Cloud Run functions for advanced control.
3. Overview of Google Cloud Run
Cloud Run is a fully-managed container-based platform that runs stateless HTTP-driven containers. It is built on top of Knative and provides a serverless container runtime: you bring any container and Cloud Run handles provisioning, autoscaling (including scale-to-zero), and ingress.
Cloud Run is ideal for microservices, multi-endpoint APIs, and workloads needing custom runtimes or persistent language/process state for the duration of a request. Cloud Run allows you to configure concurrency, min/max instances, and memory/CPU per revision.
GCP documentation: Cloud Run is described as a fully managed application platform to run containers invocable via requests or events.
4. When to Use Cloud Functions vs Cloud Run
Choose between the two based on workload characteristics:
| Criteria | Cloud Functions (FaaS) | Cloud Run (Containers) |
|---|---|---|
| Deployment model | Upload function code | Deploy container image |
| Best for | Single-purpose event handlers, quick glue code | APIs, long-running requests, custom runtimes |
| Control | Less control over runtime | Full control of container environment |
| Startup model | Optimized for small cold starts | Flexible — can tune min instances to reduce cold starts |
| Scaling | Automatic per event | Automatic, configurable concurrency and min-instances |
Decision quick-check:
- If you need event-driven, tiny tasks — pick Cloud Functions.
- If you require custom binaries, multiple endpoints, or want to reuse local Docker workflows — pick Cloud Run.
Note: Google has been integrating functions into Cloud Run (Cloud Run functions) and recommends considering Cloud Run for unified capabilities.
5. Architecture of a Serverless Application on GCP
A typical serverless application on GCP has the following layers:
- Frontend — static hosting from Firebase Hosting or Cloud Storage + CDN.
- API / Business logic — Cloud Functions for event handlers or Cloud Run for multi-endpoint APIs.
- Message bus — Pub/Sub for asynchronous communication and event-driven decoupling.
- Database — Firestore (NoSQL), Cloud SQL (managed relational), or BigQuery for analytics.
- Security — Cloud IAM, Service Accounts, Secret Manager, Identity-Aware Proxy where needed.
- Observability — Cloud Logging, Cloud Monitoring, Cloud Trace, and Error Reporting.
Inline diagram (SVG):
6. Setting Up Your GCP Environment
Before writing code, prepare a GCP project and development environment:
- Create a GCP project in the Cloud Console.
- Enable the required APIs: Cloud Run, Cloud Functions, Artifact Registry, Cloud Build, Pub/Sub, Cloud SQL, and Secret Manager.
- Install and configure the
gcloudCLI and authenticate withgcloud auth loginand set your project:gcloud config set project PROJECT_ID. - Create Service Accounts for CI/CD and service-to-service authentication; grant least-privilege IAM roles.
- Optional: Create an Artifact Registry repository for container images.
# Example: enable APIs
gcloud services enable run.googleapis.com cloudfunctions.googleapis.com
artifactregistry.googleapis.com cloudbuild.googleapis.com pubsub.googleapis.com
sqladmin.googleapis.com secretmanager.googleapis.com
Pro tip: Use Infrastructure as Code (Terraform / Deployment Manager) to version control your infra. Use separate projects for dev/staging/prod.
7. Developing and Deploying a Cloud Function
We'll walk through a simple HTTP-triggered Node.js function that returns JSON. This example uses gcloud.
Sample function (Node.js)
// index.js
exports.helloHttp = (req, res) => {
const name = req.query.name || req.body?.name || 'World';
res.json({message:Hello ${name} from Cloud Functions!});
};
Deploy (HTTP trigger)
# Deploy with gcloud
gcloud functions deploy helloHttp
--entry-point=helloHttp
--runtime=nodejs18
--trigger-http
--allow-unauthenticated
--region=us-central1
Once deployed, test the endpoint and inspect logs with:
curl -X GET https://REGION-PROJECT.cloudfunctions.net/helloHttp?name=Shivi
gcloud functions logs read helloHttp --region=us-central1
Remember: Cloud Functions v2 uses Cloud Run underneath; if you need advanced routing or container features, consider Cloud Run.
8. Developing and Deploying a Cloud Run Service
Cloud Run expects a container image. We'll show how to containerize a simple Node/Express API, push it to Artifact Registry, and deploy to Cloud Run.
Dockerfile
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 8080
CMD ["node", "server.js"]
Build & push (Cloud Build & Artifact Registry)
# configure repo and build
gcloud artifacts repositories create my-repo --repository-format=docker --location=us-central1
gcloud auth configure-docker us-central1-docker.pkg.dev
gcloud builds submit --tag us-central1-docker.pkg.dev/PROJECT_ID/my-repo/my-api:1.0.0
Deploy to Cloud Run
gcloud run deploy my-api \
--image us-central1-docker.pkg.dev/PROJECT_ID/my-repo/my-api:1.0.0
--platform managed
--region us-central1
--allow-unauthenticated
--concurrency=80
--memory=512Mi
--min-instances=0
You can configure autoscaling, concurrency, CPU/memory, and traffic splitting. Cloud Run supports both public and private (authenticated) services.
Cloud Run is built on Knative and provides serverless container capabilities.
9. Integrating Cloud Functions and Cloud Run
Use Cloud Functions for lightweight event handlers and Cloud Run for heavier processing or APIs. Example flow:
- Upload file to Cloud Storage (e.g., images).
- Cloud Storage triggers a Cloud Function (event-driven).
- The Cloud Function publishes a message to Pub/Sub with file metadata.
- A Cloud Run service subscribes to Pub/Sub or is called (HTTP) by the Function to process the file (image resizing, ML inference).
Example: Cloud Function calling Cloud Run via HTTP (service-to-service authentication recommended):
// inside Cloud Function
const fetch = require('node-fetch');
const RUN_URL = process.env.CLOUD_RUN_URL;
const token = await google.auth.getClient({scope:'https://www.googleapis.com/auth/cloud-platform'}).getAccessToken(
);
await fetch(RUN_URL, {method:'POST', headers:{'Authorization':Bearer ${token}}, body:JSON.stringify(payload)});
Service-to-service authentication using Workload Identity or service account keys is recommended rather than unauthenticated endpoints.
10. Using Pub/Sub for Event Communication
Pub/Sub is the recommended message bus for decoupling microservices and building asynchronous, scalable architectures. Use topics for events (e.g., image.uploaded) and subscriptions consumed by Functions or Cloud Run subscribers.
Advantages:
- Durable message delivery and replay.
- Horizontal scaling of subscribers.
- At-least-once delivery semantics — design idempotent consumers.
Implementation note: Cloud Run can pull or receive push subscriptions; ensure proper acknowledgement and retry policies.
11. Connecting Serverless Apps with Databases
GCP offers options for storage and databases:
- Firestore (NoSQL) — real-time data, mobile/web sync.
- Cloud SQL (managed relational) — MySQL/Postgres/SQL Server.
- BigQuery — analytics and large-scale queries.
Serverless services (Cloud Run / Cloud Functions) do not live inside your VPC by default. To access private databases (e.g., Cloud SQL via private IP), configure a Serverless VPC Access connector or use Cloud SQL Auth proxy or Cloud SQL connectors.
Docs and codelabs show how to connect Cloud Run to Cloud SQL and how to configure Serverless VPC Access.
Best practices
- Use connection pooling (e.g., PgBouncer) for relational databases to avoid connection storms.
- Prefer Cloud SQL connection pools or the Cloud SQL Auth proxy / connectors for credential management.
- Use regional deployments for low latency between Cloud Run/Functions and Cloud SQL.
12. Securing Serverless Applications
Security is multi-layered. Key controls:
- Cloud IAM roles — least privilege for service accounts.
- Service-to-service authentication — use Workload Identity and short-lived tokens; avoid embedded static keys.
- Secret Management — store credentials and API keys in Secret Manager and grant access only to necessary service accounts.
- Network controls — Serverless VPC connectors for private database access; private services where required.
- Identity-Aware Proxy (IAP) — optional for controlling web access to services behind an auth gate.
- Audit logs — keep Audit Logging enabled for critical services and use log sinks for long-term retention.
Always rotate service account keys and use short-lived tokens wherever possible.
13. Managing Environment Variables and Configuration
Use environment variables for non-sensitive configuration. For secrets (DB passwords, API keys), use Secret Manager and bind access to service accounts. Cloud Run supports direct Secret Manager integration; Cloud Functions can read secrets at runtime.
# Example: set env var on Cloud Run
gcloud run services update my-api --set-env-vars=NODE_ENV=production
Avoid storing secrets in repo or inline configuration. Use Parameter Store / Secret Manager and give only required roles.
14. Monitoring, Logging, and Tracing
Use GCP's observability suite:
- Cloud Logging — centralized logs (structured logs help searchability).
- Cloud Monitoring — metrics, uptime checks, alerting policies.
- Cloud Trace & Cloud Profiler — performance traces and profiling.
- Error Reporting — aggregated error alerts for services.
Instrument services with OpenTelemetry or Cloud Trace SDKs to get distributed tracing across Cloud Run and Functions.
15. CI/CD for Serverless Applications
Automate builds and deploys with:
- Cloud Build for automated container builds and artifact publishing.
- Cloud Build triggers tied to Git branches or tags for automated deploys.
- GitHub Actions integrated with GCP for workflows teams already use.
Example pipeline outline for Cloud Run:
- Push code to main.
- Cloud Build builds container and pushes to Artifact Registry.
- Cloud Build deploys to Cloud Run (automated or manual approval for production).
- Run smoke tests and monitoring checks.
# cloudbuild.yaml (simplified)
steps:
name: 'gcr.io/cloud-builders/docker'
args: ['build','-t', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-api:$SHORT_SHA','.']
name: 'gcr.io/cloud-builders/gcloud'
args: ['run','deploy','my-api','--image','us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-api:$SHORT_SHA','--region=us-central1']
16. Versioning and Traffic Management
Cloud Run supports revisions (immutable deploy snapshots). Use revisions for canary releases and traffic splitting (e.g., 90% v1, 10% v2). For Cloud Functions, manage versions via source control and staged deployments.
# Example: split traffic between revisions
gcloud run services update-traffic my-api --to-revisions my-api-00001=90,my-api-00002=10 --region=us-central1
Design rollback strategies: automated health checks + scriptable rollback using gcloud or CI/CD pipelines.
17. Cost Optimization Techniques
Serverless helps reduce baseline costs, but optimization matters:
- Right-size memory/CPU per service — don’t over-allocate.
- Use min-instances on Cloud Run only for latency-sensitive endpoints to balance cold starts vs cost.
- Set appropriate timeouts to prevent runaway charges.
- Monitor usage with Billing Alerts and Cost Explorer.
- For heavy persistent workloads, compare Cloud Run vs GKE for cost trade-offs.
18. Handling Cold Starts and Performance Optimization
Cold starts occur when instances spin up from zero. Mitigation strategies:
- Use
min-instanceson Cloud Run to keep some warm capacity. - Reduce package size and dependency initialization time for functions and containers.
- Prefer faster runtimes for latency-critical endpoints.
- Use connection pooling and lazy initialization for DB clients.
Trade-off: min-instances increases cost slightly but improves latency predictability.
19. Real-World Use Cases
Image processing pipeline
Flow: User uploads image to Cloud Storage → Cloud Function triggers → publish to Pub/Sub → Cloud Run job consumes message and runs processing (resize, watermark), writes back to Cloud Storage.
REST API
Cloud Run hosts a REST API (multiple endpoints) with autoscaling and canary releases; use Cloud Armor for WAF-style protections and IAP for internal APIs.
IoT event ingestion
Devices push telemetry to Pub/Sub → Cloud Functions validate and write to Pub/Sub or BigQuery for analytics.
Chatbot backend
Use Cloud Run for conversational backends integrated with Firestore for session state. Consider GenAI/ML inference deployed in containers on Cloud Run for scalable inference.
20. Best Practices and Future Trends
- Event-driven design: decouple services with Pub/Sub for resiliency and scalability.
- Observability-first: instrument logs, metrics, and tracing from day one.
- Security-first: use least-privilege service accounts and Secret Manager.
- Design for idempotency: event replays can cause duplicate messages.
- Adopt container-first mindset: Cloud Run provides greater portability and rapid feature growth.
Emerging trends: tighter Cloud Run + Functions integration (Cloud Run Functions), serverless connectors for easier VPC access, and GenAI integration in serverless workflows (embedding inference in containers). Keep an eye on portability via Knative for multi-cloud patterns.
Additional resources & recommended reading
- CloudKnowledge — curated tutorials and deep-dives on GCP.
- Official GCP docs: Cloud Run docs.
- Cloud Functions & Cloud Run functions overview.
- Serverless VPC Access and Cloud SQL connection guides.
- Hands-on codelabs for connecting Cloud Run to Cloud SQL.
Shivam Tiwari
Website: http://Cloudknowledge.in
Leave a Reply