A cloud function is a small job that Google runs for you, only when something asks for it.

A cloud function is a short piece of code that does one clear job. It might resize a photo, check a payment, send a welcome message, or copy a row of data into another place. You write the code, give it to Google Cloud, and tell Google when it should run. Google takes care of everything else: the computer it runs on, the operating system, the security updates, the network, and the number of copies needed to handle the work.

This style of computing is called serverless. The name can be confusing, because servers still exist. They are simply not your problem. You do not buy them, you do not log in to them, and you do not worry about them at three in the morning. Another name for the same idea is Function as a Service, often shortened to FaaS. You provide the function, and the platform provides the service of running it.

The three things every function needs

Every function in Google Cloud is built from three simple parts. First comes the code, which is the instructions you wrote. Second comes the trigger, which is the thing that wakes the code up. Third comes the configuration, which is the set of choices such as how much memory the code may use, how long it may run, and who is allowed to call it. If you can describe those three parts, you can describe any function.

Where functions fit in the big picture

Functions are the glue of a cloud system. A bigger application might have a database, a website, a message system, and a storage area for files. Something has to connect these pieces and react when things change. Functions are perfect for that. They sit between your services and say, “When this happens, do that.”

Before functions, even a tiny job needed a whole computer waiting around for it.

Imagine you want a small program that creates a thumbnail every time someone uploads a picture to your website. In the old days you would need to rent or buy a server, install an operating system, install your language tools, copy your program onto it, and keep it running day and night. Most of the time nobody uploads anything, yet the server still costs money, still needs updates, and can still break.

The four pains of always-on servers

How computing grew up to functions

Computing has moved step by step toward doing less manual work. Each step handed another chore to the platform.

Functions are the far end of that journey. You give up some control, such as choosing the operating system, and in return you get speed, simplicity, and a bill that follows real usage.

The product has two generations and more than one name, and knowing which is which saves a lot of confusion.

Google first launched Cloud Functions as a simple service with its own special machinery behind it. Later it introduced a new version built on top of two other Google Cloud services: Cloud Run, which runs containers, and Eventarc, which delivers events. The first version is now called 1st gen and the newer one is called 2nd gen. Today, Google’s documentation uses the name Cloud Run functions for the product family, and the 2nd gen design is where new capability arrives.

What actually differs between the generations

Because 2nd gen functions are really Cloud Run services with a friendly wrapper, they inherit Cloud Run’s strengths: bigger machines, longer run times, and the ability to handle many requests at once inside one running copy. The table below shows the differences that matter most.

Which one should you choose?

For new work, 2nd gen is the natural choice because it is more powerful and receives the newest features. 1st gen still exists for older projects, and many teams are migrating step by step. A good rule is simple: if you are starting today, start on 2nd gen unless you have a very specific reason not to.

Eleven short definitions that unlock every other chapter.

Before we go deeper, let us fix the words we will keep using. Each card explains a term in plain language. Read them slowly once, and the rest of the guide will feel much easier.

Behind a few lines of code sits a quiet assembly line of Google Cloud services.

When you deploy a function, you hand Google your source code. You do not hand over a ready-made package. Google builds that package itself, stores it safely, and then runs it. Knowing these steps helps you understand deployment errors, build times, and costs.

flowchart LR
  A["Your source code"] --> B["Cloud Build"]
  B --> C["Artifact Registry"]
  C --> D["Cloud Run service"]
  D --> E["Function instances"]
  F["Trigger or Eventarc"] --> D
  G["IAM and service account"] --> D
        

The assembly line, piece by piece

What the functions framework does

Your code does not need to know how to open a network port or parse an internet request. The functions framework does that for you. It receives the incoming call, hands your function exactly the data it expects, and sends your answer back. This is why the same function can feel so short and clean, even though a lot of work happens around it.

Revisions: a safety net for change

Each time you deploy a change, a new revision is created. Older revisions remain recorded. This means traffic can move to the new version and, if something goes wrong, return to the previous one. Think of revisions as saved game checkpoints for your function.

