Introduction
Serverless computing does not mean there are no servers — it means the developer never provisions, patches, or manages them. The most common form is Function-as-a-Service (FaaS), such as AWS Lambda, Azure Functions, or Google Cloud Functions, where you upload a small piece of code (a function) and the cloud provider runs it automatically whenever a defined event occurs, then tears the execution environment down when it's done.
Cricket analogy: A stadium doesn't keep floodlight crews on standby around the clock — they show up, do the job when a night match is scheduled, and leave, much like a serverless function that only runs when a specific event triggers it and then disappears.
Explanation
FaaS functions are event-triggered: an HTTP request through an API gateway, a new file uploaded to object storage, a message arriving on a queue, or a scheduled timer can all invoke a function. The provider handles capacity, patching, scaling, and high availability entirely behind the scenes — you write only the handler logic. Billing is usage-based, typically calculated per invocation plus the actual compute duration (often billed in milliseconds) multiplied by the memory allocated to the function, so you pay nothing while the function is idle and are never charged for a persistently running server.
Cricket analogy: A stadium's emergency medical response can be triggered by a batsman's injury, a fan's incident in the stands, or a scheduled pre-match check, and the venue handles staffing and readiness behind the scenes — the team only defines what happens once triggered, and costs apply only when actually called.
The main tradeoff of this model is the 'cold start.' Because the provider does not keep an idle server running for you, the very first invocation after a period of inactivity (or a new concurrent invocation beyond existing warm instances) requires the platform to provision a fresh execution environment: allocate compute, load the runtime, and initialize your code before it can process the event. This adds noticeable latency — often tens to hundreds of milliseconds, more for larger deployment packages or certain runtimes — compared to a 'warm' invocation that reuses an already-initialized environment. Cold starts matter most for latency-sensitive, user-facing requests and are usually mitigated with smaller deployment packages, provisioned concurrency, or by choosing lighter-weight runtimes.
Cricket analogy: A substitute fielder who's been sitting in the pavilion needs a few moments to warm up and get positioned before the first ball they field, unlike a fielder already warmed up and in position — that initial delay is like a cold start after inactivity.
Example
# Minimal AWS Lambda function configuration (SAM/CloudFormation style)
Resources:
ResizeImageFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs18.x
MemorySize: 256
Timeout: 10
Events:
S3Upload:
Type: S3
Properties:
Bucket: !Ref UploadsBucket
Events: s3:ObjectCreated:*Analysis
In the example above, the function only runs when an image is uploaded to a specific S3 bucket — there is no server sitting idle waiting for uploads. This is ideal for bursty, event-driven workloads like image processing, webhook handlers, or scheduled cleanup jobs, where traffic is unpredictable and a traditional always-on VM would sit mostly idle. It is a poor fit for workloads needing consistently low, predictable latency at high sustained volume, since cold starts and per-invocation overhead can outweigh the benefits compared to a warm, long-running service.
Cricket analogy: A stadium's ticket-scanning system only activates when a fan actually scans a ticket at the gate — there's no staff standing idle at every turnstile all match long, which works well for bursts at the gates but poorly for continuous, high-volume scanning needs.
Key Takeaways
- FaaS lets you deploy event-triggered functions without provisioning or managing any servers yourself.
- Billing is usage-based: per invocation plus compute duration and memory, with no charge while idle.
- A cold start is the added latency when the provider must initialize a fresh execution environment for a new or scaled-up invocation.
- Serverless suits bursty, event-driven workloads; it is less ideal for workloads needing consistently ultra-low latency at all times.
Practice what you learned
1. What does 'serverless' actually mean in serverless computing?
2. How is a typical FaaS function billed?
3. What causes a 'cold start' in serverless computing?
4. Which workload is generally the best fit for serverless FaaS?
Was this page helpful?
You May Also Like
Event-Driven Architecture
Understand how producers, consumers, and a message queue or event bus enable asynchronous, decoupled communication instead of synchronous request-response.
Microservices in the Cloud
See how managed containers, serverless platforms, service discovery, and API gateways make cloud-native microservices practical to build and operate.
Cost Optimization Basics
Learn concrete cloud cost-optimization levers such as right-sizing, reserved and spot instances, storage tiering, and auto-scaling.
Auto-Scaling Basics
Learn the difference between horizontal and vertical auto-scaling and how scaling policies use metrics like CPU utilization to trigger scaling actions.