INTRODUCTION TO SERVERLESS

COMPUTING
Serverless Computing is a cloud execution model where the cloud provider
dynamically manages the allocation and provisioning of servers. Despite the name,
servers do exist — but the developer never interacts with them.

The Two Pillars of Serverless

Pillar Description Examples

FaaS (Function as a Run individual functions AWS Lambda, Azure Functions, Google
Service) in response to events Cloud Functions
BaaS (Backend as a Fully managed backend Firebase, AWS DynamoDB, Auth0,
Service) services Amazon Cognito

 FaaS = Your custom logic runs without managing servers

 BaaS = You use pre-built backend services instead of coding them yourself
 Serverless = FaaS + BaaS combined
Detailed Comparison Table
Aspect Traditional (IaaS/VMs) Serverless (FaaS)

Server Management You provision, patch, scale Cloud provider manages everything

Scaling Manual or auto-scaling groups Automatic, instant, zero-config

(config required)
Billing Pay per hour/second (even when Pay per invocation + execution time
idle)
Deployment Unit Full application/container Individual functions

State Stateful (server persists) Stateless (each invocation is

independent)
Startup Time Minutes (boot VM) Milliseconds to seconds

Idle Cost 💰 You pay even when idle ✅ $0 when not running

Max Execution Time Unlimited Limited (e.g., 15 min for Lambda)

OS Access Full root/admin access No OS access

Concurrency Limited by instance size Thousands of parallel executions

The Cloud Computing Spectrum

More Control ◄────────────────────────────────────► Less Control

More Management Less Management

┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐

