Serverless Architecture: How It Works and When to Use It

Serverless architecture is a way of building applications in which the cloud provider runs, patches and scales the infrastructure, and you ship code that responds to events. Servers still exist. You just don't provision or manage them, and you pay only while your code runs. It fits spiky, event-driven work very well and fits steady, high-volume work less well, which is why most mature teams end up mixing it with containers.

This guide explains how the model works, where it earns its keep, where it hurts, and how to choose between serverless and containers for a specific workload.

TL;DR

• Serverless means the provider handles provisioning, patching and scaling; you write functions and managed-service configuration, and you are billed per request and per millisecond of execution.
• It shines for bursty, event-driven, short-lived work: API backends, file processing, scheduled jobs, webhooks, automation.
• Containers win for long-running, predictable, high-throughput workloads and when you need full control of the runtime.
• The real risks are cold starts, statelessness, duplicate event delivery and cost surprises at sustained load, and each has a known mitigation.
• The decision should follow your workload pattern, not fashion. Many teams run a hybrid.

Table of Contents

• What serverless architecture actually means
• How billing works, and why it matters
• Serverless architecture examples
• Serverless advantages and disadvantages
• Serverless vs containers
• When to use serverless
• A practical checklist before you commit
• Our perspective
• Plan your architecture with Requestum
• FAQ
• Sources

What serverless architecture actually means

AWS describes serverless computing as an application development model where you build and deploy applications on infrastructure managed by a third party. All applications require servers. In the serverless model, the provider provisions them, scales them and keeps them patched, so your team works on code and business logic instead of operating systems and capacity planning.

In practice, a serverless architecture is built from three kinds of parts:

• Functions as a service (FaaS). Small units of code, such as AWS Lambda, Azure Functions or Google Cloud Functions, that run when triggered.
• Managed backend services. Databases, queues, object storage, authentication and API gateways that you configure rather than host.
• Event sources. HTTP requests, a file landing in a bucket, a message on a queue, a database change or a timer.

The design principle is that nothing sits idle waiting for work. An event arrives, the platform starts an execution environment, your function runs, and you are billed for that run. When traffic stops, the cost stops too.

How billing works, and why it matters

The consumption model is the main reason teams adopt serverless. According to AWS's decision guide on Fargate versus Lambda, you pay for the resources consumed while your code executes, typically measured in request count and execution duration, rather than for provisioned capacity that sits unused. Lambda's free tier, per the same research, covers 1 million requests and 400,000 GB-seconds of compute each month.

Two practical consequences follow:

1. Low and unpredictable traffic gets cheap. An internal tool used a few hundred times a day, or a campaign site that spikes once a quarter, costs very little compared with an always-on server.
2. Cost scales linearly with usage. That is a feature at small scale and a warning at large scale. AWS and Microsoft architects both note that for predictable, sustained, high-throughput workloads, per-invocation billing can end up costing more than provisioned compute, so a cost model built on your real traffic should come before any full migration.

If you are comparing what an always-on environment costs against pay-per-use, a quick way to feel the difference is to look at per-minute billing in other cloud products, such as per-minute cloud workstations with persistent storage, where you also pay for active time instead of a fixed monthly machine. The principle is the same: idle time should not be your biggest line item.

For a deeper look at trimming spend once you are in the cloud, see our guide to cloud cost optimization for FinOps.

Serverless architecture examples

The patterns below show up again and again in production systems.

REST or GraphQL API backend

An API gateway receives HTTP requests and routes each to a function, which reads or writes a managed database. Traffic that varies through the day is handled without capacity planning. This is the most common first serverless project.

File and media processing

A user uploads an image or PDF to object storage. The upload event triggers a function that resizes, scans, extracts text or hands the file to an ML model. Each file is processed independently and in parallel, so a burst of 10,000 uploads needs no extra setup.

Scheduled jobs and automation

Nightly reports, invoice generation, data syncs and cleanup tasks run on a timer. Instead of a server that is on 24 hours a day to work for ten minutes, a function wakes up, does the job and disappears. This is also where routine business automation, such as property-management notifications or document handling, fits well.

