Module Navigation

Previous: Containers | Parent: Serverless Learning Path | Next: AWS Lambda QA

---

Introduction

Serverless Computing is a cloud execution model in which developers build and run applications without directly provisioning, managing, or maintaining servers.

The term serverless does not mean that servers do not exist. Servers are still used behind the scenes, but the cloud provider manages infrastructure provisioning, operating-system maintenance, runtime management, scaling, availability, and much of the operational work.

Developers mainly focus on:

• Writing business logic
• Configuring event triggers
• Defining permissions
• Monitoring execution
• Managing application data
• Optimizing performance and cost

Serverless platforms are commonly used for APIs, data processing, scheduled jobs, event-driven workflows, file processing, notifications, automation, and lightweight microservices.

What Is Serverless Computing?

Serverless Computing is a cloud model where application code runs on demand in fully managed execution environments.

A function is typically invoked by an event such as:

• HTTP request
• File upload
• Database change
• Queue message
• Scheduled event
• Authentication event
• Monitoring alert
• Event-bus notification

The cloud provider automatically creates execution environments, runs the code, scales capacity, and releases resources when execution is complete.

---

Basic Serverless Architecture

flowchart LR
    Client[Client Application] --> Gateway[API Gateway]
    Gateway --> Function[Serverless Function]
    Function --> Database[(Managed Database)]
    Function --> Storage[(Object Storage)]
    Function --> Queue[Message Queue]
    Function --> Notification[Notification Service]

---

How Serverless Works

A typical serverless execution flow follows these steps:

1. An event occurs.
2. A cloud service receives the event.
3. The event triggers a serverless function.
4. The platform allocates or reuses an execution environment.
5. The function processes the request.
6. The function communicates with managed services when required.
7. The result is returned or forwarded.
8. Logs, metrics, and traces are collected.
9. The platform scales execution instances based on demand.

---

Serverless Request Flow

sequenceDiagram
    participant User
    participant API as API Gateway
    participant Function as Serverless Function
    participant DB as Database
    User->>API: Send HTTP request
    API->>Function: Invoke function
    Function->>DB: Read or update data
    DB-->>Function: Return result
    Function-->>API: Return response
    API-->>User: Send HTTP response

---

Main Characteristics of Serverless

Characteristic	Description
No server management	Cloud provider manages the infrastructure
Event-driven	Functions execute when events occur
Automatic scaling	Capacity increases or decreases automatically
Pay per use	Billing is based primarily on execution and resources consumed
Short-lived execution	Functions are designed to complete defined units of work
Stateless design	Persistent state should be stored outside the function
Managed runtime	Provider manages operating systems and language runtimes
High availability	Platform distributes execution across managed infrastructure
Integrated services	Functions connect easily with queues, databases, storage, and events

---

Serverless Service Models

Serverless architectures commonly use two major models:

Function as a Service

Function as a Service, or FaaS, allows developers to deploy individual functions that execute in response to events.

Examples:

• AWS Lambda
• Azure Functions
• Google Cloud Functions

A FaaS function typically contains a small unit of business logic.

flowchart LR
    Event[Incoming Event] --> Function[Function as a Service]
    Function --> Result[Processed Result]

Backend as a Service

Backend as a Service, or BaaS, provides managed backend capabilities that applications can consume without building and operating the underlying infrastructure.

Examples include:

• Managed authentication
• Managed databases
• Object storage
• Push notifications
• Message queues
• API management
• Managed event buses

A complete serverless application usually combines FaaS and BaaS services.

---

FaaS vs BaaS

FaaS	BaaS
Executes custom business logic	Provides managed backend functionality
Triggered by events	Accessed through APIs or SDKs
Developers write functions	Developers configure and consume services
Examples include Lambda and Azure Functions	Examples include managed authentication and databases
Used for processing	Used for reusable platform capabilities

---

Serverless vs Traditional Servers

Traditional Server Model	Serverless Model
Infrastructure is provisioned manually	Infrastructure is provisioned automatically
Capacity planning is required	Capacity scales automatically
Servers may run continuously	Functions execute only when triggered
Operations teams patch operating systems	Provider maintains the execution environment
Billing is based on allocated capacity	Billing is based mainly on usage
Applications may be long-running	Functions are usually short-lived
Scaling rules must be configured	Scaling is largely platform-managed

