Start here. This chapter explains the big idea in plain words before we look at any details.

The simple definition

Cloud Functions is a serverless compute service. “Compute” means a place where your code runs. “Serverless” does not mean there are no servers. Servers still exist, but they are Google’s problem, not yours. You never log in to them, you never choose how many to buy, and you never fix them when they break.

A function is a small block of code that does one job. For example: resize one picture, send one email, check one payment, or save one row of data. It starts, finishes its job, and stops.

Why it exists

Before serverless, a team that wanted to run even tiny code had to rent a server, install software, secure it, watch it, and pay for it twenty-four hours a day. Most of that time the server sat idle. Cloud Functions was created to remove that waste and that busywork, so developers can focus on the code that matters to their business.

Where it is used

Teams use it for web hooks, small web APIs, file processing, chat bots, data clean-up, scheduled jobs, and glue code that connects one Google Cloud service to another. It is a favourite tool for “when this happens, do that” tasks.

Six simple ideas explain almost everything about Cloud Functions. Learn these and the rest becomes easy.

Two kinds of functions

The first kind is an HTTP function. It gets its own web address. Anyone allowed to call that address can wake it up by sending a request, just like opening a web page. It answers with a response. This kind is good for small APIs and webhooks.

The second kind is an event-driven function. It has no public address of its own. Instead it listens for an event from another Google Cloud service and runs when that event happens. This kind is good for background work, such as processing a file after it lands in storage.

Stateless by design

A function must be stateless. That means it should not rely on remembering anything from earlier runs. Google may reuse an instance for the next request, or may throw it away at any time. If you need to remember something, write it to a database or storage service. We return to this rule many times because breaking it is the most common beginner mistake.

Cloud Functions exists in two generations. Knowing the difference helps you read older tutorials and choose wisely for new work.

The first generation was the original product. Each instance handled exactly one request at a time. If ten requests came together, Google started ten instances. It was simple, but it also meant more cold starts and less control.

The second generation was rebuilt on top of Cloud Run and Eventarc. Cloud Run is Google’s service for running containers. Eventarc is Google’s service for routing events. Because of this foundation, second generation functions gained longer time limits, bigger machine sizes, the ability to handle many requests inside one instance, and a much wider list of event sources.

Let us look at the building blocks that sit around your code and make the magic happen.

flowchart LR
  A["Client or Browser"] --> B["HTTPS Endpoint"]
  B --> C["Cloud Functions Service"]
  C --> D["Function Instance"]
  D --> E["Firestore Database"]
  D --> F["Cloud Storage Bucket"]
  G["Pub/Sub Topic"] --> H["Eventarc Router"]
  H --> C
  I["Cloud Scheduler"] --> B
    

The picture shows two doors into your function. The first door is the HTTPS endpoint, used by browsers, mobile apps, and other programs. The second door is Eventarc, which listens to other Google Cloud services and delivers their events. Cloud Scheduler can ring the first door on a timetable, like an alarm clock for your code.

The main parts

The Functions Framework

Google publishes a free, open-source helper called the Functions Framework. It wraps your code so that it follows the same rules locally as it does in the cloud. You can run your function on your own laptop, test it, and then deploy the same code unchanged. This is a big help, because it means you do not have to deploy every small change just to see if it works.

This chapter follows one request from the moment it arrives until the answer goes back out.

sequenceDiagram
  participant U as User
  participant P as Platform
  participant I as Instance
  participant D as Database
  U->>P: Send request
  P->>P: Look for a free instance
  alt No instance is ready
    P->>I: Start a new instance
    I->>I: Load code and run setup
  end
  P->>I: Hand over the request
  I->>D: Read or write data
  D-->>I: Return result
  I-->>P: Send response
  P-->>U: Reply to user
  Note over P,I: Idle instances are removed later
    

Cold starts and warm starts

When a request arrives and no instance is ready, Google must create one. It finds a machine, loads your container, starts the language runtime, and runs your setup code. This extra waiting time is called a cold start. It can take from a fraction of a second to a few seconds, depending on your language, your libraries, and how much your setup code does.