Event-driven integrations

Webhooks from payment providers, CRMs or marketplaces trigger functions that validate the payload, update records and notify other systems. Teams that wire many systems together often combine this with an API-first approach; the layered thinking in this piece on API-led integration shows how publishing and integration flows can be split into reusable layers, a pattern that maps naturally to event-driven functions. Our own API integration strategy covers OpenAPI-first design and service-level objectives.

Data and AI pipelines

Stream events land on a queue, functions transform them and write to a warehouse. For inference, a function can call a hosted model for each request. Heavy, long-running training jobs, though, belong on dedicated compute. For the pipeline side, see our breakdown of the four layers of a data engineering pipeline.

A simple worked example

Imagine a B2B app where customers upload invoices:

1. The upload lands in object storage.
2. A storage event triggers function A, which validates the file type and puts a message on a queue.
3. Function B reads the message, extracts the fields with an OCR or AI service, and writes a record to a managed database.
4. Function C sends the customer a notification and updates a dashboard.

No server is provisioned. If a customer uploads 5,000 invoices on the last day of the month, the platform runs many copies of function B in parallel. On a quiet Sunday, you pay close to nothing.

Serverless advantages and disadvantages

The benefits are real, but the disadvantages are mostly design problems that you can solve if you plan for them. Let's go through the ones that cause the most trouble.

Cold starts

When a function scales from zero, the platform has to start a new instance, which adds latency to that first request. Google describes this trade-off directly: scaling to zero saves money, but latency-sensitive applications can configure minimum instances so that some capacity stays warm. You trade a small standing cost for a smoother user experience. For background jobs, nobody notices a cold start; for a checkout page, you may care.

Statelessness

Functions keep no memory between invocations, so anything that must persist goes to a database, cache or storage. Microsoft's Azure guidance notes that teams struggle most when they force complex, stateful workflows into stateless functions, and recommends orchestration such as Durable Functions in the Azure Well-Architected guidance. AWS Step Functions plays the same role on AWS. If a process has many steps, waits for humans or needs retries, put an orchestrator in charge of state instead of chaining functions by hand.

Duplicate events

Platforms can deliver the same event more than once during retries. The AWS Serverless Applications Lens tells teams to make functions idempotent: check for an existing record or state before you apply a change, so that processing the same payment event twice does not charge a customer twice.

Execution limits

Functions are short-lived by design. On Lambda, the maximum timeout is 15 minutes, and an API gateway in front can cut requests off much sooner. Work that runs longer needs to be split into steps, handed to an orchestrator, or moved to a container.

Cost surprises

The usual causes are a function stuck in a retry loop, chatty calls between functions, or very high steady volume. Set budgets and alerts from the first week, and model your expected request volume before committing.

Serverless vs containers

This is the question behind most architecture reviews. Cloudflare's comparison of serverless and containers frames it as control versus abstraction: containers, often orchestrated with Kubernetes, give you full control of the runtime and suit long-running, steady processes, while serverless functions suit event-driven, short-lived tasks.

There is also a middle path. Managed container services that scale automatically, such as the Fargate option AWS compares against Lambda in its decision guide, give you container packaging with much of the operational relief of serverless. If you are reading the choice as a strict either-or, it usually is not one.

When to use serverless

Choose serverless when most of these are true:

• Traffic is variable, seasonal or unpredictable, or the app is new and demand is unknown.
• Work is triggered by events and finishes in seconds or a few minutes.
• Your team is small and you would rather spend time on product than on infrastructure.
• You want to launch an MVP quickly and keep the idle cost near zero.
• The workload can be split into independent, stateless steps.

Choose containers, or a mix, when:

• Load is high and constant, so provisioned capacity is cheaper per unit of work.
• Processes run for hours, hold connections open or need local state.
• You need specific runtimes, system libraries, GPUs or a custom network setup.
• Strict latency targets leave no room for cold starts.
• Portability across clouds is a hard requirement.

