Cloud Run is Google Cloud’s managed platform for running containerized applications that scale automatically, including all the way down to zero.

The simple definition

Cloud Run is a fully managed compute service. Fully managed means Google operates the machines, the operating system patches, the networking, the load balancing, and the scaling logic. You bring only your application, packaged as a container image. Cloud Run takes that image, runs it, gives it a secure web address, and keeps it healthy.

Because the unit you deploy is a standard container, you can use almost any programming language, framework, or library. A team that writes in Java, Python, Go, Node.js, .NET, Rust, or even an older language that still works inside a container can run it on Cloud Run. If it can listen for network requests inside a container, Cloud Run can host it.

Why it was needed

For many years, running an application meant managing machines. Teams rented virtual machines, installed software, applied security patches, configured load balancers, and watched dashboards at night to see whether the machines were overloaded. This work is necessary but it is not what makes a product special. It is plumbing.

Containers made applications portable, because a container carries the application together with everything it needs to run. Orchestration systems such as Kubernetes made it possible to run many containers across many machines, but they brought a new kind of complexity: clusters, nodes, upgrades, and a large vocabulary. Early serverless function platforms removed that complexity, but they asked developers to fit their code into a special function shape and often limited the language or runtime.

Cloud Run was designed to sit in the happy middle. You keep the freedom of containers, so any language and any library works. You also keep the ease of serverless, so there are no clusters to manage and no machines to size in advance. It is built around an open request-serving model that is compatible with the Knative serving API, which means the ideas you learn here are not locked into a mystery system.

What you get out of the box

When you deploy a web application to Cloud Run, you receive a secure HTTPS address without buying or installing a certificate. You receive automatic load balancing across the copies of your application. You receive request logs and basic metrics without installing agents. You receive identity-based access control through Google Cloud’s identity system. You can also attach your own domain name, place a global load balancer in front, or connect to private networks when you need them.

Who uses it and for what

Cloud Run is popular for websites, application programming interfaces, mobile app backends, webhook receivers, internal tools, data processing steps, scheduled batch work, and machine learning inference. Startups like it because they can launch with almost no operations work. Large companies like it because it gives product teams a safe, standard way to ship services without opening a ticket for every virtual machine.

Two ideas sit under everything in Cloud Run: the container and the serverless operating model.

What a container really is

A container is a lightweight, isolated package that holds your application code, its libraries, its settings, and a minimal slice of an operating system’s user space. It runs on a shared operating system kernel, so it starts much faster than a full virtual machine. The same container behaves the same on your laptop, in a test environment, and in production, which removes the classic excuse that it works on my machine.

The recipe that describes how to build a container is called a build file, and the result of following the recipe is a container image. An image is a read-only snapshot. When Cloud Run starts your image, the running copy is called a container instance. You can start many instances from one image, just like you can bake many cakes from one recipe.

Where images are stored

Images live in a registry. On Google Cloud, the recommended registry is Artifact Registry, which stores images, tracks versions, and can scan them for known security problems. Cloud Run pulls the image from the registry whenever it needs to start a new instance, so a reliable registry in the same region helps startup speed.

What serverless means

Serverless does not mean there are no servers. It means you do not think about servers. The provider decides where your code runs, how many machines are needed, and when to add or remove them. Three promises usually come together. The first is automatic scaling. The second is no machine management. The third is pay for what you use instead of paying for what you reserve.

The stateless rule

Cloud Run instances are stateless. That means any single instance can disappear at any time, and a new one can appear somewhere else. You should never rely on an instance remembering something between requests as your only copy of the truth. Data that matters belongs in a database, a storage bucket, or a cache service outside the instance.

Instances do have a temporary writable file area, but it lives in memory and vanishes when the instance stops. It is fine for scratch work, such as unpacking an uploaded file before processing it. It is not a place to keep user data.

Three styles of running software compared

Learn these eight words well and the rest of Cloud Run becomes easy to read.

How the words fit together

Picture a restaurant chain. The service is the restaurant brand. A revision is one version of the menu and kitchen setup. An instance is one open branch serving customers right now. Concurrency is how many tables one branch can handle at once. When the brand updates its menu, it does not edit the old menu; it prints a new one, which is a new revision, and slowly sends customers to the new branches.

The container contract

Cloud Run expects your container to follow a few simple rules. It must run a web server that listens on the network port Cloud Run provides through an environment variable, which is 8080 by default. It must listen on all network interfaces, not only on the local loopback address. It must start quickly enough to become ready before the startup time limit, which is a few minutes at most. It must handle a polite shutdown signal, which Cloud Run sends shortly before stopping an instance, so that in-flight work can finish.