│ On- │ │ IaaS │ │ CaaS │ │ PaaS │ │ Serverless │
│ Premises │ │ (EC2, │ │ (ECS, EKS │ │ (Elastic │ │ (Lambda, │
│ │ │ VMs) │ │ Containers │ │Beanstalk) │ │ FaaS) │
└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
You manage: You manage: You manage: You manage: You manage:
Everything OS, Runtime, Containers, App Code, ONLY Code
App, Data App, Data Data & Data

HOW SERVERLESS WORKS: THE EXECUTION

MODEL

The given diagram illustrates the Serverless Execution Model (Function as a Service – FaaS)
and shows how cloud functions operate in an event-driven architecture. The system does not
run continuously. It runs only when an event happens. This is the foundation of serverless
computing.

The model consists of three main parts:

1. Events (Triggers) – Left Side

2. Cloud Function – Center
3. Outputs – Right Side

The key idea is:

An event occurs → it triggers a cloud function → the function processes it → produces an
output.

The left side of the diagram shows different types of events that can trigger a cloud function.

HTTP Request

 A user sends a request from a browser or mobile app.

 Usually handled via API Gateway.
 Common for REST APIs.

Example:
A user clicks “Submit Form” on a website → triggers Lambda function.

File Upload

 A file uploaded to cloud storage (e.g., AWS S3).

 Automatically triggers a function.

Example:
User uploads a profile picture → function resizes image.

Database Change

 When data is inserted / updated in a database.

 Triggers a function automatically.

Example:
New order added to database → function sends confirmation email.

Cloud Function (Center Component)

At the center is the Cloud Function (e.g., AWS Lambda, Azure Function, Google Cloud
Function).

What happens here?

1. Event payload is received.

2. Cloud provider creates (or reuses) execution environment.
3. Function code runs.
4. Logic is executed.
5. Output is generated.
6. Execution ends.
Key Properties:

 Stateless
 Short-lived
 Automatically scalable
 No server management required

You do NOT:

 Manage OS
 Configure web servers
 Handle scaling manually

The cloud provider manages infrastructure.

Outputs – Right Side

After processing, the function generates outputs.

Response

 Returns HTTP response to user.

 Used in APIs.

Example:
API returns:

{"message": "Order confirmed"}

Notification

 Sends email, SMS, or push notification.

 Often integrated with services like SNS.

Example:
Function sends order confirmation email.

Data Storage

 Stores processed data in database or storage.

Example:
Function stores form data in DynamoDB.
Complete Flow Explanation

Let’s describe the entire flow in simple steps:

1. An event occurs (HTTP request, file upload, database update).

2. The event triggers the cloud function automatically.
3. Cloud provider provisions execution environment.
4. Function code runs.
5. Function processes data.
6. Output is generated (response, notification, or storage).
7. Execution stops.

No server remains running after execution.

Why This Model is Powerful

This execution model provides:

 Pay-per-use billing (no idle cost)

 Automatic scaling
 Event-driven automation
 Reduced infrastructure complexity
 High availability

Example: Online Shopping System

Event:
Customer places order (HTTP request)

Cloud Function:

 Validates payment
 Updates inventory
 Saves order in database

Outputs:

 Sends confirmation email

 Stores order in database
 Returns response to user

All of this happens without managing any servers.

The Serverless Lifecycle
┌─────────────┐
│ EVENT │ (HTTP request, file upload, DB change, timer, etc.)
│ OCCURS │
└──────┬─────┘
│
▼
┌─────────────┐
│ CLOUD │ Provider detects the event
│ PROVIDER │
└──────┬──────┘
│
▼
┌─────────────┐
│ CONTAINER │ A lightweight container is spun up (or reused)
│ CREATED │
└──────┬──────┘
│
▼
┌─────────────┐
│ FUNCTION │ Your code is loaded & executed
│ EXECUTES │
└──────┬──────┘
│
▼
┌─────────────┐
│ RESPONSE │ Result returned to the caller
│ RETURNED │
└──────┬──────┘
│
▼
┌─────────────┐
│ CONTAINER │ Container stays warm briefly, then destroyed
│ RECYCLED │
└─────────────┘

 EVENT OCCURS
o What it means: Some event happens that should trigger your code.
Examples include an HTTP request, a file upload, a database change (like
a new row), or a timer.
o Role: This is the trigger that starts the whole process.

 CLOUD PROVIDER
o What it means: The cloud platform detects that an event has occurred.
 o Role: The provider is responsible for managing the function's lifecycle,
scaling, and execution environment.

 CONTAINER CREATED
o What it means: The platform creates (or reuses) a lightweight execution
environment, often referred to as a container.
o Role: This container is prepared to run your function’s code. If a suitable
container already exists (warm start), it may be reused to save setup
time.

 FUNCTION EXECUTES
o What it means: Your code is loaded into the container and runs in
response to the event.
o Role: This is where your business logic executes, processing the event
data and performing the desired actions.

 RESPONSE RETURNED
o What it means: The function returns a result back to the caller (the event
source or user that triggered the function).
o Role: The output of your function is sent back to complete the request, or
to trigger downstream processes.

 CONTAINER RECYCLED
o What it means: After execution, the container isn’t kept fully alive forever.
It stays warm for a short period to handle potential immediate subsequent
requests, then is destroyed if not needed.
o Role: This helps balance quick startup for new events with resource
efficiency. If another event arrives soon, a warm container can be reused;
otherwise, it’s released.

Summary of the lifecycle:

1. An event triggers the function.

2. The cloud provider detects the event.
3. A container is created or reused.
4. The function code is loaded and executed.
5. A response is returned to the caller.
6. The container may stay warm briefly, then be recycled/destroyed if not reused.

Notes:

 “Warm start” vs “cold start” terminology: If a container is already running

(warm), startup is faster. If a new container is needed (cold start), there’s an
initialization delay.
 This model is common across many serverless platforms and helps scale
automatically while managing resources efficiently.
 Key Concepts
a) Event-Driven Execution
Functions are triggered by events — they don't run continuously.

Event Source Example

HTTP Request User calls an API endpoint

File Upload Image uploaded to S3 bucket

Database Change New record inserted in DynamoDB

Schedule/Cron Run every day at midnight

Message Queue Message arrives in SQS/SNS

IoT Sensor sends temperature data

b) Statelessness
 Each function invocation (request) is independent
 No memory of previous executions
 External storage (DynamoDB, S3, Redis) used for persistence

c) Ephemeral Containers
 The runtime environment is temporary
 Created on-demand, destroyed after idle timeout
 You have no control over the underlying infrastructure

KEY CHARACTERISTICS OF SERVERLESS

# Characteristic Description

1 No Server Management Zero infrastructure provisioning, patching, or maintenance

2 Event-Driven Functions execute only in response to triggers

3 Auto-Scaling Scales from 0 to thousands of instances automatically

4 Pay-Per-Use Billed only for actual compute time consumed

5 Stateless Each invocation is isolated; no shared state

6 Short-Lived Functions have maximum execution time limits

7 Vendor-Managed Cloud provider handles availability, fault tolerance, security patches

