India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Google Cloud Run Serverless Development: Services, Jobs & Functions
Cloud Run is Google Cloud's fully managed serverless platform for running containers as HTTP services, batch jobs or functions, scaling automatically from zero. NTSPL builds Cloud Run applications wired together with Eventarc, Cloud Tasks and Cloud Scheduler, tuning concurrency, minimum instances and billing mode so Indian consumer and marketplace apps handle peaks without paying for idle servers.
Google Cloud services in scope
The Problem Cloud Run services and Cloud Run jobs Solve
Serverless on Google Cloud goes wrong in predictable ways. Teams deploy each endpoint as a separate function and end up with 120 deployables and no shared code path. Others leave concurrency at 1 copied from an old functions setup, so a lunch-hour spike spins up 900 instances that exhaust Cloud SQL connections. Webhooks from aggregators or payment gateways get processed inline, and when a downstream POS or SMS gateway slows, request timeouts cascade back to the caller. Cold starts on large Java images then add seconds to the first order of the morning.
NTSPL designs Cloud Run around the shape of the work. Synchronous APIs are Cloud Run services with concurrency set from load tests and minimum instances only on customer-facing paths. Anything that can wait goes onto Cloud Tasks or Pub/Sub, with Eventarc routing storage, audit-log and Pub/Sub events to the right handler. Scheduled and batch work runs as Cloud Run jobs triggered by Cloud Scheduler, so nothing sits idle waiting for cron.
When Cloud Run Is the Right Runtime (and When GKE or Compute Engine Fit Better)
Signals that point to serverless applications on Google Cloud
- API traffic varies more than 10x between off-peak and peak hours, such as lunch and dinner ordering or evening browsing.
- Servers or VMs run 24x7 to host services that are idle for more than 60% of the day.
- Webhook bursts from aggregators, payment gateways or job boards cause timeouts because they are processed inline.
- Your team spends more time patching base images and Kubernetes nodes than shipping features for a handful of services.
- Legacy Cloud Functions need upgrading to second-generation runtimes or tighter integration with Cloud Run features.
When a different approach is better
- Workloads needing persistent local disks, privileged containers or custom kernel modules belong on GKE Standard or Compute Engine.
- A large platform with dozens of services needing a shared service mesh, operators and StatefulSets is better served by GKE Autopilot.
- Steady, near-constant CPU load around the clock, such as stream processors, is often cheaper on committed Compute Engine or GKE capacity than instance-based Cloud Run.
Serverless Building Blocks: Cloud Run Services, Jobs and Functions with Eventarc, Cloud Tasks and Cloud Scheduler
| Service | Role in the architecture | Choose it when |
|---|---|---|
| Cloud Run services | Run stateless containers behind an HTTPS endpoint, scaling instances on concurrent requests from zero to a configured maximum, with traffic splitting between revisions. | You have an HTTP or gRPC API, web front end or webhook receiver with variable traffic. |
| Cloud Run jobs | Run containers to completion as one or many parallel tasks, each with an index, retries and a task timeout, without serving requests. | Work is batch or scheduled, such as nightly reports, data imports or bulk notifications, and should stop when finished. |
| Cloud Run functions | Source-based functions, formerly Cloud Functions, built and deployed as Cloud Run services with event triggers and the same scaling and networking options. | A single-purpose handler for an event, such as an uploaded file or Pub/Sub message, is easier to maintain as a function than a container. |
| Eventarc | Routes events from Google Cloud sources, Cloud Audit Logs, Pub/Sub and third parties to Cloud Run targets in CloudEvents format with filtering. | Services should react to things happening, such as an object finalized in a bucket, without polling or custom glue code. |
| Cloud Tasks | Managed queues that dispatch HTTP requests to Cloud Run with per-queue rate limits, concurrency caps, retries with backoff and scheduled delivery times. | A downstream system can only take a limited rate, or a request should be retried reliably without the caller waiting. |
| Cloud Scheduler | Managed cron that triggers Cloud Run jobs, HTTP endpoints or Pub/Sub topics on a schedule with time-zone support, including Asia/Kolkata. | Recurring work is still driven by crontab on a VM that runs 24x7 for a few minutes of actual work. |
Event-driven Cloud Run application with queued side effects
Event-driven Cloud Run application with queued side effects
Customers call a global external Application Load Balancer that routes through a serverless NEG to a Cloud Run service in asia-south1, which writes the transaction to the database and enqueues side effects such as POS pushes, SMS or partner calls to Cloud Tasks. Eventarc delivers storage and Pub/Sub events to Cloud Run functions, and Cloud Scheduler starts Cloud Run jobs for reports and bulk work.
Select any component
Event-driven Cloud Run application with queued side effects: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Cloud Run Engineering Decisions: Concurrency, Cold Starts, Billing Mode and Async Offload
Concurrency and maximum instances
Cloud Run's default concurrency of 80 is a starting point, not an answer. We load-test each service and set concurrency where p95 latency starts to bend, typically 20-40 for CPU-heavy Java or Python and 100-250 for I/O-bound Node.js or Go. Maximum instances is then derived from the database: if Cloud SQL allows 500 connections and each instance pools 10, the API caps at around 45 instances, leaving headroom for jobs and admin tools.
Cold starts and minimum instances
Minimum instances cost money while idle, so we set them only on customer-facing services and only for the hours that matter, adjusted by Cloud Scheduler before lunch or evening peaks. Startup CPU boost, smaller distroless images, lazy initialization of SDK clients and avoiding heavy frameworks on hot paths usually cut cold start from 3-4 seconds to under one second. Background handlers keep minimum instances at zero.
Request-based or instance-based billing
Request-based billing charges CPU only while requests are processed and adds a per-request fee; it suits spiky APIs. Instance-based billing keeps CPU allocated for the instance lifetime with no per-request fee, which suits services doing background work after responding or sustaining high, steady traffic. We compare both using a week of real request logs, since busy services above roughly 50-60% utilization often become cheaper on instance-based billing.
Cloud Tasks versus Pub/Sub for offload
Cloud Tasks fits when one specific handler must be called with explicit control over rate, concurrency, scheduled delivery and per-task deduplication, such as pushing orders to store POS terminals at 20 per second. Pub/Sub fits fan-out to many subscribers and very high throughput where the publisher should not know the consumers. Both retry; we set dead-letter handling for each so failed messages are inspected, not lost.
Service granularity and functions versus services
We group endpoints that share a data model and release cadence into one Cloud Run service, rather than one function per route, to keep deployables under control and share connection pools. Cloud Run functions are used for genuinely isolated event handlers, such as thumbnailing or webhook fan-out. Since functions now deploy as Cloud Run services, moving a handler between the two models later is straightforward.
How NTSPL Ships an Event-Driven Application on Cloud Run
Containerize and baseline
Package each service with a slim base image, add health and readiness behaviour, and record cold-start and steady-state latency.
Concurrency and scaling tests
Load-test each service at 1x, 5x and 10x expected peak to choose concurrency, CPU, memory and instance limits.
Async offload with Cloud Tasks and Eventarc
Move webhook processing, notifications and partner calls onto queues and event triggers, with dead-letter handling.
Edge and private networking
Place services behind a global Application Load Balancer with serverless NEGs, restrict ingress, and configure Direct VPC egress for database access.
Jobs and schedules
Replace VM crontabs with Cloud Scheduler triggering Cloud Run jobs, using task parallelism for bulk work.
Progressive rollout
Deploy new revisions with tagged URLs, shift traffic in 10%, 50% and 100% steps, and keep the previous revision ready for instant rollback.
What you receive
Securing Cloud Run: Ingress Settings, Invoker IAM, Service Identity and Direct VPC Egress
Cloud Run's main exposures are services left publicly invokable on their run.app URL, every service sharing the default compute service account, and secrets baked into images or plain environment variables. NTSPL restricts ingress so only the load balancer or internal callers reach services, requires IAM invoker permission for service-to-service calls, gives each service its own identity, and mounts secrets from Secret Manager with version pinning.
- Ingress setting internal-and-cloud-load-balancing so Cloud Armor cannot be bypassed via the run.app URL
- roles/run.invoker granted per calling identity, with authenticated Cloud Tasks and Eventarc push
- Dedicated service account per service and function, never the default compute account
- Secret Manager references with pinned versions and rotation, not secrets in images
- Binary Authorization policy for Cloud Run so only attested images are deployed
Cloud Run Pricing Levers: Request-Based Billing, Concurrency, Min Instances and Committed Use
Cloud Run bills vCPU-seconds and GiB-seconds of memory, plus a per-request fee under request-based billing, with a monthly free tier per billing account. Minimum instances incur idle charges, and higher concurrency directly reduces cost because more requests share one instance. Cloud Tasks bills per operation, Cloud Scheduler per job beyond a small free allowance, and Eventarc per event for non-Google sources.
- Raise concurrency from load-test results to cut instance-seconds by 30-60% on I/O-bound services
- Schedule minimum instances only for peak hours instead of 24x7
- Switch steady, busy services to instance-based billing and apply Cloud Run committed use discounts
- Right-size CPU and memory per service; many Node.js and Go services run well on 1 vCPU and 512 MiB
- Move chatty polling to Eventarc triggers so instances run only when events occur
Cloud Run services vs Cloud Run functions vs Cloud Run jobs: which should I use?
Pick by how the code is invoked and packaged. Use Cloud Run services for anything answering HTTP or gRPC requests, especially multi-endpoint APIs and web apps where you control the container, framework and dependencies. Use Cloud Run functions when you want to deploy source code for a single event handler, such as a Pub/Sub message or a file upload, and let Google build the container; since functions now run on Cloud Run, they get the same networking, scaling and revision features. Use Cloud Run jobs when work has a start and an end, does not serve requests, and may need to fan out into parallel tasks, such as reconciliations or bulk messaging triggered by Cloud Scheduler. Most applications use all three.
Key facts about serverless applications on Google Cloud
Serverless Applications on Google Cloud in Practice
3 serverless applications scenarios from Quick-service restaurants (QSR), Recruitment and HR-tech, Hyperlocal home-services marketplace: the starting position, the services chosen, the architecture, the rollout and the measured outcome.
QSR chain processes 6x lunch-hour orders with zero dropped POS pushes
Job portal parses 400,000 resumes a day on Cloud Run with no idle servers
Home-services marketplace cuts missed appointments 42% with Cloud Tasks reminders
Agritech firm delivers 6 a.m. crop advisories to 2.1 million farmers on time
News publisher absorbs 14x breaking-news spikes with a 94% Cloud CDN hit ratio
K-12 e-learning company halves video delivery cost across 180,000 lessons
Loyalty fintech handles festive redemption peaks on Cloud SQL with Memorystore
EV charging network connects 9 roaming partners and settles sessions in near real time
Pharmacy chain exposes e-prescription APIs and live stock across 720 stores
Serverless Applications on Google Cloud: Frequently Asked Questions
How is Cloud Run billed, and is it cheaper than a VM?
Cloud Run bills per vCPU-second and GiB-second of memory used by instances, plus a per-request charge under request-based billing, after a monthly free tier. For services idle much of the day, it is typically 40-70% cheaper than an always-on VM because it scales to zero. For services busy around the clock, instance-based billing with committed use discounts narrows or reverses the difference, so we model both.
What happened to Cloud Functions?
Cloud Functions became Cloud Run functions in 2024. Functions deployed from source are now built and run as Cloud Run services, so they share Cloud Run's scaling, concurrency, networking and revision management. Existing first-generation functions keep working, but we recommend moving to the current model to gain concurrency and longer timeouts, typically with small code changes for event signatures.
How do we migrate a monolith on VMs to Cloud Run?
Start by containerizing the monolith unchanged and running it on Cloud Run behind the same load balancer, which proves statelessness and session handling. Then extract the busiest or most change-prone modules into separate services, moving background work onto Cloud Tasks and cron jobs onto Cloud Scheduler with Cloud Run jobs. File writes to local disk must move to Cloud Storage first, as instance filesystems are ephemeral.
Can Cloud Run keep customer data within India?
Yes. Cloud Run, Cloud Tasks, Cloud Scheduler and Eventarc are available in Mumbai (asia-south1) and Delhi (asia-south2). Deploying services, queues and triggers in these regions, with databases and buckets pinned by organization policy, keeps processing and storage in India for DPDP Act 2023 commitments. A global load balancer in front still terminates TLS at Google's edge before forwarding to the India region.
How do we stop Cloud Run from overwhelming our database during a spike?
Set maximum instances based on database connection limits and per-instance pool size, raise concurrency so fewer instances serve the same load, and use Cloud SQL Managed Connection Pooling or a pooler where needed. Writes that do not need to be synchronous should go through Cloud Tasks with a dispatch rate the database can sustain, so spikes queue instead of failing.
How do Eventarc and Pub/Sub differ for triggering Cloud Run?
Pub/Sub is the messaging service; Eventarc is the routing layer that delivers events from many sources, including Cloud Storage, Cloud Audit Logs and Pub/Sub topics, to Cloud Run in CloudEvents format with filtering. Many Eventarc triggers use Pub/Sub as transport underneath. Use Eventarc when reacting to platform events; publish to Pub/Sub directly when your own services emit domain events.