Following the contract is usually easy because most web frameworks already behave this way. Problems appear when an application binds only to the local address, hard codes a port number, or takes too long to boot because it loads huge files or contacts many systems during startup.

Cloud Run is not only for web servers. It offers different resource types for different shapes of work.

A common beginner error is to force every task into a web service. Cloud Run offers four resource types, and picking the right one makes designs simpler and cheaper. Think of the question this way: does the work start because a request arrives, because a schedule fires, because a message sits in a queue, or because a small event needs a small reaction?

Inside a job

A job is defined by the container to run, how many tasks to create, how many may run at the same time, how many times a failed task may be retried, and how long a task may run. Each task receives its own index number, so your code can decide which slice of the data it owns. For example, with one hundred tasks and one million records, task number seven might process records seventy thousand to seventy nine thousand nine hundred ninety nine. This is how a job turns one large chore into many small parallel ones without any coordination code.

Choosing quickly

A Cloud Run application is a small set of parts that cooperate: an image, a service, revisions, instances, a front door, and the Google Cloud services around them.

The big picture

Every request to a Cloud Run service passes through Google’s managed front end. This front end terminates the secure connection, checks who is allowed in, and picks an instance to handle the request. Behind it, the platform keeps a pool of instances for each revision that is receiving traffic. Your code inside an instance talks to other Google Cloud services, such as databases, queues, and storage, using the identity you assigned.

flowchart LR
  U["Users and client apps"] --> FE["Managed front end"]
  FE --> AUTH["Identity and ingress checks"]
  AUTH --> R["Service with traffic rules"]
  R --> V1["Revision A instances"]
  R --> V2["Revision B instances"]
  V1 --> DB["Database"]
  V1 --> ST["Cloud Storage"]
  V2 --> Q["Pub/Sub topic"]
  V2 --> SM["Secret Manager"]
        

The diagram shows the shape of the system. Users reach the managed front end first. The identity and ingress checks decide whether the request may continue. The service holds the traffic rules and divides requests between revisions. Each revision owns its own instances, and each instance reaches the supporting services it needs.

Component by component

The control plane and the data plane

Architects like to separate a platform into two planes. The control plane is where you give instructions: creating a service, deploying a revision, changing a setting. The data plane is where real traffic flows: requests entering, instances running, responses leaving. Keeping these planes separate matters for reliability. A problem in the control plane, such as a slow deployment tool, does not stop live requests that are already flowing through the data plane.

Understanding the life of one request, and the life of one instance, explains most of the behavior that surprises newcomers.

The journey of a single request

sequenceDiagram
  participant C as Client
  participant F as Front end
  participant I as Instance
  participant D as Database
  C->>F: Send request
  F->>F: Check identity and ingress
  F->>I: Route to instance with free capacity
  I->>D: Read or write data
  D-->>I: Result
  I-->>F: Response
  F-->>C: Response and logged metrics
        

The life of an instance

An instance moves through simple stages. First it starts: the image is fetched and the container begins running. Next it becomes ready: the application opens its port and the platform begins sending traffic. Then it serves traffic for as long as demand continues. When demand drops, the platform may keep the instance around for a while in case more requests come, which helps avoid repeated cold starts, but it makes no promise about how long. Finally, the platform stops the instance by sending a polite shutdown signal and giving the application a short grace period to finish work and close connections.

What happens between requests

With the default billing setting, the platform reduces the CPU available to an idle instance as soon as the last request finishes. This is how you avoid paying for idle time, but it has a consequence: background threads, timers, and work you started after sending the response may run extremely slowly or pause until the next request wakes the instance. If your application needs to keep working between requests, you must choose a setting that keeps CPU available, which Chapter 9 explains.

Graceful shutdown in practice

When the platform wants to stop an instance, it sends a termination signal and then, after a short grace period of around ten seconds, forcefully ends the process. A well-behaved application listens for the signal, stops accepting new work, finishes active requests, flushes logs, closes database connections, and exits. A careless application ignores the signal and may leave half-finished work or open connections behind.

Because every change creates a new immutable revision, Cloud Run makes careful, reversible releases natural.

Why revisions are immutable

