Getting Started with Serverless

What is Serverless?

Serverless is a cloud execution model where the cloud provider dynamically manages the allocation and provisioning of servers. As a developer, you write and deploy functions (small units of code) without thinking about the underlying infrastructure — no servers to configure, patch, or scale.

The name is slightly misleading: servers absolutely exist. You just don’t manage them. The cloud provider handles:

Provisioning
Scaling (up and down, including to zero)
Availability and fault tolerance
OS patching and maintenance

You pay only for the compute time your code actually runs — to the nearest millisecond. When your function isn’t running, you pay nothing.

Key mental model: Traditional servers sit idle waiting for requests. Serverless functions wake up on demand, run, and vanish.

Simple Serverless Architecture Diagram

                            ┌─────────────────────────┐
                            │        CLIENT            │
                            │  (Browser / Mobile App)  │
                            └────────────┬────────────┘
                                         │  HTTPS Request
                                         ▼
                            ┌─────────────────────────┐
                            │      API GATEWAY         │
                            │  (Routes + Auth layer)   │
                            └──────┬──────────┬────────┘
                                   │          │
                    ┌──────────────┘          └──────────────┐
                    ▼                                         ▼
         ┌──────────────────┐                    ┌──────────────────┐
         │  Lambda Function │                    │  Lambda Function │
         │  POST /orders    │                    │  GET /products   │
         └────────┬─────────┘                    └────────┬─────────┘
                  │                                        │
                  ▼                                        ▼
         ┌──────────────────┐                    ┌──────────────────┐
         │    DynamoDB      │                    │      S3 Bucket   │
         │  (Orders table)  │                    │  (Product data)  │
         └──────────────────┘                    └──────────────────┘
                  │
                  │ Event trigger (on write)
                  ▼
         ┌──────────────────┐
         │  Lambda Function │
         │  Send confirm.   │
         │  email via SES   │
         └──────────────────┘

Key components in this diagram

Component	Role
API Gateway	The front door — routes HTTP requests to the right function
Lambda Functions	Your business logic — each function does one thing
DynamoDB	Serverless NoSQL database (scales automatically)
S3	Object/file storage
SES	Simple Email Service — triggered by a database event

Advantages of Serverless

Cost

Pay-per-use — you are billed only for execution time (milliseconds), not idle time
AWS Lambda free tier: 1 million requests and 400,000 GB-seconds of compute per month
No wasted spend on under-utilised servers running 24/7

Scalability

Automatic and instant — scales from 0 to thousands of concurrent executions without any configuration
Handles traffic spikes (e.g. a product launch) without pre-provisioning

Reduced operational overhead

No server management, OS patching, or capacity planning
Teams focus on writing business logic, not DevOps
Fewer moving parts to go wrong

Faster time to market

Deploy a function in minutes
Ideal for prototyping, MVPs, and startups

High availability built-in

Cloud providers run functions across multiple availability zones by default

Disadvantages of Serverless

Cold starts

When a function hasn’t been called recently, the provider must spin up a new container — this adds latency (100ms–2s) to the first request
Mitigations: provisioned concurrency (AWS), keeping functions warm with scheduled pings
Less of a problem for background/async workloads

Vendor lock-in

Functions are tightly coupled to provider-specific triggers (S3 events, DynamoDB streams, API Gateway)
Migrating from AWS Lambda to Google Cloud Functions or Azure isn’t trivial
Mitigation: frameworks like the Serverless Framework or AWS SAM help abstract some of this

Debugging and observability is harder

No persistent server to SSH into
Logs are distributed across many short-lived executions
Requires tooling: AWS CloudWatch, Datadog, X-Ray, or OpenTelemetry
Local testing requires emulation (e.g. LocalStack, AWS SAM local)

Execution time limits

AWS Lambda: maximum 15 minutes per invocation
Not suitable for long-running processes (video transcoding, heavy ML inference)

Stateless by design

Functions have no persistent memory between invocations
State must live in an external store (database, cache, S3)
Can be a conceptual shift for developers used to long-running processes

Potential for unexpected costs