8 Polyglot Supports multiple programming languages

Platform Comparison

Google Cloud
Feature AWS Lambda Azure Functions Functions IBM Cloud Functions
Launched 2014 2016 2016 2016

Python, [Link],
C#, JS, Python, [Link], Python, Go, [Link], Python, Swift,
Languages Java, Go, C#, Ruby,
Java, PowerShell Java, Ruby, PHP PHP, Go
Custom

Max 10 min 9 min (1st gen), 60 min

15 min 10 min
Timeout (Consumption) (2nd gen)

Max 1,536 MB
10,240 MB 32 GB (2nd gen) 2,048 MB
Memory (Consumption)

Free Tier 1M requests/month 1M requests/month 2M requests/month 5M requests/month

Pricing
(per 1M $0.20 $0.20 $0.40 $0.00 (free)
req)

Pricing
$0.0000166667 $0.000016 $0.0000025 $0.000017
(GB-sec)

Deep
Largest (API GW, Based on Apache
Ecosystem Azure/Microsoft Tight GCP integration
DynamoDB, S3, etc.) OpenWhisk
integration

Market
🥇 Dominant 🥈 Strong 🥉 Growing Niche
Share

AWS SERVERLESS ECOSYSTEM (DEEP DIVE)

Below is a concise explanation of the AWS serverless ecosystem shown in the diagram.
What it illustrates

 A typical serverless data flow using managed services: user requests flow
through API Gateway to Lambda, which in turn reads/writes data in DynamoDB
and stores/files in S3. CloudWatch collects logs/metrics, and SNS can publish
notifications. The diagram highlights how components interact without managing
servers.

Components and roles

 User
o The client or end-user that initiates requests.
 Amazon API Gateway
o A fully managed service that creates, publishes, and secures RESTful APIs
or WebSocket APIs.
o Routes incoming HTTP requests to Lambda functions (and can handle
authentication, throttling, caching).

 AWS Lambda
o Serverless compute that runs code in response to events (e.g., API
Gateway requests).
o Automatically scales; you only pay for compute time used.
o In this diagram, Lambda processes the request and coordinates other
services (DynamoDB, S3).

 Amazon DynamoDB
o A fast, scalable NoSQL database.
o Used by Lambda to store or fetch structured data (e.g., items by key).

 Amazon S3
 o Object storage for files, images, logs, or large data blobs.
o Lambda can store or retrieve objects in S3 during its processing.

 Amazon CloudWatch
o Monitoring and observability service.
o Collects logs, metrics, and events from AWS resources (Lambda, API
Gateway, DynamoDB, etc.).
o Helps with debugging, performance, and alerting.

 Amazon SNS (Simple Notification Service)

o Publish/subscribe messaging service for fan-out notifications.
o In this diagram, SNS is connected to DynamoDB, implying a pattern where
data changes trigger notifications (e.g., new item added).

Data flow summary

 User → API Gateway: User sends a request which API Gateway exposes and
manages.
 API Gateway → Lambda: API Gateway triggers a Lambda function to handle the
request.
 Lambda → DynamoDB / S3: Lambda reads/writes data in DynamoDB and may
store large objects in S3 as part of processing.
 DynamoDB ↔ SNS: DynamoDB can trigger SNS notifications (e.g., on item
changes) to inform downstream systems.
 Lambda / API Gateway → CloudWatch: Both services publish logs/metrics to
CloudWatch for monitoring.
 Optional: CloudWatch events/alarms can trigger actions or notifications.

Key benefits of this architecture

 No server management: You don’t provision or manage servers; the platform

handles scaling.
 Cost efficiency: Pay only for usage; Lambda scales automatically with demand.
 Resilience and scalability: Services are managed by AWS, designed for high
availability and fault tolerance.
 Observability: CloudWatch provides visibility into performance and issues; SNS
enables decoupled notifications.

Common patterns you might see

 Event-driven: DynamoDB streams or API Gateway triggers Lambda.

 Data storage: DynamoDB for structured data; S3 for large objects.
 Notification/alerting: SNS for fan-out messaging and alerts.
 Monitoring: CloudWatch for logs, metrics, dashboards, and alarms.

If you want, tell me which part you’d like a deeper dive into (e.g., API Gateway setup,
Lambda event handling, DynamoDB data model, or CloudWatch logging).