As the cloud architects cited above stress, successful adoption depends on the workload pattern rather than the type of application. A hybrid is common: containers for the core, steady services and serverless for event-driven or bursty edges. Our article on web application architecture shows how to run these checks from patterns through deployment, and the 7 Rs of cloud migration help decide which existing components are worth re-architecting at all.

A practical checklist before you commit

1. Map the workload. Requests per second, burst size, run time per task, and how steady the pattern is over a month.
2. Model the cost at three volumes. Today, 10 times today and your realistic ceiling. Compare against a provisioned container setup.
3. Identify stateful parts. Decide where state lives and whether an orchestrator is needed.
4. Design for retries. Make every handler idempotent and send failed events to a dead-letter queue.
5. Set a latency budget. If cold starts matter, plan for minimum instances or provisioned concurrency.
6. Protect downstream systems. Cap concurrency so a burst of functions does not flatten your database.
7. Instrument from day one. Structured logs, traces and cost alerts.
8. Plan an exit. Keep business logic in plain libraries and keep the provider-specific glue thin.

Our perspective

We build web, mobile and AI products for clients across industries, and we rarely treat serverless as a religion. What we see in discovery is that the architecture question is almost never "serverless or not". It is "which parts of this product have which traffic shape".

Our default for a new product is to start with the pieces where serverless clearly pays off: webhooks, file processing, scheduled automation, AI inference calls and light APIs. Those parts are where a small team gains the most speed. We keep the core transactional services in containers when load is steady, when they need long-lived connections, or when the client wants portability. Automation of routine work, for example in property management, and event-driven AI features are a natural fit for functions and queues.

The mistakes we see most often are not exotic. Teams skip the cost model, forget idempotency, or chain ten functions together where a workflow engine belongs. A short business analysis and discovery phase catches these before they are written into code, and that is far cheaper than a rewrite. If your AI workloads are part of the picture, we also look at how LLM features reach production and how MLOps practices keep them reliable.

— Dmitry

Plan your architecture with Requestum

If you are deciding between serverless, containers or a hybrid for a new product or a modernization project, our team can help you map the workload, model the cost and build it. We start with a discovery phase and take projects through design, development and QA. See our web development services for custom web applications, CRMs, ERPs and marketplaces, or explore AI development services if event-driven AI features are on your roadmap. AI Development Services are listed at 30000-60000 USD one-off. For a first conversation about scope, start from our services overview.

FAQ

Is serverless always cheaper than containers?

No. Serverless is usually cheaper for low, spiky or unpredictable traffic because you pay nothing while idle. For sustained, predictable, high-throughput workloads, per-invocation billing can cost more than provisioned compute, so model your own traffic before deciding.

Why do some teams move away from serverless?

The common reasons are cost at steady high volume, cold-start latency, execution time limits and complex stateful workflows that fit poorly into stateless functions. Most of these come from applying serverless to the wrong workload, and many teams respond by moving only those components to containers rather than abandoning the model.

What are valid examples of serverless technologies?

Function services such as AWS Lambda, Azure Functions and Google Cloud Functions are the best known. Managed pieces like API gateways, object storage, queues, NoSQL databases and workflow orchestrators such as Step Functions or Durable Functions complete a serverless architecture.

Can serverless handle long-running processes?

Not inside a single function, since execution is capped; Lambda's limit is 15 minutes. You can split the job into steps coordinated by an orchestrator that tracks state and retries, or run that part in a container.

Sources

• What is Serverless Computing? (AWS)
• Choosing between AWS Fargate and AWS Lambda (AWS decision guide)
• Serverless Applications Lens, AWS Well-Architected Framework
• Architecture Best Practices for Azure Functions (Microsoft Learn)
• Cloud Run adds min instances feature for latency-sensitive apps (Google Cloud Blog)
• Serverless vs. containers (Cloudflare)
• AWS Lambda Timeout Best Practices (Dash0)

Recommended

• Web Application Architecture: 6 Checks From Patterns to Deployment
• 5 Step API Integration Strategy for Engineers: OpenAPI First, SLOs
• Recover 30–50% in 30 Days: Cloud Cost Optimization for FinOps
• Ship CI/CD Pipelines Faster with Copyable YAML and Five Stages