What Does "Serverless" Actually Mean?
The name "serverless" is a slight misnomer — there are absolutely still servers involved. What it means is that you don't see, manage, or pay for the servers when your code isn't running. The cloud provider owns and operates all the underlying infrastructure; you simply deploy your code and let the platform handle the rest.
In traditional cloud computing (IaaS), you provision a virtual machine, install an OS, configure software, and pay for that VM 24/7 whether it's doing anything or not. In serverless, the model flips: your code sleeps when there's nothing to do, wakes up in milliseconds when triggered, executes, and then goes dormant again. You pay only for the compute time consumed during execution — typically measured in 1-millisecond increments.
This model delivers three major advantages: no infrastructure management (no OS patching, no capacity planning, no server configuration), automatic scaling (the platform scales from 0 to thousands of concurrent executions instantly without any configuration), and pay-per-use billing (a function that runs 1,000 times per month costs a tiny fraction of a VM that runs idle 99.9% of the time).
FaaS — Function as a Service
FaaS is the compute model that underlies serverless. The key characteristics of a serverless function are:
AWS Lambda — The Most Widely Used FaaS Platform
AWS Lambda, launched in 2014, popularised the serverless model and remains the most widely used FaaS platform. Understanding Lambda is essential for AWS certifications and gives you a solid mental model for Azure Functions and Google Cloud Functions, which work similarly.
A Lambda function consists of your code (uploaded as a ZIP file or container image), a runtime (the language environment — Node.js, Python, Java, Go, .NET, Ruby, and more are supported), and a handler (the entry point function within your code that Lambda calls). You configure the function's memory (128 MB to 10 GB), timeout (up to 15 minutes), and the IAM role that defines what AWS resources it can access.
Lambda functions are priced on two dimensions: invocation count (the first 1 million requests per month are free; $0.20 per million thereafter) and compute duration (charged in 1-millisecond increments based on memory allocation). For many workloads, Lambda is dramatically cheaper than running equivalent EC2 instances — a function that runs 100ms, 100,000 times per day, costs roughly $2/month.
AWS Lambda — the original FaaS service, launched 2014. Most widely used.
Azure Functions — Microsoft's equivalent. Integrates tightly with Azure Event Grid, Service Bus, and Cosmos DB triggers.
Google Cloud Functions (1st gen) and Cloud Run functions (2nd gen) — Google's FaaS offerings. Integrates with Pub/Sub, Firestore, and Cloud Storage triggers.
Cloudflare Workers — a serverless edge computing platform that runs functions at CDN edge locations worldwide, not just in datacenters. Extremely low latency for globally distributed workloads.
Event-Driven Architecture
Serverless functions are naturally stateless and short-lived, which makes them a perfect fit for event-driven architecture (EDA) — a design pattern where application components communicate by producing and consuming events rather than by making direct, synchronous API calls.
In a traditional monolithic or microservices architecture, Service A calls Service B directly: "process this payment now." In an event-driven architecture, Service A emits an event: "payment submitted" — and any interested services (payment processor, notification service, inventory system, audit logger) independently consume and react to that event. The producer doesn't know or care who consumes it.
This decoupling has significant benefits: resilience (if the notification service is down, the payment still processes — the event is queued), scalability (each consumer scales independently based on its queue depth), and extensibility (add a new consumer without changing the producer). The trade-off is increased system complexity and the need for careful management of event ordering and delivery guarantees.
Common Serverless Use Cases
Serverless vs Containers vs VMs
| Property | Serverless (FaaS) | Containers | Virtual Machines |
|---|---|---|---|
| Infrastructure management | None — fully managed | Low — manage container orchestration | High — manage OS, patching, scaling |
| Scaling | Automatic, scales to zero | Automatic with orchestrator (K8s) | Manual or scheduled auto-scaling |
| Billing model | Per invocation + duration (ms) | Per running container (seconds) | Per running VM (hours) |
| Cold start | Yes — latency on first invocation | Minimal (containers start in ms) | Slow (minutes to boot OS) |
| Max execution time | 15 min (Lambda), varies by provider | Unlimited | Unlimited |
| Stateful workloads | Poor — stateless by design | Good — with persistent volumes | Best — full persistent storage |
| Best for | Irregular, event-driven, short tasks | Microservices, consistent workloads | Legacy apps, full OS control needed |
The Cold Start Problem
The most discussed performance trade-off of serverless is the cold start. When a serverless function hasn't been invoked for a period of time, the provider scales it down to zero — no execution environment is running. When the next request arrives, the provider must: (1) allocate compute resources, (2) download and initialise the function code, (3) start the language runtime, and (4) execute the handler. This process typically adds 100ms to several seconds of latency on top of the normal execution time.
Cold starts are worst with runtimes that have slow initialisation — Java and .NET have significantly worse cold starts than Node.js or Python because of JVM/CLR startup overhead. Large deployment packages (ZIP files with many dependencies) also increase cold start time.
Mitigation strategies: AWS Lambda Provisioned Concurrency keeps a specified number of execution environments pre-warmed, eliminating cold starts for latency-sensitive workloads (at additional cost). Keeping functions warm with periodic scheduled pings (every few minutes) is a cheaper but less reliable approach. Choosing lightweight runtimes (Node.js, Python) and minimising deployment package size also reduces cold start impact.
Serverless = no server management + pay-per-use + auto-scale.
FaaS = functions triggered by events, stateless, short-lived.
Cold start = latency on first invocation after idle period.
Event-driven = producers emit events, consumers react independently. The decoupling is the key architectural benefit.
Serverless Security Considerations
Serverless shifts the security boundary significantly toward the application layer. Since the provider manages the underlying infrastructure, you no longer need to patch OS vulnerabilities or harden server configurations — but you are fully responsible for your function code, dependencies, and IAM permissions.
Overly permissive IAM roles are the most common serverless security mistake. Following the principle of least privilege is critical: each Lambda function should have its own IAM role with only the permissions it specifically needs. A function that reads from one S3 bucket should not have write access to other buckets or access to unrelated services.
Dependency vulnerabilities in your function's package dependencies (npm packages, Python pip packages) are a significant risk. Serverless functions often pull in many third-party packages, each of which may contain known CVEs. Regular dependency scanning and updates are essential.
Injection attacks remain relevant in serverless — SQL injection, command injection, and event data injection can all occur if function code processes user-supplied input without proper validation and sanitisation.
Key Scenarios
Preparing for a Cloud Certification?
Check out the best study resources for AWS, Azure, and CompTIA cloud exams.