There are two kinds of functions, and the kind you pick decides how it is woken up.

Every function belongs to one of two families. An HTTP function answers web requests. Someone, or some program, calls a web address and waits for an answer. An event-driven function reacts to something happening inside Google Cloud. Nobody waits for an answer, because the event is simply a notification.

Where events come from

Event-driven functions in 2nd gen rely on Eventarc. It supports messages from Pub/Sub (a message delivery service), changes in Cloud Storage (file buckets), and changes in Firestore (a document database). Eventarc also supports a very wide range of other Google Cloud services through audit logs, with over ninety sources available. That means a function can react when a virtual machine is created, a permission changes, or a dataset is updated.

flowchart LR
  S1["Cloud Storage change"] --> E["Eventarc"]
  S2["Pub/Sub message"] --> E
  S3["Firestore change"] --> E
  S4["Audit log event"] --> E
  E --> F["Event-driven function"]
  W["Web request"] --> H["HTTP function"]
  SC["Cloud Scheduler"] --> H
  T["Cloud Tasks"] --> H
        

HTTP functions can be woken by other services too

An HTTP function is not only for human callers. Cloud Scheduler can call it on a timetable, such as every night at midnight. Cloud Tasks can call it from a waiting line of jobs and can also slow the pace so your function is not overwhelmed. Workflows can call it as one step in a longer process. A Pub/Sub push subscription can also deliver messages to it as web requests.

Event size matters

Events travelling through Eventarc are small notes, not heavy parcels. In 2nd gen the size limit for such an event is 512 KB. This is another reason to put references in events, such as the name of a file, and let the function fetch the large content itself from storage.

Follow a single request from the moment it arrives to the moment the answer leaves.

An invocation is one run of your function for one request or one event. Understanding what happens during an invocation explains why some calls are fast, why some are slow, and why some strange bugs appear only under load.

sequenceDiagram
  participant C as Caller
  participant G as Google front door
  participant I as Function instance
  participant D as Downstream service
  C->>G: Send request or event
  G->>I: Route to a ready instance
  Note over I: If none is ready, a new one starts
  I->>D: Read or write data
  D-->>I: Reply
  I-->>G: Return response
  G-->>C: Deliver response
        

Step by step

Functions grow and shrink on their own, but you still steer how far and how fast.

Automatic scaling is the headline feature of functions. When more requests arrive, Google starts more instances. When requests slow down, it removes instances, even down to zero. You do not press any button to make this happen. What you can do is set boundaries, so scaling stays helpful and affordable.

The three dials you control

Understanding concurrency

In 1st gen, each instance handles exactly one request at a time. If ten requests arrive together, ten instances are needed. In 2nd gen, one instance can handle many requests together, as long as your code is safe to run that way. This is like a waiter who can serve several tables at once instead of one waiter per table.

The trade-off is that your code must not mix up data between requests. If two requests share a variable that holds “the current user,” they can overwrite each other. Concurrency rewards clean, stateless code.

Ways to soften cold starts

A cold start is usually short, but for a user-facing page even a short delay can be felt. Several habits reduce its effect:

• Keep the package small. Fewer and lighter dependencies load faster.
• Do heavy setup once. Create connections and load settings outside the function body so warm instances reuse them.
• Load rarely used parts lazily. Do not load something at startup if only one request in a hundred needs it.
• Use minimum instances for important, latency-sensitive functions.
• Choose a lighter runtime when startup speed truly matters.

The settings you choose decide how fast, how large and how safe your function is.

Writing the code is only half the job. The other half is deciding the size of the “room” where the code lives. Google Cloud lets you tune several settings, and each one has a trade-off between speed, safety and cost.

Languages you can use

Cloud functions support popular runtimes including Node.js, Python, Go, Java, Ruby, PHP and .NET. The exact versions supported change over time as older versions retire and newer ones arrive. A healthy habit is to review your runtime versions regularly, because running an out-of-support version can leave you without security fixes.