At very high scale (millions of requests per second), serverless can become more expensive than reserved server instances
A misconfigured function in an infinite loop can rack up unexpected charges quickly

Interesting Example: Image Processing Pipeline

One of the most compelling real-world uses of serverless is automated image processing at scale.

User uploads photo
        │
        ▼
   S3 Bucket (raw uploads)
        │
        │ S3 Event triggers automatically
        ▼
  Lambda Function
  ┌─────────────────────────────────┐
  │ 1. Resize to thumbnail          │
  │ 2. Resize to web (1200px)       │
  │ 3. Strip EXIF metadata (privacy)│
  │ 4. Run through content moderation│
  │    API (e.g. AWS Rekognition)   │
  │ 5. Save processed images to S3  │
  │ 6. Update database record       │
  └─────────────────────────────────┘
        │
        ▼
  S3 Bucket (processed images)
  + DynamoDB updated with image URLs

Why this is a great fit for serverless

Irregular, bursty traffic — uploads don’t happen at a steady rate
Each upload is independent — perfect for parallel, stateless execution
Only pay when photos are actually being uploaded
A traditional server would sit idle most of the time

Real-world scale example

Netflix uses serverless functions for encoding pipeline tasks. When you upload a video (e.g. as a content creator on a platform), dozens of Lambda functions fire in parallel to produce different resolutions, subtitles, and device-optimised formats — all without a dedicated transcoding fleet.

AWS Lambda — Key Facts

Lambda is AWS’s flagship serverless compute service and the most widely used in the industry.

Runtime support

Lambda supports: Node.js, Python, Java, Go, Ruby, .NET, and custom runtimes via container images.

Execution model

An event triggers the function (HTTP request, S3 upload, DynamoDB change, cron schedule, SQS message, etc.)
Lambda provisions a sandboxed container (a micro-VM using Firecracker)
Your handler function runs
The container may be reused for a short time (warm start) or discarded

Pricing (as of 2025)

$0.20 per 1 million requests
$0.0000166667 per GB-second of compute
Free tier: 1M requests + 400,000 GB-seconds per month (never expires)

Lambda Layers

Reusable packages (e.g. numpy, ffmpeg, shared utilities) that can be attached to multiple functions — avoids duplicating dependencies across deployments.

Lambda + EventBridge (Cron)

You can schedule Lambda functions to run on a cron schedule — useful for nightly data jobs, cleanup tasks, or sending digest emails:

EventBridge Rule: "cron(0 8 * * ? *)"  →  Lambda: send_daily_digest()

Concurrency model

Each request gets its own isolated execution environment
Lambda can run up to 10,000 concurrent executions by default (increasable)
This means 10,000 simultaneous users = 10,000 Lambda containers running in parallel

Serverless vs Traditional vs Containers — Quick Comparison

	Traditional Server	Containers (Docker/K8s)	Serverless
Provisioning	Manual	Semi-automated	Fully managed
Scaling	Manual / slow	Automated (minutes)	Instant, to zero
Billing	Always-on	Always-on	Pay-per-use
Execution limit	None	None	15 min (Lambda)
Cold start	None	Slow (container boot)	Fast (~100ms)
State	Persistent	Persistent	Stateless
Best for	Long-running, predictable workloads	Microservices, complex apps	Event-driven, variable traffic

Other Serverless Providers

Provider	Product	Notes
AWS	Lambda	Market leader, widest ecosystem
Google Cloud	Cloud Functions / Cloud Run	Cloud Run supports containers serverlessly
Microsoft Azure	Azure Functions	Deep .NET integration
Cloudflare	Workers	Runs at the edge (globally distributed), V8 isolates = near-zero cold starts
Vercel / Netlify	Edge Functions	Popular with frontend developers

Key Takeaways

Serverless ≠ no servers — it means you don’t manage servers
It’s best suited to event-driven, stateless, variable-traffic workloads
Cold starts are the main technical gotcha — understand when they matter
Cost efficiency is the headline benefit, but vendor lock-in is a real trade-off
AWS Lambda is the dominant player — understanding it covers ~70% of what you’ll encounter
Serverless pairs naturally with microservices — each function does one thing well