Software architecture
Serverless architecture
Serverless architecture runs application code as managed functions and services that the cloud provider provisions, scales and bills per use.
Teams choose serverless to ship a backend without running one. Functions start when a request or event arrives, scale with the load and stop costing anything when traffic stops, which suits small teams, new products and anything with spiky usage.
Why does serverless architecture matter?
- No infrastructure to operate. No instances to size, patch, monitor or replace.
- Scales automatically, including to zero. A function that handles one request a day costs almost nothing; the same code handles a thousand per second.
- Pay per use. Billing follows invocations and milliseconds, not reserved capacity.
- Fits event-driven designs. Functions are triggered by requests, queue messages, file uploads and schedules, which makes them natural consumers in an event-driven architecture.
What are the parts of a serverless architecture?
- Functions. Small units of code, each with one handler, that the provider runs on demand. AWS Lambda, Azure Functions, Google Cloud Functions and Cloudflare Workers are the main platforms.
- Triggers. The events that invoke a function: an HTTP request, a queue message, a file upload, a schedule.
- API gateway. The managed front door for HTTP traffic. It maps routes to functions and handles authentication, throttling and TLS. See API gateway.
- Managed data services. Databases such as DynamoDB or Aurora Serverless, object storage such as S3 and caches, all billed per use and scaled by the provider.
- Queues and streams. SQS, Pub/Sub, EventBridge and similar services that buffer work between functions and trigger the next step.
The gateway and functions play the application tier of a three-tier architecture, and the managed database and storage play the data tier.
How do you read a serverless architecture diagram?
Follow the request, then follow the events. In the photo upload example at the top of this page, a mobile app calls the API gateway over HTTPS, an ordinary client-server call. The gateway invokes the upload function, which writes the photo’s metadata to the managed database and the file itself to object storage, then puts a job on the queue and returns.
The dashed arrows are where the request ends and events take over. The queue triggers the thumbnail function, which generates a thumbnail and writes it back to object storage. The mobile app never waits for that work, and if the function fails the job stays on the queue to be retried.
Everything inside the tinted group is a managed service; there is no server to draw. The questions this raises are the serverless ones: how long is the cold start on the upload function, and what does the bill look like if uploads spike to a million a day?
What is a cold start and why does it matter?
When a function receives a request and no idle instance is available, the provider provisions a sandbox, downloads the code, starts the runtime and runs any initialization outside the handler, such as opening database connections. That is a cold start. A warm start reuses an instance that already did all of this and goes straight to the handler.
Cold start latency depends on the runtime, the package size and how much work the initialization does. Small interpreted functions start in tens of milliseconds; large Java or .NET functions with heavy frameworks can take seconds. The usual mitigations are keeping packages small, moving work out of initialization and paying for a minimum number of warm instances.
How is serverless priced?
| Service | Billed by | Idle cost |
|---|---|---|
| Functions | Invocations plus memory multiplied by duration | None |
| API gateway | Requests and data transferred | None |
| Managed database | Reads, writes and storage, or provisioned capacity | Storage only |
| Object storage | Storage, requests and egress | Storage only |
The model rewards bursty and low-volume workloads, which is why internal tools are nearly free and a sudden spike costs money but does not fail. At sustained high volume a function running continuously is billed for every millisecond, and at some throughput a container on a reserved instance is cheaper. Model the bill at expected peak before committing.
When should you not use serverless?
- Long-running work. Functions have execution limits, typically around fifteen minutes. Video transcoding and large reports belong in a container.
- Latency-critical requests. If a 500 millisecond cold start is unacceptable and warm instances are too expensive, an always-on service is simpler.
- Steady, high throughput. Per-millisecond billing at constant load costs more than reserved capacity.
- Portability requirements. Triggers, permissions and managed services are provider-specific. Moving a serverless system between clouds is a rewrite of everything except the handlers.
How does serverless compare with other architectures?
| Serverless | Containers | Virtual machines | |
|---|---|---|---|
| Unit of deployment | Function | Container image | Machine image |
| Who scales it | Provider, automatically | Orchestrator, with rules you write | You |
| Scales to zero | Yes | Usually no | No |
| Billing | Per invocation and millisecond | Per running container or node | Per hour, running or idle |
Serverless is not the opposite of microservices. Many teams run some services as containers and others as functions, and a small monolith can even be deployed as one function. Which compute model each part uses is a system architecture decision, best recorded in an architecture diagram.
What tools help with serverless architecture?
- Infrastructure as code frameworks. The Serverless Framework, AWS SAM, Terraform and Pulumi define functions, triggers and permissions as code, which is essential once a system has more than a handful of functions.
- Distributed tracing. AWS X-Ray, OpenTelemetry and similar tools show where a request spent its time across gateway, functions and queues.
- AI diagramming tools. Tools like Eraser turn infrastructure code or a description of your functions, triggers and managed services into an AWS diagram or architecture diagram you can keep editing, which is the easiest way to see a system with no servers to point at.
For more on this kind of diagram, see architecture diagrams.
Frequently asked questions
-
Are there really no servers in serverless?
There are servers, but you never see them. The cloud provider owns, patches, scales and replaces them, and you deploy code and configuration against an API instead of an operating system. The name describes the developer's experience, not the data center. If you need to choose an instance size, it is not serverless.
-
What is a cold start?
A cold start is the delay before a function handles its first request on a new instance, while the provider provisions a sandbox, loads the runtime and your code and runs any initialization. It ranges from under 100 milliseconds for small functions to several seconds for large ones. Later requests to the same warm instance skip it.
-
How is serverless priced?
Per use. Functions bill by the number of invocations and the memory multiplied by the milliseconds each one runs. Managed databases, queues and storage bill by requests, throughput and data stored. Idle costs nothing, which is ideal for spiky or low traffic, but at sustained high volume the per-request price can exceed the cost of always-on servers.
-
What is the difference between serverless and containers?
Containers package an application with its dependencies and run it on infrastructure you size and keep running, whether that is Kubernetes or a managed container service. Serverless functions package a single handler that the provider starts on demand and stops when idle. Containers give more control and longer-running processes; serverless gives less operations work and scale to zero.