A revision captures the container image, the environment settings, the memory and CPU sizes, the concurrency value, the service account, and the network settings at one moment. Once created, it never changes. If you want something different, you create a new revision. This simple rule gives you a perfect history: you can always see exactly what was running at any time, and you can send traffic back to an older revision in seconds.

Splitting traffic

A service decides how to divide incoming traffic across its revisions. Usually all traffic goes to the latest revision. But you can set percentages, for example ninety percent to the stable revision and ten percent to the new one. This allows a canary release: you expose a small group of real users to the new version, watch error rates and latency, and then increase the percentage gradually.

Deployment strategies you can build

Where builds come from

A revision starts from an image. Teams commonly build that image automatically whenever code changes, using a build service in Google Cloud or an external pipeline, store it in Artifact Registry, and then deploy it to Cloud Run. Some teams deploy directly from source code and let the platform build the image using standard build packs. Either way, the best practice is to deploy images referenced by a fixed digest or unique version label, not a floating label like latest, so that a revision always means exactly one thing.

These three ideas together determine how fast your service feels, how much it costs, and how well it survives traffic spikes.

How autoscaling decides

Cloud Run adds instances when existing ones are getting full, and removes them when they sit idle. It looks at how many requests each instance is handling compared to its concurrency setting and also at CPU use. If load rises quickly, more instances are started in parallel. If load falls, instances are removed gradually. You control the boundaries with a minimum instance count and a maximum instance count.

Concurrency is the hidden superpower

Many serverless platforms handle one request per instance. Cloud Run lets one instance handle many requests at once, as long as your code is safe for that. A web server written with an event loop or with threads can answer dozens of requests while waiting for databases. With a concurrency of 80, one instance can do the work that would need up to 80 separate instances on a one-request-per-instance platform. That means fewer cold starts, fewer database connections, and a smaller bill.

But concurrency is not always better when higher. If each request uses a lot of CPU or memory, many simultaneous requests will compete and slow each other down. If your code keeps request-specific data in shared global variables, concurrent requests can corrupt one another. The right value comes from testing: increase concurrency until latency or memory starts to suffer, then pull back a little.

Tuning in practice: a worked thought experiment

Suppose a service receives a steady two hundred requests per second, and each request spends about a quarter of a second waiting for a database. At any moment roughly fifty requests are in flight. With a concurrency value of eighty, a single instance could in theory hold all of them, but CPU use would be high and latency would suffer. A more comfortable layout is three or four instances, each holding a dozen or so requests. The point is not to memorize the arithmetic but to see the relationship: requests per second multiplied by seconds per request gives the number of requests in flight, and dividing that by a healthy per-instance concurrency estimates how many instances you will need.

Now imagine the database slows down so each request takes a full second. The same two hundred requests per second now mean two hundred requests in flight. The autoscaler adds instances to hold them, your connection count to the database rises, and the slow database becomes even slower. This feedback loop is why a maximum instance count and request timeouts are not optional extras. They are the brakes that stop a small slowdown from becoming a large outage.

Understanding cold starts

A cold start is the extra delay a request experiences when no ready instance exists and a new one must be started. It includes pulling the image, starting the container, running your startup code, and passing the readiness check. A small image with a fast-starting runtime may become ready in a second or less. A large image with a heavy framework and slow initialization can take many seconds.

flowchart TD
  A["Request arrives"] --> B{"Instance with free capacity?"}
  B -- "Yes" --> C["Serve immediately - warm path"]
  B -- "No" --> D["Start new instance"]
  D --> E["Pull image and start container"]
  E --> F["Run startup code"]
  F --> G["Pass readiness check"]
  G --> H["Serve request - cold path"]
        

Ways to reduce cold start pain

Cloud Run charges for what you use, and the way it measures use depends on one important choice: request-based or instance-based billing.

What you size

For each service you choose how much CPU and memory every instance receives. Instances can be given up to 8 virtual CPUs and up to 32 GiB of memory at the time of writing. Choose memory generously enough that your application never runs out, because an instance that exceeds its memory limit is stopped. Remember that the temporary file area is stored in memory too, so large temporary files reduce the memory available to your code.

The two billing settings

What else is on the bill

Compute is the main charge, but the bill can also include network traffic leaving Google Cloud, charges for the load balancer if you place one in front, build and registry storage costs, logging volume, and the cost of other services your application calls. A free tier covers a modest amount of monthly use, which makes learning and small projects nearly free. Pricing details change over time and differ by region, so check the official pricing page before making financial plans.

Cost behavior you should expect