The main settings

Limits worth knowing

Who can reach your function, and which doors your function may open to the outside.

Networking in functions has two directions. Ingress is traffic coming in to your function. Egress is traffic going out from your function to other places. Each direction has its own controls.

Ingress choices

By default, a function can be reached from the internet at its public address, although whether a caller is allowed is a separate question handled by identity checks. You can narrow the doors. You may allow only traffic from inside your own Google Cloud network, or allow internal traffic plus traffic that arrives through a Cloud Load Balancer. The second choice is popular when you want a custom domain, protection from attacks at the edge, and a single controlled entrance.

Egress and private resources

Some systems you need, such as a database that has no public address, live inside a private network called a VPC (Virtual Private Cloud). A function sits outside that network by default. To reach private resources, you connect the function to the VPC using a serverless connector or the newer direct network egress option. You can also choose to send all outgoing traffic through the VPC so it passes your firewall rules and a fixed outgoing address, which is helpful when a partner only accepts calls from known addresses.

flowchart LR
  U["Internet users"] --> LB["Cloud Load Balancer"]
  LB --> F["Cloud function"]
  F --> V["VPC network"]
  V --> DB["Private database"]
  F --> API["External partner API"]
        

Practical networking advice

• Make functions that serve only internal systems private, so the public internet cannot even knock.
• Place the function in the same region as the database it talks to, to keep delay low.
• Remember that private network paths add configuration work, so use them where the data deserves it.
• Keep outgoing calls short and set time limits on them so a slow partner cannot hold your function hostage.

Security for functions is mostly about two questions: who may call me, and what may I touch?

Because functions are small and numerous, a team can end up with dozens or hundreds of them. If each one is casually set up, the total risk grows quickly. A few clear habits keep things safe.

Who may call the function

Access to invoke a function is controlled through IAM, Google Cloud’s permission system. A caller must hold an invoker permission for that specific function. For 2nd gen functions this is the Cloud Run invoker role. You may deliberately open a function to the public, for example a public web hook, but this should be a conscious choice and not an accident. For calls between your own services, require the caller to present a signed identity so the receiving function can verify who is knocking.

What the function itself may touch

When a function talks to other Google Cloud services, it uses a service account, which is like a staff badge. The badge carries a list of permissions. By default, functions may use a shared general-purpose badge that is often far too powerful. A much better habit is to create a dedicated service account for each function or each small group of functions, and give it only the exact permissions it needs. This is the principle of least privilege.

Protecting secrets

Passwords, tokens and keys must never live inside your code or in plain settings. Store them in Secret Manager and attach them to the function. Secrets are then delivered to the function when it runs, access is recorded in audit logs, and you can rotate a secret without rewriting the code.

More layers you can add

You cannot fix what you cannot see, and functions are easy to forget once they are running.

Because you never log in to a machine, observation happens through Google Cloud’s operations tools. They are built in, so a function starts producing useful signals from day one.

The four views of a healthy function

Metrics that tell the real story

Alerting that people actually read

Create alerts for the few things that truly matter: error rate rising above a normal level, run time becoming too slow, and failed events piling up. Too many alerts teach teams to ignore all of them. Each alert should say what is wrong and where to look first.

Things fail, networks blink, and the same event can arrive twice. Good functions expect all of this.

Event-driven systems usually promise at-least-once delivery. This means an event will be delivered one or more times, but not zero. The promise protects you from lost events, but it also means duplicates are possible. Your function must be built to handle a repeat without causing damage.

What idempotent means

An operation is idempotent when doing it once or doing it many times gives the same final result. Setting a value to “paid” is idempotent. Adding ten rupees to a balance is not. To make a function idempotent, remember what you have already processed, usually by recording the unique identifier of each event or order, and skip anything you have seen before.

Retries: a double-edged tool