If an instance is already running and idle, the next request reuses it. This is a warm start, and it is much faster because all the setup is already done.

Scaling up and down

Google watches how many requests are coming in. If traffic grows, it starts more instances. If traffic falls, it removes instances, and when no traffic remains, it can remove all of them. This is called scale to zero, and it is why you pay nothing when nobody uses your function.

You can place limits on this behaviour. A minimum instances setting keeps some instances always ready, which reduces cold starts but costs a little even when idle. A maximum instances setting puts a ceiling on growth, which protects other systems from being overwhelmed.

Concurrency in the second generation

In the second generation, one instance can serve several requests at the same moment. This setting is called concurrency. If one instance handles ten requests together, you need far fewer instances, you see fewer cold starts, and your bill is usually smaller. The trade-off is that your code must be safe when many tasks share the same memory. Shared variables that change are dangerous here. The default is often one request at a time, so you must turn higher concurrency on deliberately and give the function enough CPU.

Where the code really runs

Every instance runs inside a secure sandbox. A sandbox is a sealed room: your code can use the room’s resources but cannot peek into the neighbouring rooms that belong to other customers. This isolation is how Google safely runs code from millions of different people on shared hardware.

Follow the data and the life of a function from first idea to retirement.

The lifecycle of a function

A real data flow: photo upload

Picture a photo-sharing app. A user uploads a picture. Nobody wants to wait while the server makes thumbnails, so the work happens in the background through a chain of small functions.

flowchart TD
  A["User uploads photo"] --> B["Cloud Storage bucket"]
  B --> C["Eventarc trigger"]
  C --> D["Thumbnail function"]
  D --> E["Resized image bucket"]
  D --> F["Pub/Sub topic image-ready"]
  F --> G["Notification function"]
  F --> H["Metadata function"]
  G --> I["Email or push message"]
  H --> J["Firestore record"]
    

The upload lands in a bucket. Storage emits an event. Eventarc delivers it to the thumbnail function. That function creates smaller images and then publishes a short message to a Pub/Sub topic. Two other functions listen to that topic. One sends a notification, and the other saves details to a database. Each function is small, easy to understand, and can fail or be fixed on its own without breaking the others.

Delivery guarantees and retries

Event-driven delivery is usually at least once. That means Google promises the event will arrive one or more times, but it does not promise exactly once. If your function crashes and retries are on, the same event may be delivered again. For this reason you should write functions that are idempotent, a long word that simply means “doing it twice gives the same result as doing it once”.

A function is useless until something wakes it. Here are the most common wake-up calls.

Cloud Tasks for controlled work

Sometimes you want to send work to a function slowly and carefully, not all at once. Cloud Tasks is a queue service that hands out jobs at a rate you choose, retries failures, and can delay jobs to a later time. It pairs well with functions when a downstream system, such as an old database, can only handle a trickle of requests.

A handful of settings decide how fast, how safe, and how costly your function will be.

The region choice deserves a moment. Running your function far from your database adds delay to every call, because data must travel a long distance. Put the function and its data in the same region whenever you can. This single choice often makes a bigger speed difference than any code tuning.

No tool is perfect. Here is an honest look at both sides.

The big trade-offs

Simplicity versus control. You give up the ability to tune the machine, the network, and the operating system. In return you get freedom from running them. For most small and medium jobs this is a very good bargain.

Cost at low traffic versus cost at high traffic. Paying per use is wonderful when traffic is small or uneven. When a service receives heavy, constant traffic all day, an always-on container can be cheaper than millions of separate function runs. Run the numbers for your own case.

Speed of development versus ease of debugging. Small functions are quick to write. But a business flow spread across fifteen functions needs good logs and tracing, or finding the cause of a problem feels like searching for a lost sock in a big house.

Security answers two questions. Who may call my function? And what may my function do once it runs?

Who may call it: invoker permissions