Two services with the same traffic can have very different bills depending on code quality. A service that makes five sequential database calls per request holds an instance five times longer than one that makes them in parallel or caches results. A service that logs every field of every request can spend more on logging than on compute. A service that downloads a large file from storage on every request pays for both network time and instance time. Optimizing the code path is often a larger saving than switching billing settings.

Cost also follows architecture. Sending traffic across regions adds network charges and delay. Keeping a minimum instance count in many services quietly adds a steady baseline. Using a job for nightly work instead of a service that sleeps all day removes idle time entirely. When reviewing a bill, group costs by service and by category, find the top three items, and ask what design choice produced each one.

Limits that shape design

The default request timeout is five minutes and can be raised up to the maximum. The size of one request over the older web protocol is capped at 32 MiB, while the newer protocol has no such cap. These numbers can change, so always confirm them in the current quotas page. The lesson for design is stable though: long, heavy work belongs in jobs or queues, not in a single web request that a user waits for.

Networking in Cloud Run answers two questions: who can reach your service, and where can your service reach.

Ingress: who can come in

Every service has an ingress setting. When it is open to all, anyone on the internet who passes the identity check can send requests to the default address. When it is internal, only traffic from inside your Google Cloud private networks and certain Google services is accepted. A third option accepts traffic only through a Google Cloud load balancer, which is useful when you want protections that a load balancer provides.

Egress: where your code can go

By default, instances can reach the public internet and Google APIs. Many companies also need to reach private resources such as a database that has no public address. Cloud Run can attach to a private virtual network, either directly or through a connector, so that traffic to private addresses travels inside the network. You can also send all outgoing traffic through the private network and then through a network address translation service to give your service a fixed outbound address, which some partners require for allow lists.

Putting a load balancer in front

The default service address is convenient, but production systems often place a global load balancer in front of Cloud Run. This gives you a custom domain, a single global entry point, caching of static content, web application firewall rules, rate limiting, and the ability to spread traffic across services in several regions. It also lets you restrict direct access to the default address so that all users must pass through the protective layer.

Protocols supported

Cloud Run serves standard web traffic, supports the newer multiplexed web protocol, streaming responses, long-lived bidirectional connections such as WebSockets, and remote procedure call traffic. Each request is still bound by the request timeout, so extremely long-lived connections should reconnect gracefully.

flowchart LR
  I["Internet users"] --> LB["Global load balancer with firewall rules"]
  LB --> S["Cloud Run service - internal plus load balancing ingress"]
  S --> VPC["Private network"]
  VPC --> DB["Private database"]
  VPC --> NAT["Network address translation"]
  NAT --> EXT["Partner API with allow list"]
        

Security on Cloud Run is a shared effort: Google secures the platform, and you secure your application, your identities, and your settings.

The shared responsibility idea

Google patches the host machines, isolates customers from each other, and protects the managed front end. You are responsible for the code inside your container, the libraries it includes, who may call it, what permissions it holds, and how you handle secrets. Knowing where the line sits prevents two opposite mistakes: assuming the platform protects you from your own weak code, and wasting time worrying about machine-level patches that you cannot touch anyway.

Who may call your service

By default, a new service requires callers to prove who they are. Access is granted through an invoker permission on the service. You can grant it to a person, a group, or a service account. A frontend service that calls a backend service should present a signed identity token issued for the backend, and the backend checks it. This is called service-to-service authentication, and it means a backend can safely refuse every caller except the ones you named.

A service can also be made public by allowing unauthenticated access. That is appropriate for a public website or a public application interface, but it should be a deliberate decision. Public does not mean unprotected: you still need application-level protections such as input validation and rate limiting.

Who your service is

Each revision runs as a service account, which is the identity it uses when calling other Google Cloud services. The most important rule is least privilege: give each service its own dedicated service account and grant only the permissions that service genuinely needs. If a service reads from one storage bucket, it should not be allowed to delete projects. Reusing a powerful default identity for everything is one of the most common causes of serious cloud incidents.

Protecting the supply chain

Thinking like an attacker for five minutes

A useful exercise is to ask what an attacker could do if they found one flaw in your service. If the answer is that they could read every secret in the project, delete every bucket, and call every backend, then your identity design is too generous. If the answer is that they could read one table and write to one queue, the damage is contained. This habit of limiting the blast radius is more valuable than any single tool.