---

Serverless vs Containers

Serverless Functions	Containers
Infrastructure is highly abstracted	More control over the runtime environment
Usually event-driven	Can run continuously
Automatic scaling is built in	Scaling is managed through an orchestration platform
Execution-duration limits may apply	Suitable for long-running workloads
Limited runtime customization	Supports custom runtimes and dependencies
Pay mainly for execution	Pay for allocated compute resources
Best for focused units of work	Best for complex and portable services

Serverless and containers are not direct competitors in every situation. Many production systems use both.

For example:

• Serverless functions process asynchronous events.
• Containers run long-lived business services.
• Managed queues connect the two platforms.

---

Event-Driven Serverless Architecture

Serverless applications are commonly designed around events.

flowchart LR
    Producer[Event Producer] --> EventBus[Event Bus]
    EventBus --> FunctionA[Validation Function]
    EventBus --> FunctionB[Notification Function]
    EventBus --> FunctionC[Audit Function]
    FunctionA --> Database[(Database)]
    FunctionB --> Email[Email Service]
    FunctionC --> Logs[(Audit Logs)]

Event-driven architecture allows services to remain loosely coupled.

The event producer does not need to know how every consumer processes the event.

---

Common Serverless Event Sources

Event Source	Example
HTTP API	REST request invokes a function
Object storage	File upload triggers image processing
Message queue	Queue message triggers order processing
Event bus	Business event triggers multiple consumers
Database stream	Data change triggers downstream processing
Scheduler	Function runs every hour or day
Authentication	User registration triggers onboarding
Monitoring	Security alert triggers automated remediation

---

Serverless Execution Lifecycle

flowchart LR
    Event[Event Received] --> Allocate[Allocate or Reuse Environment]
    Allocate --> Initialize[Initialize Runtime]
    Initialize --> Execute[Execute Function]
    Execute --> Return[Return Result]
    Return --> Retain[Temporarily Retain Environment]
    Retain --> Reuse[Reuse for Future Invocation]

The provider may reuse an existing execution environment for later requests. When no reusable environment exists, a new environment must be initialized.

---

Cold Start and Warm Start

Cold Start

A cold start occurs when the serverless platform must create and initialize a new execution environment before running the function.

Cold-start activities may include:

• Starting the runtime
• Loading application code
• Loading dependencies
• Initializing frameworks
• Establishing connections
• Running initialization logic

Cold starts can increase response latency.

Warm Start

A warm start occurs when the platform reuses an already initialized execution environment.

Warm invocations are generally faster because runtime initialization has already completed.

flowchart TD
    Request[Incoming Request] --> Environment{Warm Environment Available?}
    Environment -->|Yes| Execute[Execute Immediately]
    Environment -->|No| Initialize[Create and Initialize Environment]
    Initialize --> Execute
    Execute --> Response[Return Response]

---

Stateless Functions

Serverless functions should normally be designed as stateless components.

This means a function should not depend on local memory or local disk data remaining available between invocations.

Persistent state should be stored in external services such as:

• Managed databases
• Distributed caches
• Object storage
• Message queues
• Workflow engines

Local execution storage may be temporary and can disappear when the execution environment is removed.

---

Automatic Scaling

Serverless platforms automatically scale by creating additional function instances when the number of incoming events increases.

flowchart LR
    Requests[Incoming Requests] --> Platform[Serverless Platform]
    Platform --> F1[Function Instance 1]
    Platform --> F2[Function Instance 2]
    Platform --> F3[Function Instance 3]
    Platform --> FN[Function Instance N]

Each concurrent request or event may require a separate execution environment.

This makes concurrency management important because downstream systems such as databases may not scale at the same rate.

---

Scale-to-Zero

Some serverless services can reduce active execution capacity to zero when there are no incoming requests.

Benefits include:

• Reduced idle cost
• Efficient resource usage
• Simplified capacity management

However, scale-to-zero can increase the likelihood of cold-start latency.

---

Serverless Pricing Model

Serverless pricing commonly depends on:

• Number of invocations
• Execution duration
• Allocated memory
• CPU consumption
• Network transfer
• API requests
• Logs and monitoring
• Connected managed services