For event-driven functions you can choose whether failed events should be tried again. Retrying helps with short problems such as a brief network failure. It hurts when the problem is permanent, because a broken event can be retried again and again, wasting money and filling logs. These repeated failures are sometimes called poison messages.

Timeouts and partial work

If a function is stopped at its time limit halfway through a job, some work may be done and some not. Break big jobs into smaller steps, save progress as you go, and design every step so it can be repeated safely. Short, repeatable steps are the secret of dependable serverless systems.

Five proven shapes that solve most function-based problems.

A design pattern is a tried and tested way of solving a common problem. Functions fit certain patterns especially well because they are small, quick to start, and easy to connect.

A pipeline example

The diagram below combines several patterns into one small data pipeline. A file arrives, a function validates it, a message announces the result, and another function loads the clean data into an analytics warehouse.

flowchart TD
  A["File uploaded to Cloud Storage"] --> B["Eventarc trigger"]
  B --> C["Validation function"]
  C --> D["Pub/Sub topic"]
  D --> E["Loader function"]
  D --> F["Notification function"]
  E --> G["BigQuery table"]
  C --> H["Dead-letter topic for bad files"]
        

Four common habits that look clever on day one and hurt by month six.

Functions are cheap for light and bursty work, but the bill has several parts worth knowing.

The big promise of functions is that you pay for what you use. That is true, but “what you use” has several parts. Exact prices change and differ by region, so always read the current pricing page. What stays steady is the shape of the bill.

How to keep the bill friendly

• Right-size memory. Oversized instances multiply cost for every second.
• Use concurrency in 2nd gen so one instance serves many requests.
• Finish fast. Avoid waiting on slow services without time limits.
• Set maximum instances so a runaway loop or attack cannot scale spending without limit.
• Trim logs. Very chatty functions can spend more on log storage than on compute.
• Set budget alerts on the project so surprises arrive as a message, not as an invoice.

Every tool has a sweet spot. Here is where functions shine and where they struggle.

Choosing among Google Cloud compute options

Functions are one of several ways to run code on Google Cloud. The right choice depends on how much control you need and what shape your workload has.

flowchart TD
  Q1["Is the job small and triggered by an event or request?"] -->|Yes| F["Use Cloud Run functions"]
  Q1 -->|No| Q2["Do you have a container or need custom libraries?"]
  Q2 -->|Yes| R["Use Cloud Run services"]
  Q2 -->|No| Q3["Need deep control or complex orchestration?"]
  Q3 -->|Yes| K["Consider GKE or Compute Engine"]
  Q3 -->|No| R
        

A short checklist of habits that separate calm production systems from stressful ones.

Habits worth building

Mistakes teams make again and again

Everyday examples that show how small functions solve large business needs.

Functions appear in many industries because they handle the small reactions that every digital business needs. Here are scenarios that teams commonly build.

A closer look at what really happens below the surface when your function runs.

So far we have treated an instance as a magic box. Let us open the lid a little. Understanding the inside of the box explains many behaviours that otherwise feel mysterious, such as why global variables survive between requests, why two functions never see each other’s files, and why events sometimes arrive late.

What an instance really is

An instance is a running container started from the image that Cloud Build created for you. Inside the container, the functions framework listens for incoming calls and passes each one to your code. The container runs inside a secure sandbox, which is a protected space that keeps your workload apart from every other customer’s workload on the same physical machine. Even if two customers share one computer, neither can look into the other’s container.

What survives between requests, and what does not

While an instance stays alive, anything stored in memory outside the function body stays alive too. This is why connections and loaded settings can be reused, and it is the reason warm calls are so much faster than cold ones. But the instance can be removed at any moment, for example when traffic drops or when Google moves workloads around. Any data kept only in memory, or written to the instance’s temporary disk, will vanish when that happens. The temporary disk is also held in memory in this environment, so writing large files there uses up the memory you have paid for.

How an event reaches your function