By default a function is private. Only callers with the right permission, called the invoker role, may wake it. You can choose to allow anyone on the internet to call it, which suits a public website, but you should do that on purpose and never by accident. For calls between your own services, each caller proves who it is with a signed identity token, much like showing an ID card at a door.

What it may do: service accounts

Every function runs as a service account, which is an identity made for programs instead of people. That identity decides what your function can read or write. If it has too much power, a single bug or stolen token could cause great damage.

Protecting secrets

Passwords, API keys, and tokens must never be written inside your code or left in plain environment variables. Use Secret Manager, a service that stores secrets safely, controls who can read them, and keeps old versions. Your function asks for the secret when it needs it.

Network controls

Ingress settings decide where calls may come from: anywhere, only from inside your own private network, or only through a load balancer you control. Egress settings and VPC connectivity decide how your function reaches private resources, such as a database that has no public address. Combining these lets you build functions that are invisible from the internet but still useful inside your system.

Other protections

• Keep libraries updated. Old libraries often contain known security holes.
• Check every input. Treat anything that arrives in a request as untrusted until you have checked it.
• Verify webhook signatures. Outside services sign their messages so you can confirm they are real.
• Use your own encryption keys when rules demand it. Customer-managed keys let a team control how stored data is protected.
• Keep audit logs. They record who changed or called what, which helps during an investigation.

You cannot fix what you cannot see. Cloud Functions connects to Google’s observability tools automatically.

The numbers worth watching

• Execution count. How often the function runs. A sudden jump or drop is a warning sign.
• Execution time. Look at the slow end of the range, not just the average. A few very slow runs can hurt real users.
• Error rate. The share of runs that fail. Set an alert when it rises above a normal level.
• Instance count. Shows how hard the platform is working to keep up.
• Memory use. If it is close to the limit, a crash is coming.

Set up alerting policies so the right person gets a message when something drifts out of normal range. Also add a correlation identifier, a unique label copied through every function in a chain. With that label you can search one word in the logs and see the whole story of a single customer order from start to finish.

A pattern is a proven way to solve a common problem. An anti-pattern is a popular way to cause one.

Helpful patterns

Anti-patterns to avoid

More things to steer clear of

• The giant function. One function that does twenty jobs is slow to start, hard to test, and hard to secure. Keep each one focused.
• Hidden state. Storing user data in a global variable and expecting it to still be there next time.
• Heavy work in setup code. Loading large files at startup makes every cold start longer.
• Unlimited scaling against a small database. A thousand instances opening a thousand database connections can knock the database over.
• Ignoring retries. Turning retries on without making the function safe to repeat.

A checklist of habits that experienced engineers rely on every day.

Habits that work

• One job per function. Small functions are easy to name, test, and replace.
• Reuse expensive things. Create database clients and similar helpers once in the setup area, outside the main handler, so warm instances can reuse them.
• Use lazy loading. Load rarely used libraries only at the moment they are needed.
• Keep dependencies lean. Fewer and smaller libraries mean faster cold starts and fewer security worries.
• Use a dedicated service account for each function. Do not share one powerful identity across everything.
• Pin library versions. This keeps today’s working build the same as tomorrow’s.
• Write idempotent code. Assume every event may arrive twice.
• Return quickly from HTTP functions. If real work will take long, accept the request, queue the job, and answer at once.
• Use minimum instances for user-facing paths. One or two warm instances can remove most visible slowness.
• Automate deployment. Use a pipeline so every release follows the same tested steps.
• Use revisions and gradual rollout. In the second generation you can send a small share of traffic to a new version first and roll back fast if it misbehaves.

Mistakes beginners often make

Here are common ways teams use Cloud Functions. The scenarios are typical examples, not claims about any single company.

Cloud Functions is one of several compute choices in Google Cloud. Here is how it compares.

A simple rule of thumb: if the job is small and reacts to something, choose Cloud Functions. If you already have a container or a bigger application, choose Cloud Run. If you need very tight control or run a huge platform, look at Kubernetes or virtual machines. Because the second generation runs on Cloud Run, moving up from a function to a full service later is usually a smooth step.