Also consider the path an attacker might take around your protections. If the service accepts internet traffic directly, then protections placed only in a load balancer are optional for the attacker. If a build pipeline can deploy to production with broad permissions, then the pipeline itself is a target. If logs contain tokens, anyone with log access effectively holds those tokens. Reviewing these paths once a quarter, with a short written list of findings and owners, keeps security a normal engineering activity instead of a crisis response.

A short security checklist

• Require authentication unless the service is intentionally public.
• Use one service account per service with the smallest set of permissions.
• Restrict ingress so only expected paths reach the service.
• Scan and rebuild images on a regular schedule, not only when features change.
• Keep secrets out of images and out of source control.
• Log and review permission changes and deployments.

Because instances are disposable, configuration and data must live in the right places outside the instance.

Configuration without rebuilding

The same image should run in testing and production, with only the settings changing. Environment values are the simplest way to pass settings such as the address of a database, a feature switch, or a log level. Because settings are part of a revision, changing one creates a new revision, which keeps history clean and allows rollback.

Secrets belong in a secret store

Google Cloud Secret Manager stores sensitive values, controls who may read them, keeps versions, and records access. Cloud Run can expose a secret to your application either as an environment value or as a file mounted into the instance. Using a file mount allows a secret to be rotated without restarting every instance in some setups, while environment values are read when an instance starts. Choose the approach that matches how often your secrets change.

Where to keep data

Mounting storage as folders

Cloud Run can mount a Cloud Storage bucket or a network file share as a folder that your code reads like a normal directory. This helps with applications written to expect files, such as tools that read models or templates. It is convenient, but remember that these folders are not the same as a local disk: operations can be slower, and some file behaviors differ. Use them where file-style access is needed and avoid treating them as a high speed database.

Talking to databases carefully

Databases have a limited number of connections, and Cloud Run can create many instances quickly. Each instance with its own connection pool multiplies the total. Keep pools small, reuse connections across requests inside an instance, close them in the shutdown handler, and set a maximum instance count that your database can survive. For relational databases, Google Cloud provides secure built-in connection paths so you need not expose the database to the public internet.

You cannot log in to a serverless instance, so your visibility must come from logs, metrics, and traces that the platform collects.

Three signals

Make logs useful

Plain text lines are hard to search at scale. Writing logs in a structured format, with fields such as severity, request identifier, user identifier, and operation name, lets you filter, count, and alert reliably. Include a correlation identifier that follows a request through every service so that you can reconstruct the full story of a failure. Never write passwords, tokens, or personal data into logs, because logs are widely readable inside a company.

The metrics worth watching

A calm way to troubleshoot

Runbooks and ownership

Technology alone does not keep a service healthy; people and habits do. A runbook is a short document that tells the on-call person what each alert means, where to look first, how to roll back, and who to call. Write it while the design is fresh, test it during calm periods, and update it after every incident. Pair it with a clear owner for each service, so that questions about behavior, cost, or security always have a named team to answer them.

After an incident, hold a blameless review. The aim is to understand how the system and the process allowed the failure, not to find someone to blame. Typical outcomes on Cloud Run include adding a missing alert, lowering a maximum instance count, shortening a timeout, adding an idempotency check, or splitting a service whose parts had different risks. Small, specific improvements compound over months into a system that is genuinely resilient.

Alerts that respect people’s sleep

Alert on symptoms that users feel, such as high error rates and slow responses, rather than on every internal fluctuation. Tie alerts to service level objectives, which are promises like ninety-nine point nine percent of requests succeed. This keeps on-call people focused on what truly matters.

A handful of proven patterns cover most real systems.

flowchart LR
  U["User upload"] --> API["API service"]
  API --> BK["Storage bucket"]
  BK --> EV["Event notification"]
  EV --> PS["Processing service"]
  PS --> Q["Queue for slow steps"]
  Q --> W["Worker pool or job"]
  W --> DB["Database"]
  SCH["Scheduler"] --> J["Nightly cleanup job"]
  J --> DB
        

Idempotency: the pattern behind all patterns

Messages and events are usually delivered at least once, which means your code may receive the same message twice. Design handlers so that repeating the same work gives the same final result. For example, record a unique operation identifier and skip work that was already completed. This single habit prevents duplicated payments, duplicated emails, and double counted data.

These mistakes appear again and again in real projects. Learn to recognize them early.

A compact guide to getting good results and avoiding avoidable pain.

Build and image practices

• Keep images small and clean. Use minimal base images, multi-stage builds, and remove build tools from the final image.
• Use unique image versions. Deploy by digest or unique tag so each revision is reproducible.
• Run as a non-administrator user inside the container to limit damage from a flaw.
• Handle the shutdown signal so work ends cleanly.

