Traditional infrastructure is sized for peak demand — and costs the same every day as it does on that peak day. Serverless flips this model: you pay for what runs, and what doesn't run costs nothing. Cloud Run on Google Cloud makes this principle practical for everyday applications, without requiring teams to reinvent how they work. Here's how the cost model works, where its limits lie, and why we're writing about this from our own experience.
The silent bill in the server room
There's a question that rarely comes up in infrastructure discussions, even though it's the most important one: what does your infrastructure cost when no one is using it? With traditional servers, the answer is: exactly the same as always. The machines run at night, on weekends, and during holidays. They were sized for the busiest day of the year — Black Friday, the catalog mailing, the month-end close. On every other day, you're paying for that reserve without using it.
For decades, this was treated as a law of nature. Capacity had to be kept on hand because adding more took weeks. Anyone who planned too lean risked outages at the worst possible moment. Anyone who planned generously burned money quietly. Most planned generously, for understandable reasons, and the utilization statistics of many data centers tell that story to this day.
What serverless does differently
Serverless reverses the principle. Applications don't run on dedicated machines — they're started by the platform when requests arrive and shut down when they stop. Cloud Run, Google Cloud's serverless service, automatically scales applications with load, down to zero if needed. Zero means literally zero: an application that no one is currently calling uses no resources and generates no costs.
For cost structure, this means a shift from fixed costs to variable costs. You pay for compute time that actually happens. You no longer need to buy capacity for peak days in advance — the platform provides it at the moment of the spike and releases it afterward. Black Friday costs more than a Tuesday in February, and that's exactly how it should be, because you also earn more on Black Friday.
The second effect is operational and often underestimated. There are no more servers to patch, monitor, and replace. The operating system, scaling, and fault tolerance are the platform's responsibility. The team that used to maintain machines now works on applications. For small IT departments, this effect is often more valuable than the cost savings themselves — skilled staff are scarcer than budget.
Worth noting: Cloud Run is not a niche product
Serverless long had a reputation as a specialist technology for small functions that requires a particular way of writing code. That doesn't apply to Cloud Run. The platform runs ordinary containers. An application that runs in a container today can run on Cloud Run with manageable effort, regardless of whether it's written in Java, PHP, Python, or Node. The team doesn't need to learn a new architectural philosophy to get started.
This makes Cloud Run a pragmatic entry point into the cloud altogether. Instead of a large migration, you take a single service that's causing pain, package it in a container, and run it serverless. The old server stays in place until the new approach has proven it can carry the load. A fundamental debate about cloud strategy becomes a contained experiment with a measurable outcome.
Transparency belongs here: we're not writing from a brochure, but from operational experience. Our own systems run on Cloud Run — from our website's content backend to the tools we use daily — as do the system landscapes of several of our clients. The experience is unremarkable in the best sense: services scale when things get busy, cost almost nothing when they don't, and no one on our team has thought about an operating system update in months.
Where the model hits its limits
An honest article also covers the cases where serverless is not the right answer. Applications with consistently high, sustained load benefit little from the variable model — if you're running at full capacity around the clock, variable pricing ends up costing roughly the same as fixed. There are more suitable operating models for such workloads, including within Google Cloud.
The second limit applies to highly latency-sensitive systems with infrequent requests. When an application has scaled to zero and the first request arrives, startup takes a moment. For the vast majority of web and API applications, this is either irrelevant or can be addressed through configuration — for example, by keeping a minimum instance warm. But it's worth knowing before you design a trading system with millisecond requirements.
The third limit is not technical but architectural. Serverless rewards small, clearly scoped services and penalizes monoliths that do everything at once. Packaging a large legacy application into a container as-is will get you the operational benefits, but only part of the cost benefits. The full effect comes when the landscape is gradually broken down into components that scale independently. That takes work, but it can be planned, and it pays dividends beyond just the cloud bill.
Why AI gives this topic new weight
The load profile of AI applications is made for this model. AI workloads are bursty: a batch job enriches product data overnight, a wave of requests hits the chatbot after a newsletter goes out, a model is retrained once a week. Maintaining fixed capacity for these patterns is the most expensive option. Running them serverless is the most natural.
Then there's the experimentation question. Companies that want to test AI use cases need an environment where a prototype costs a few euros, not a procurement cycle. That environment is serverless: the prototype runs, gets measured, and only costs what it actually computes. If it fails, it gets deleted — and there's no hardware left that anyone needs to write off. Our article on bringing AI pilots into production describes how prototypes like these become production systems.
A calculation example, deliberately simplified
A simplified example makes the model tangible. The numbers are fictional; the structure is typical. A company runs an internal ordering portal. Usage is concentrated on weekdays between eight and six, with a spike at month-end. Running it the traditional way means two servers operating around the clock, sized for the month-end peak. Of the 730 hours in a month, they're meaningfully used for perhaps 220, and even then usually well below capacity.
Running the same application on Cloud Run, it starts up in the morning with the first requests, scales up automatically at month-end, and shuts down to zero in the evening. You pay for the hours actually computed. In this pattern, the savings aren't ten or twenty percent — they're in a different order of magnitude entirely, because the constant baseline cost disappears completely. There's an unplanned benefit too: when the portal is rolled out company-wide a year later and the user count triples, nothing changes in the infrastructure. It simply scales along, with no procurement and no project.
To be clear: this is an illustrative example, not a performance guarantee. Applications running at constant full load won't achieve these effects. That's why the starting point is always an analysis of your own load profile — not a promise.
How Cloud Run fits into the rest of your landscape
A legitimate concern with any new operating model is integration. No one wants another island. The context helps here: Cloud Run is not a standalone system — it's a building block in the Google Cloud ecosystem, and those building blocks are designed to work together. A service on Cloud Run talks natively to BigQuery for analytics, Cloud SQL for relational data, Pub/Sub for events, and Vertex AI for models. Permissions, logging, and network rules follow the same mechanisms as the rest of the platform.
For established landscapes, this means the serverless service isn't a foreign element sitting next to the ERP and legacy systems — it's the integration point through which they're gradually connected. Many of our projects start exactly this way. The first Cloud Run service is an API linking two legacy systems that previously communicated via file exchange. From there, the landscape grows one building block at a time, at the pace that budget and team allow.
What changes for your team day to day
Beyond cost and scaling, there's a third effect that only becomes visible in daily work. Deployments lose their edge. A new version goes live on Cloud Run as a new revision, and if something goes wrong, the previous revision is one step away. Teams that used to deploy once a quarter under pressure suddenly ship weekly or daily, because each individual step has become small and reversible.
This also changes the relationship between development and operations. Where two groups used to communicate through tickets, one team takes ownership of the full cycle, because the operational overhead has become small enough to manage. For a mid-sized company, this translates directly into more changes shipped per year with the same headcount. That pace is ultimately what determines competitiveness — not the saved server bill.
How to find out what's possible for you
Getting started with this analysis is simpler than most people expect. Take your infrastructure costs from the past twelve months and compare them against actual utilization. The gap between capacity paid for and capacity used is your potential. Then find the one service that would work as a pilot: clearly scoped, container-ready, with variable load. Internal tools, APIs, batch processing, and web applications are typical candidates.
We'll bring that one service to Cloud Run with you, measure the real costs over three months, and put the numbers next to the old ones. After that, you decide how to proceed based on results, not slides. In our experience, the answer tends to become obvious on its own. You can find the starting point on our Google Cloud page. All analyses are available in our Google Cloud Insights.