Serverless can be cost-effective for variable or intermittent workloads.

It may become expensive when:

• Functions execute continuously
• Workloads have long execution times
• Memory allocation is inefficient
• Logging volume is excessive
• Architecture invokes many services for one transaction

---

Common Serverless Use Cases

REST APIs

API Gateway invokes functions that validate requests, apply business logic, and access databases.

File Processing

Object-storage uploads trigger functions for:

• Image resizing
• Virus scanning
• Document conversion
• Metadata extraction

Data Processing

Functions transform records from event streams, queues, or databases.

Scheduled Jobs

Functions run on schedules for:

• Report generation
• Data cleanup
• Notification delivery
• Backup validation

Notifications

Business events trigger email, SMS, or push notifications.

Automation

Functions automate infrastructure remediation, account provisioning, and operational workflows.

Internet of Things

Device events trigger validation, transformation, storage, and alerting.

---

Production Use Case: Image Processing

Consider an application where users upload profile images.

flowchart LR
    User[User] --> Storage[Object Storage]
    Storage --> Event[Upload Event]
    Event --> Function[Image Processing Function]
    Function --> Validate[Validate File]
    Validate --> Resize[Resize Image]
    Resize --> ProcessedStorage[Processed Image Storage]
    Function --> Metadata[(Metadata Database)]
    Function --> Notification[Notification Service]
    Function --> Monitoring[Logs and Metrics]

Processing Flow

1. The user uploads an image.
2. Object storage publishes an event.
3. A serverless function receives the event.
4. The function validates the file type and size.
5. The function resizes and optimizes the image.
6. The processed file is stored separately.
7. Metadata is saved in a database.
8. A notification confirms completion.
9. Failures are sent to a dead-letter queue.
10. Logs and metrics are captured for monitoring.

---

Interview Questions and Answers

1. What is Serverless Computing?

Answer

Serverless Computing is a cloud execution model where developers deploy application logic without directly managing servers.

The cloud provider manages:

• Infrastructure provisioning
• Runtime environments
• Operating-system maintenance
• Scaling
• Availability
• Resource allocation

Developers remain responsible for application code, security permissions, data handling, monitoring, and configuration.

---

2. Does serverless mean there are no servers?

Answer

No. Serverless applications still execute on physical or virtual servers.

The word serverless means that server management is abstracted from the application team.

The cloud provider manages the underlying infrastructure, while developers focus primarily on code and business logic.

---

3. How does Serverless Computing work internally?

Answer

A typical internal flow is:

1. An event is received.
2. The platform checks whether a reusable execution environment exists.
3. If necessary, the platform creates a new environment.
4. The runtime and function code are initialized.
5. The function processes the event.
6. The result is returned or passed to another service.
7. Logs and metrics are collected.
8. The environment may be retained temporarily for reuse.

The platform creates more instances when concurrency increases.

---

4. What is Function as a Service?

Answer

Function as a Service is a serverless model in which developers deploy small units of code that execute in response to events.

Examples include:

• AWS Lambda
• Azure Functions
• Google Cloud Functions

A FaaS function should generally perform a focused responsibility, remain stateless, and complete within the platform's execution limits.

---

5. What is the difference between FaaS and BaaS?

Answer

FaaS executes custom application logic, while BaaS provides managed backend capabilities.

For example:

• A Lambda function validating an order is FaaS.
• A managed authentication service is BaaS.
• A managed database is BaaS.
• A managed notification service is BaaS.

Most serverless systems combine both models.

---

6. What are the advantages of Serverless Computing?

Answer

Major advantages include:

• No direct server administration
• Automatic scaling
• Faster application development
• Reduced idle infrastructure cost
• High integration with cloud services
• Built-in availability
• Event-driven processing
• Easier deployment of focused functions

Serverless is especially useful for unpredictable or bursty workloads.

---

7. What are the limitations of Serverless Computing?

Answer

Common limitations include:

• Cold-start latency
• Execution-duration limits
• Runtime restrictions
• Vendor dependency
• Difficult local testing
• Distributed debugging complexity
• Concurrency limits
• Limited control over infrastructure
• Potentially high cost for continuous workloads
• Downstream database connection pressure

These limitations should be evaluated during architecture design.

---

8. What is a cold start?