Runtime practices

• Test concurrency with realistic load before choosing a value.
• Set sensible timeouts for outbound calls so slow dependencies do not hold instances hostage.
• Retry with backoff and make operations idempotent.
• Warm only what matters. Use minimum instances for latency-sensitive paths, not everywhere.
• Choose the right region near users and near data, and keep related services together to cut delay.

Operations practices

• Release in small steps using traffic splitting and watch error rates.
• Keep infrastructure described as code so environments are repeatable and reviewable.
• Use separate projects for development, testing, and production to isolate permissions and costs.
• Set budgets and alerts so cost surprises become early warnings.
• Review idle and over-sized services regularly.

A readiness checklist before going live

Before a new service takes real users, walk through a short list. Each item takes minutes to check and prevents common launch-day surprises.

Common mistakes at a glance

Choosing a platform is a trade between control and convenience.

When Cloud Run is the right choice

Choose it when your workload is request driven or batch oriented, your application can be stateless, you want fast delivery with small operations effort, and traffic is variable. It is also a strong choice when you want the portability of containers without running a cluster.

Moving an existing application to Cloud Run

Many teams arrive at Cloud Run with an application that already exists on virtual machines or in a cluster. A careful move happens in stages rather than in one dramatic weekend.

When to look elsewhere

Consider Kubernetes when you need deep control of networking, custom schedulers, specialized operators, or very large stateful platforms. Consider virtual machines when software requires a full operating system, kernel-level access, or licensing tied to machines. Consider keeping workloads on Cloud Run but moving specific components, such as stateful databases, to managed data services rather than trying to run them yourself.

These scenarios are illustrative composites of how teams typically use Cloud Run, not descriptions of any single company.

Every platform choice has a cost. Be honest about both sides.

Reading the trade-offs correctly

Most disadvantages disappear when the design matches the platform. Cold starts matter less when images are small and critical paths keep a warm instance. Statelessness is an advantage once you accept it, because it makes scaling and recovery simple. Cost surprises are rare when maximum instances and budgets are set. The real risk is forcing a workload that wants a different shape into a service, such as a long stateful process.

Yes. Serverless describes your experience, not the absence of machines. You never provision, patch, or size servers. The platform does all of that, and your bill follows usage.

With a minimum of zero instances, the platform removes all instances after a quiet period and you pay no compute charge. The next request triggers a cold start. If that delay is unacceptable, set a minimum instance count.

Functions are a simpler way to deploy small units of code without writing your own web server or image recipe. They run on the same platform and share its billing ideas. Services give you full control of the container and runtime.

Only reliably if you choose a setting that keeps CPU allocated, and even then the instance can be stopped. For anything important, use a queue, a job, or a worker pool so work is tracked and retried.

Data stored in managed databases and storage services is safe. Data stored only in an instance’s memory or temporary files is lost. Always store anything valuable outside the instance.

Set a maximum instance count, pick the billing setting that matches your traffic, right-size memory and CPU, trim log volume, keep images small, and set budget alerts. Review recommendations from the cost tools regularly.

Yes. Attach the service to your private network, or use the built-in secure connection path for supported managed databases, so the database never needs a public address.

It supports streaming and bidirectional connections within the request timeout limit. Applications should be ready to reconnect cleanly when a connection ends.

Yes. The common production approach is to put a global load balancer in front with your domain and certificate, which also enables edge protections and multi-region routing.

Your application is a standard container, so the core is portable. Lock-in appears mainly in surrounding services such as identity, queues, and databases. Keep business logic separate from cloud-specific code to stay flexible.

Start with few. Split when parts have different scaling needs, different owners, or different risk levels. Too many tiny services create network overhead and operational burden.

The official Google Cloud quotas and pricing pages are the source of truth. Limits and prices change over time and vary by region, so check them before making commitments.

Cloud Run gives you the freedom of containers with the simplicity of serverless. You package an application, deploy it as an immutable revision, and let the platform route requests, scale instances, and remove them when work ends. The ideas that matter most are statelessness, concurrency, cold starts, billing mode, least-privilege identity, and careful releases through traffic splitting. Choose services for request-driven work, jobs for tasks that finish, worker pools for pulling from queues, and functions for small event reactions. Keep state in managed services, protect dependencies with limits and queues, observe with structured logs and metrics, and verify limits and prices in official documentation.