Event-driven delivery has its own journey. When something happens in a source service, such as a new file in a bucket, an event is created. Eventarc receives it, checks it against the filters of every trigger you have defined, and wraps it in a standard envelope format called a CloudEvent. That envelope carries the type of event, the source, the time, and the details. Eventarc then calls your function over the internal network with an identity that is allowed to invoke it.

A function is only as dependable as the way it is tested, shipped and rolled back.

Because functions are small, it is tempting to edit them directly in a console and press deploy. That works for a first experiment, but it is a risky habit for anything real. Teams that run many functions in production treat them like any other software: code lives in version control, changes are reviewed, tests run automatically, and releases follow a repeatable path.

A healthy delivery path

The kinds of tests that matter

Configuration as part of the release

Settings such as memory, timeout, maximum instances and network rules are part of what makes a function work. Store them alongside the code, ideally in infrastructure definitions that are reviewed like code. When settings live only in someone’s memory or in a console, no one can tell why production behaves differently from the test environment.

If you already run older functions, here is a calm, step-by-step way to modernise them.

Many organisations still run 1st gen functions that were written years ago and work fine. There is no need to panic, but there are good reasons to plan a move: access to larger machines, longer run times, concurrency, richer event sources, and the full range of Cloud Run features. A careful migration is mostly about checking differences, not rewriting everything.

What usually changes

A safe migration path

Functions forget everything, so the memory of your system must live somewhere else.

Since a function instance can disappear at any time, every piece of information that matters must be kept in a service built for that purpose. Choosing the right home for your data is one of the most important design decisions you will make. A wrong choice can make a simple function slow, expensive or fragile. Google Cloud offers several storage services, and each one fits a different kind of information.

Choosing the right home for your data

Protecting databases from your own success

Because functions scale quickly, they can open a very large number of database connections within seconds. Traditional relational databases allow only a limited number of connections, and too many can make the whole database unresponsive. Several habits help. Reuse one connection per instance rather than opening one per request. Use a connection pool or a managed proxy that shares connections. Set a sensible maximum instance count. Or place a queue in front so work arrives at a steady pace.

Caching and the cost of repetition

If many requests ask for the same slow-to-fetch information, such as a settings table or a list of product categories, fetching it every time wastes time and money. A small in-memory copy that lives for the life of the instance can help, as long as the information changes rarely and slightly stale data is acceptable. For information that must be consistent across all instances, a shared cache service is a better choice. Always decide how long cached data may be trusted, because stale data is a quiet source of confusing bugs.

What changes when you go from a handful of functions to hundreds across many teams.

A single function is easy to understand. A hundred functions owned by ten teams are a different matter. Without shared habits, you end up with unknown owners, unclear names, forgotten experiments still running, and permissions nobody remembers granting. Operating at scale is mainly about discipline and visibility.

Ownership and naming

Every function should have a clear owner and a clear purpose that can be read from its name. Names that describe the job, such as one that mentions the event and the action, are far more useful than names like “test2” or “newfunction.” Labels, which are small key and value tags attached to resources, can record the team, the environment, the cost centre and the service the function belongs to. Labels make it possible to filter logs, split the bill by team, and find all functions owned by a team that is being reorganised.

Projects, environments and boundaries

A common approach is to give each environment its own Google Cloud project, so a mistake in testing can never touch production data. Larger organisations also group projects into folders and apply organisation policies at the folder level. These policies can enforce rules automatically, such as allowing only certain regions, blocking public access to functions, or requiring that functions use private networking. Rules enforced by the platform are far more reliable than rules written in a document that people may forget.

Quotas, budgets and guard rails

Quotas protect the platform and also protect you. Limits exist on the total memory and processing power a project may use in a region, on how many functions you may deploy, and on how fast you may change them. If one noisy function consumes the project’s allowance, other functions can fail. To avoid this, separate critical and experimental functions into different projects, monitor how close you are to quotas, and request increases early.

Documentation people will actually read

