What Is Serverless Computing? Pros, Cons, and Use Cases

Your developer wants to build the new booking feature “serverless.” It sounds ideal: no servers to patch, no capacity to plan, and you only pay when someone actually uses it. Then a colleague warns that serverless bills can spiral and that the app might feel slow at times.

Both are right, depending on the workload. This guide explains what serverless computing really is, how functions-as-a-service works, where it saves money, where it costs more and how to decide whether it fits your project.

What serverless computing means

Serverless computing is a way of running code in the cloud where the provider handles every server-related task: provisioning, patching, scaling and capacity planning. There are still servers, of course. You just never see or manage them.

The most common form is functions-as-a-service (FaaS). You write a small piece of code, a function, that does 1 job, such as resizing an uploaded image or processing a form submission. You tell the cloud what event should trigger it. When that event happens, the provider starts your function, runs it and shuts it down.

The best-known FaaS products are:

• AWS Lambda, launched by Amazon Web Services in 2014
• Azure Functions from Microsoft
• Cloud Run functions from Google, renamed from Cloud Functions in August 2024 when Google merged it with its Cloud Run platform

“Serverless” also describes other fully managed services where you do not size or manage servers, such as serverless databases, queues and container platforms that scale to zero. In this guide, the focus is on functions.

How functions-as-a-service works

A typical serverless flow looks like this:

1. An event happens. A customer submits a form, a file lands in cloud storage, a scheduled time arrives or an API receives a request.
2. The platform starts your function. If no copy is running, it creates a fresh execution environment.
3. Your code runs. It reads the event, does its job and returns a result or writes data somewhere.
4. The platform scales automatically. If 500 events arrive at once, the platform runs many copies in parallel, up to your account’s limits.
5. You pay for what ran. When traffic stops, nothing runs and, for most usage-based plans, nothing is billed for compute.

Functions are designed to be short-lived and stateless. AWS describes Lambda as built for short-lived tasks that do not keep state between invocations. A standard Lambda function can run for up to 15 minutes per invocation and use up to 10,240 MB of memory. Anything that needs to be remembered between runs goes into a database or storage service.

How serverless pricing works

Serverless pricing is usage-based, which is both its main attraction and its main risk. Taking AWS Lambda as an example, you are charged on 2 dimensions:

• Requests: a fee per million invocations. AWS lists $0.20 per million requests for standard functions in its US East region at the time of writing.
• Duration: compute time multiplied by the memory you allocate, measured in GB-seconds. Allocating more memory raises the per-second cost but also gives the function more CPU.

AWS’s free tier for Lambda includes 1 million requests and 400,000 GB-seconds of compute per month. Azure Functions and Google Cloud Run functions use broadly similar consumption models. Prices vary by provider, region, architecture and plan, so always check the current pricing page.

Remember the extras. A serverless app usually also pays for an API gateway, databases, storage, logging and data transfer. These often cost more than the functions themselves.

The pros of serverless

1. No server management. No operating systems to patch or capacity to plan. Small teams can ship production features without operations staff.
2. Automatic scaling. Functions scale up during spikes and back down when traffic stops.
3. Pay for actual use. Idle time on consumption plans costs nothing for compute, which is ideal for workloads that sit quiet most of the day.
4. Fast development for event-driven tasks. Wiring a function to “run when a file is uploaded” takes far less work than building and hosting a full service.
5. Built-in resilience. The provider runs functions across its infrastructure, so you are not relying on 1 server you manage.

The cons of serverless

1. Cold starts. When a function has not run recently, the platform must create a new environment before running your code, which adds a delay. For background jobs this rarely matters. For customer-facing pages, it can feel sluggish. Providers offer options to keep instances warm, such as Lambda Provisioned Concurrency or always-ready instances on Azure’s Flex Consumption plan, but those cost money even when idle.
2. Time and resource limits. Long-running jobs, such as video processing or large data imports, can hit execution time limits and need to be split up or moved elsewhere.
3. Costs at high, steady volume. Per-request pricing is efficient at low volume. For a service handling heavy, constant traffic, a container or virtual machine running all the time can be cheaper.
4. Harder debugging and monitoring. An app made of dozens of small functions is harder to trace than 1 application. Good logging and tracing are essential.
5. Lock-in. Triggers, permissions and integrations are specific to each provider. Moving a large serverless app to another cloud takes real work.

Key takeaway: Serverless saves the most money and effort when work is event-driven and uneven. When traffic is steady and heavy, or jobs run for a long time, compare the cost against containers or virtual machines before committing.

Where serverless saves money and where it costs more

For workloads in the weak or mixed rows, containers are often the next option. Our guides to what Docker is and Kubernetes explain that path.

Serverless vs other cloud options

For a broader view of how serverless fits into cloud service models, see our guide to IaaS vs PaaS vs SaaS.

Where to start: 5 steps to a first serverless project

1. Pick a small, event-driven task. Good candidates: sending an email when a form is submitted, resizing images on upload, or a nightly report.
2. Use your existing cloud. If you already use AWS, Azure or Google Cloud, start with its function service so you can reuse accounts, billing and permissions. Our AWS vs Azure vs Google Cloud guide compares them.
3. Set budgets and alerts first. A bug that triggers a function in a loop can run up charges. Set a spending alert before you deploy.
4. Give each function minimal permissions. Allow only the specific actions and resources it needs. This follows zero trust security principles.
5. Measure and compare. After a month, review cost, speed and error rates. If a function runs constantly, model the cost of moving it to a container. Our FinOps guide explains how to track this.

The bottom line

Serverless computing lets you run code without managing servers, scaling automatically and paying for what you use. It is an excellent fit for event-driven, uneven workloads and for small teams that want to ship quickly. It is a poor fit for long-running jobs and can be more expensive for steady, heavy traffic. Start with 1 small task, set a budget alert and let real usage data decide how far to go.

Sources

• AWS Lambda pricing — request and GB-second pricing model, free tier amounts
• AWS Lambda quotas — 15-minute timeout, memory limits, short-lived stateless design
• Microsoft Learn: Azure Functions hosting options — Consumption and Flex Consumption plans, always-ready instances
• Google Cloud: Cloud Functions is now Cloud Run functions — August 2024 rename and merger with Cloud Run