Answer

A cold start occurs when the platform creates and initializes a new execution environment before processing a request.

Cold-start latency may increase because the platform must load:

• Runtime
• Application code
• Dependencies
• Frameworks
• Initialization logic

Cold starts can be reduced by minimizing package size, reducing initialization work, reusing connections, choosing suitable runtimes, and using platform-specific prewarming capabilities when justified.

---

9. How does auto-scaling work in serverless systems?

Answer

The platform automatically creates more execution environments as incoming request volume or event concurrency increases.

For example, if 100 events are processed concurrently, the platform may create multiple function instances to handle them.

However, automatic scaling must be controlled carefully because downstream resources such as relational databases, third-party APIs, or legacy systems may have lower capacity limits.

Concurrency controls, queues, backpressure, retries, and connection pooling help protect dependent systems.

---

10. When should Serverless Computing be used?

Answer

Serverless is a strong choice for:

• Event-driven processing
• APIs with variable traffic
• Scheduled jobs
• File processing
• Notifications
• Automation
• Stream processing
• Lightweight microservices
• Short-duration background tasks

It may not be ideal for long-running processes, highly customized runtime requirements, extremely latency-sensitive workloads, or applications with constant high utilization.

---

Serverless Production Architecture

flowchart TB
    Client[Web or Mobile Client] --> CDN[CDN]
    CDN --> Gateway[API Gateway]
    Gateway --> Auth[Authentication Service]
    Auth --> Function[Serverless Function]

    Function --> Database[(Managed Database)]
    Function --> Cache[(Distributed Cache)]
    Function --> Queue[Message Queue]
    Function --> Storage[(Object Storage)]
    Function --> EventBus[Event Bus]

    Queue --> Worker[Background Function]
    EventBus --> Notification[Notification Function]

    Function --> Logs[Centralized Logging]
    Worker --> Logs
    Logs --> Monitoring[Monitoring and Alerting]

    Queue --> DLQ[Dead-Letter Queue]

---

AWS, Azure, and Google Cloud Serverless Services

Capability	AWS	Azure	Google Cloud
Functions	AWS Lambda	Azure Functions	Google Cloud Functions
API Management	Amazon API Gateway	Azure API Management	API Gateway
Event Routing	Amazon EventBridge	Azure Event Grid	Eventarc
Messaging	Amazon SQS and SNS	Azure Service Bus	Pub/Sub
Workflow	AWS Step Functions	Durable Functions and Logic Apps	Workflows
Object Storage	Amazon S3	Azure Blob Storage	Cloud Storage
Monitoring	CloudWatch	Azure Monitor	Cloud Monitoring
Identity	IAM	Microsoft Entra ID and Managed Identities	Cloud IAM

---

Common Interview Follow-Up Questions

• What is the difference between serverless and Platform as a Service?
• How do serverless functions handle concurrency?
• What causes cold starts?
• How do you manage database connections in Lambda?
• What is a dead-letter queue?
• How do retries work in event-driven systems?
• How do you secure a serverless API?
• How do you monitor distributed serverless applications?
• What is function orchestration?
• How do you avoid vendor lock-in?

---

Common Mistakes

Storing State Locally

Function instances may be destroyed at any time. Persistent state should be stored externally.

Creating Database Connections Per Request

Opening a new connection for every invocation can exhaust database capacity.

Ignoring Retry Behavior

Automatic retries can cause duplicate processing unless the function is idempotent.

Assigning Excessive Permissions

Functions should receive only the minimum permissions required.

Deploying Large Packages

Large dependencies increase deployment size and cold-start latency.

Ignoring Concurrency Limits

Uncontrolled scaling can overload databases and external APIs.

Logging Sensitive Information

Passwords, tokens, personal data, and payment details should never be written to logs.

Using Functions for Long-Running Jobs

Long-running workflows should use containers, batch services, or workflow orchestration when function limits are unsuitable.

Missing Failure Destinations

Failed asynchronous events should be captured in dead-letter queues or failure destinations.

Ignoring Cost Across Services

The total cost includes functions, API gateways, databases, logs, queues, storage, and network transfer.

---

Serverless Best Practices

