Serverless architecture

Build an application from managed services and short-lived functions, so none of the servers are yours to run.

Live modeldata or requestresponsebusy / idle instance

What you’re watchingThe pet store without servers of its own. The browser reads listings straight from the hosted database; search and checkout go through the gateway, which rejects calls without a valid token, to functions that start on demand (amber marks a cold start).

How it works

A serverless architecture builds an application from two kinds of parts that someone else operates. The first is backend as a service (BaaS): hosted databases, sign-in, file storage, queues and other services that your code, and sometimes the browser itself, calls over an API. The second is functions as a service (FaaS): your own code, cut into handlers that a platform such as AWS Lambda starts when an event arrives (an HTTP request through an API gateway, a new file, a queue message, a schedule) and stops when the work is done. Nothing of yours runs while there are no events, so idle time costs little or nothing, and capacity follows traffic without anyone resizing a cluster. The shape of the code changes too. A function can’t count on keeping state between invocations, so state lives in the managed services. Steps are chained through events, queues and workflow services instead of in-process calls. Some logic moves into the client, which may read a database directly under per-user access rules (Firebase Security Rules, for example). The costs are real. Every hop is a network call and some are billed per call, so chatty designs get slow and expensive. Platform limits shape the design: Lambda stops a function after 15 minutes and allows 1,000 concurrent executions by default. And the app is wired to one vendor’s services, which makes it harder to move and to run on a laptop.

Think of it as

Throwing a party in a rented hall with caterers instead of cooking at home. You choose the menu and the guest list; staff turn up when guests do and leave when they go, and you pay per guest. But you can’t rearrange their kitchen, and moving the party means hiring everyone again.

Reach for it when

Event-driven products that react to uploads, messages, webhooks and schedules
Spiky, unpredictable or low traffic, where idle servers would cost more than they earn
Small teams that would rather ship features than run servers, databases and patching
Glue between managed services in one cloud

Think twice when

Steady high load or lots of data passed between steps: Prime Video’s stream-monitoring service hit a hard scaling limit at about 5% of its expected load and cut costs by 90% by moving into one process
Long-running or stateful work, like jobs longer than the function timeout or game state held in memory
You must stay portable across clouds or run fully on your own hardware
Latency-critical paths that can’t absorb the occasional cold start

A real example

Mike Roberts’s classic example is an online pet store. The traditional version is one server application that handles sign-in, browsing, search and purchases in front of a database. The serverless version deletes most of it. Sign-in moves to a hosted auth service such as Auth0, and the browser reads product listings straight from a hosted database such as Firebase. Only search and purchase stay as server code, each a function behind an API gateway; purchase stays on the server for security. The browser grows into a single-page app that keeps track of the session itself.

Technologies

Specific products, and what each does differently.

SSTOpen sourceA TypeScript framework that defines a whole app, from Next.js front end to functions, containers and databases, in one config file and deploys it to your own AWS or Cloudflare account.Mainly Infrastructure as code


SST	Open source	Anomaly Innovations	MIT	2026-10-06

What each provider calls it

AWS: Lambda with API Gateway, SQS, SNS, EventBridge, Step Functions, DynamoDB and Cognito
Google Cloud: Cloud Run and Cloud Run functions with Pub/Sub, Eventarc, Workflows, Firestore and Firebase
Azure: Azure Functions with API Management, Service Bus and Azure Cosmos DB serverless
Open source & others: SST (MIT) to define and deploy the wiring; Knative for functions on Kubernetes; Supabase (Apache 2.0), an open-source Firebase-style backend

Who runs what in the pet store#

Following Roberts’s example: the same features, moved out of one server application.

Feature	Traditional three-tier	Serverless
Sign-in	Code in the server application	A hosted auth service (BaaS), such as Auth0 or Cognito
Browsing products	The server reads the database and renders pages	The browser reads a hosted database directly, under access rules
Search	The server application	A function behind an API gateway
Purchase	The server application	A separate function behind the gateway, kept server-side for security
Session and page flow	The server	The single-page app in the browser
Always-on servers you run	The application server and the database	None

In code · ts

// sst.config.ts: the whole backend is managed services plus three functions
const products = new sst.aws.Dynamo("Products", {
  fields: { sku: "string" },
  primaryIndex: { hashKey: "sku" },
});

const orders = new sst.aws.Queue("Orders");
orders.subscribe("src/fulfil.handler");        // runs once per message

const api = new sst.aws.ApiGatewayV2("Api", { link: [products, orders] });
api.route("GET /search", "src/search.handler");      // reads Products
api.route("POST /checkout", "src/checkout.handler"); // charges, then queues the order

Often confused with

Serverless functions (FaaS)Monoliths Microservices API gateways Event buses Workflow orchestration Authentication Local cloud emulators Monolith, microservices or serverless?

Where it came from2012–2023

The word came before the platforms. In October 2012 Ken Fromm, then at Iron.io, wrote that cloud apps were “moving into a serverless world”, adding that the phrase doesn’t mean servers are gone, only that developers no longer have to think much about them. The parts already existed: hosted “mobile backend as a service” products such as Parse and Firebase gave apps a database and sign-in without a server of their own.

AWS Lambda, announced on 13 November 2014, added the missing piece: your own code, run on demand when an S3 upload, a Kinesis record or a DynamoDB update arrived, with nothing to configure or scale. According to Mike Roberts, the term caught on in 2015, growing after Amazon API Gateway launched that July and let functions answer HTTP. By the end of 2015 the JAWS project had renamed itself the Serverless Framework, and by mid-2016 “serverless” was the usual name for the area. Roberts’s article on Martin Fowler’s site, last updated in May 2018, gave the standard definition: applications built from BaaS and FaaS, with no always-on server component of your own.

Academics split on it. In December 2018 Joseph Hellerstein and colleagues at Berkeley argued in “One Step Forward, Two Steps Back” that first-generation serverless was a bad fit for data-heavy and distributed work. In February 2019 another Berkeley group, including David Patterson and Ion Stoica, predicted that serverless computing “will grow to dominate the future of cloud computing.” In 2023 Prime Video’s write-up of moving a monitoring service from Step Functions and Lambda to a single process, cutting its costs by 90%, became the best-known case for where the style doesn’t fit.

Why it’s built this way

Buy the backend instead of building it: Roberts’s pet store replaces its own sign-in with Auth0 and its own data layer with a hosted database. Less code to write and run, at the price of depending on vendors you can’t change.
Functions start on events and keep no state: Because a platform can start and stop each function freely, it can scale to traffic and bill only for work done. In return, state must live in a database, cache or queue, never in the function.
Let the client do more: With per-user access rules on the database, the browser can read data directly, so there is less server code. Some logic then moves into the client, and Roberts warns it may be repeated across web and mobile apps.
Accept one vendor’s platform: Roberts calls lock-in a legitimate concern but still recommends picking one vendor and using its services fully, since staying cloud-agnostic often costs more.

Timeline

2012
Ken Fromm writes “Why The Future Of Software And Apps Is Serverless”
2014
AWS announces Lambda
2015
Amazon API Gateway launches; JAWS becomes the Serverless Framework
2018
Mike Roberts’s “Serverless Architectures” reaches its final major version; Hellerstein et al. publish “One Step Forward, Two Steps Back”
2019
Berkeley’s “Cloud Programming Simplified” predicts serverless will dominate cloud computing
2023
Prime Video moves a monitoring service from serverless parts to one process, cutting costs 90%

Sources16

Improve this page on GitHub