Google Cloud Functions

When a file is uploaded you need to generate a thumbnail; when a webhook arrives you need to store data. Spinning up a server, patching it, and managing scaling for each of these small tasks adds up fast.

As microservice architectures spread, teams found themselves managing dozens of small services — webhook receivers, file processors, scheduled cleanup jobs — where most were idle 99% of the time but still consumed compute resources and cost money. Servers sat waiting for events that arrived a few times an hour, and operators still had to patch, monitor, and scale each one. The function-as-a-service model flipped this: instead of paying for idle servers, you deploy a function that executes only when its trigger fires and releases resources the moment it finishes. Teams stopped paying for idle compute and stopped managing infrastructure for workloads that barely used it.

Cloud Functions connects a function to a trigger (HTTP request, Cloud Storage event, Pub/Sub message, etc.). When the trigger fires for the first time, the platform provisions a lightweight container to run your function — this is the cold start, and it adds latency on the order of hundreds of milliseconds to a few seconds depending on runtime and package size. Once the container is up, subsequent invocations reuse the same warm instance, responding much faster. If the function stays idle past a timeout window, the platform destroys the instance entirely, and the next call starts cold again. During traffic spikes, multiple instances are created in parallel, each handling its own invocations independently. You define only the code and trigger — Google manages provisioning, scaling, and teardown.

Cloud Functions and Cloud Run are both serverless, but Cloud Functions focuses on connecting a single function to an event, while Cloud Run deploys an entire container. If the logic is simple and event-driven, use Cloud Functions; if your app has multiple endpoints, use Cloud Run.

Well-suited for event post-processing, webhook receivers, simple APIs, and scheduled tasks — short, independent pieces of logic. Not a good fit when request processing takes a long time or your app has many routes.