• Design small and focused functions.
• Keep functions stateless.
• Store persistent state in managed services.
• Apply least-privilege permissions.
• Encrypt data at rest and in transit.
• Store credentials in a secrets-management service.
• Make event handlers idempotent.
• Configure bounded retries.
• Use dead-letter queues for failed events.
• Reuse SDK clients and database connections when safe.
• Minimize deployment-package size.
• Control concurrency to protect downstream services.
• Use queues to absorb traffic spikes.
• Add correlation IDs for distributed tracing.
• Monitor errors, duration, throttling, and concurrency.
• Test failure scenarios and recovery processes.
• Evaluate total architecture cost instead of function cost alone.

---

Idempotency in Serverless Systems

An idempotent function produces the same intended result when the same event is processed multiple times.

This is important because distributed systems may deliver the same event more than once.

flowchart LR
    Event[Event with Unique ID] --> Function[Serverless Function]
    Function --> Check{Already Processed?}
    Check -->|Yes| Ignore[Return Existing Result]
    Check -->|No| Process[Process Event]
    Process --> Store[Save Result and Event ID]

Common techniques include:

• Unique event identifiers
• Database uniqueness constraints
• Idempotency tables
• Conditional writes
• Request tokens

---

Error Handling Strategy

flowchart TD
    Event[Incoming Event] --> Function[Function Execution]
    Function --> Result{Successful?}
    Result -->|Yes| Complete[Complete Processing]
    Result -->|No| Retry[Retry with Backoff]
    Retry --> Limit{Retry Limit Reached?}
    Limit -->|No| Function
    Limit -->|Yes| DLQ[Dead-Letter Queue]
    DLQ --> Alert[Alert Operations Team]
    DLQ --> Replay[Review and Replay]

Production serverless systems should include:

• Retry policies
• Exponential backoff
• Maximum retry limits
• Dead-letter queues
• Failure alerts
• Replay procedures
• Idempotent handlers

---

Security Considerations

Serverless removes infrastructure-management responsibilities, but it does not remove application-security responsibilities.

Important controls include:

• Least-privilege IAM roles
• Strong API authentication
• Input validation
• Secure secret storage
• Encryption
• Dependency scanning
• Network restrictions
• Audit logging
• Rate limiting
• Web Application Firewall protection

Each function should have a dedicated identity where practical instead of sharing broad permissions.

---

Observability Considerations

Serverless applications are distributed across many managed services.

Effective observability requires:

• Centralized logs
• Metrics
• Distributed traces
• Correlation IDs
• Error alerts
• Concurrency monitoring
• Throttling monitoring
• Queue-depth monitoring
• Dead-letter queue alerts

Important function metrics include:

Metric	Purpose
Invocation count	Measures workload volume
Error rate	Identifies failures
Duration	Measures performance
Cold-start duration	Identifies initialization overhead
Throttles	Shows rejected or delayed executions
Concurrent executions	Tracks scaling behavior
Retry count	Detects processing instability
Queue age	Identifies processing delays

---

Quick Revision

Topic	Key Point
Serverless	Run applications without directly managing servers
FaaS	Execute custom functions in response to events
BaaS	Consume managed backend services
Trigger	Event that invokes a function
Cold Start	New execution environment initialization
Warm Start	Reuse of an existing environment
Stateless	Persistent state is stored externally
Auto-Scaling	Platform adds execution capacity automatically
Idempotency	Safe processing of repeated events
Dead-Letter Queue	Stores events that could not be processed
Concurrency	Number of function executions occurring simultaneously
Pay Per Use	Cost based mainly on consumed resources

---

Key Takeaways

• Serverless Computing allows developers to run application logic without directly managing infrastructure.
• Servers still exist, but the cloud provider handles provisioning, runtime management, availability, and scaling.
• Serverless architectures usually combine FaaS with managed BaaS services.
• Functions are commonly event-driven, stateless, short-lived, and automatically scaled.
• Cold starts, retries, duplicate events, concurrency, cost, and observability must be considered in production.
• Serverless is well suited for APIs, event processing, file processing, scheduled jobs, automation, and variable workloads.
• Long-running, constantly utilized, highly customized, or extremely latency-sensitive workloads may be better suited to containers or dedicated compute.
• Secure permissions, idempotency, failure handling, monitoring, and downstream protection are essential for reliable serverless applications.

---