For every function, write a short page that states its purpose, its trigger, what it reads and writes, which settings matter, how to tell whether it is healthy, and what to do when it fails. A page that takes two minutes to read can save two hours of confusion during an incident.

The idea of functions is shared across providers, but the details feel different.

Function-as-a-Service is not unique to Google. Other major cloud providers offer their own versions, and the basic promise is the same everywhere: send code, get automatic scaling, pay for use. Knowing how the ideas line up helps you move knowledge between platforms and avoid being surprised when you switch.

Ideas that carry over

What feels distinctive about Google’s approach

The most noticeable difference is that 2nd gen functions are built directly on Cloud Run, a general container platform. This blurs the line between a function and a small containerised service. A team can start with a function and later promote the same workload to a full Cloud Run service with little redesign. This also means that features such as concurrency per instance, longer web request times and larger memory sizes come from the same foundation as container workloads.

A second distinctive point is Eventarc, which gives one consistent way to receive events from a very wide range of Google Cloud services, including those that report activity through audit logs. This makes it simple to build rules like “when this resource changes, run this function” without writing special code for each service.

Quick answers to the questions beginners and intermediate engineers ask most.

No. Servers exist, but Google owns, patches and scales them. You never manage them directly, which is why the word serverless describes your experience rather than the hardware.

Cloud Run functions is the newer name Google uses for the product family. The 2nd gen design runs on Cloud Run and Eventarc, while 1st gen is the earlier implementation. For new projects, 2nd gen is the usual choice.

It depends on the generation and type. 1st gen is limited to nine minutes. In 2nd gen, web functions can run up to sixty minutes, event-driven functions up to nine minutes, and scheduled or task-queue functions up to thirty minutes. Always confirm current numbers in the quotas page.

A cold start is the extra time needed to start a new instance before it handles its first request. You cannot remove it completely, but you can reduce it with smaller packages, lazy loading, and minimum instances that keep some instances warm.

In 2nd gen, yes, through concurrency. In 1st gen, each instance handles one request at a time. Concurrency saves money but requires code that keeps each request’s data separate.

Not directly. Each function has one trigger. If several events must run the same logic, deploy more than one function that shares the same helper code, or send all events through one Pub/Sub topic that feeds a single function.

Design for idempotency. Record a unique identifier for each processed event or order, and skip anything already seen. Also store results in a way that makes repeating the final step harmless.

It can be, when that is the purpose, such as a public web hook. Even then, validate every incoming request, check signatures where the sender provides them, limit the maximum instances, and avoid giving the function powerful permissions.

Connect the function to your VPC network using a serverless connector or direct network egress. Then the function can reach private addresses. Place it in the same region as the database and set a sensible maximum instance count to protect the database from too many connections.

Choose Cloud Run services when you already have a container, need custom system libraries, want several routes in one application, or need full control over how the application starts. Functions are best for small, focused, event or web reactions.

Right-size memory, use concurrency, set maximum instances, avoid long waits, trim noisy logs, and add budget alerts. Review the bill monthly in the first few months, because early habits shape long-term spending.

Start with the logs for the failing time window and search by the request or event identifier. Then check error reports for grouped failures, and look at metrics for sudden changes in memory, run time, or instance count.

Cloud Functions, now described by Google as Cloud Run functions, lets you focus on the single job your code must do while the platform takes care of machines, scaling and many security chores. You learned that functions are woken by web requests or by events delivered through Eventarc, that 2nd gen is built on Cloud Run and brings bigger limits and concurrency, and that automatic scaling is powerful but needs boundaries. You also saw that dependable systems come from habits: stateless code, idempotent handling, least-privilege identities, protected secrets, careful retries, and clear monitoring.

Functions are not the answer to everything. Heavy, long, always-busy workloads may fit better on container services or virtual machines. But for small reactions, glue between systems, scheduled chores and bursty events, they are one of the quickest and most economical tools in the whole cloud. Start small, measure honestly, and grow with confidence.