FaaS/Serverless #

Serverless Computing and Function as a Service (FaaS) represent one of the most revolutionary paradigm leaps in cloud architecture history. The term “serverless” is often misunderstood by beginners as “running programs without physical servers.” In reality, physical servers still exist and run in the cloud provider’s data centers; it’s just that all server management responsibilities — from hardware provisioning, OS installation, OS security updates, traffic load balancing, to server capacity scaling — are fully abstracted and managed by the cloud provider. As developers, we only need to focus on one thing: writing our business function code, uploading it to the cloud, and deciding which event will trigger that code’s execution. This model promises extreme operational cost efficiency and instant scalability, but demands a total mindset shift in how we design and write programs.

How Serverless Works and Its Paradigm #

In the traditional computing era (on-premise and IaaS), servers were like “pets”. Each server had a unique name, its OS was maintained regularly, and it had to stay on 24/7 waiting for traffic requests. We paid the server rental fee even when the server sat idle with no users accessing it at night.

In the Serverless era, servers become like “cattle” — unnamed, ephemeral, and only alive when needed. Our function code is only activated into a micro execution container when an event trigger occurs. After the function finishes its task and returns a response to the user, that execution container is frozen or immediately destroyed by the platform.

  Dedicated Server Model (VM / IaaS):
    Server On 24/7 -> Waiting for Requests -> Processing Data -> Waiting Again -> Paying Continuously
    * We pay for server uptime, not for the number of processed requests.

  Serverless Model (FaaS):
    Service Idle (0 Instances) -> Event Occurs -> Instance Activates Instantly -> Code Executes -> Instance Dies -> Pay $0 While Idle
    * We only pay per millisecond while our code is actually processing data.

This paradigm shift makes FaaS a highly cost-efficient model for applications with highly fluctuating traffic patterns or lots of idle gaps.

Anatomy and Structure of a Serverless Function #

A FaaS function is designed for a single specific purpose and is stateless. At the code-writing level, a FaaS function generally has three main structural components:

1. Trigger (Event Source): The external event that fires the function.
2. Handler Function (Entry Point): The main function in our code that receives event data, processes business logic, and interacts with the database.
3. Context Object: The metadata object provided by the cloud runtime, giving information about the execution environment (like remaining function timeout, unique request ID, and logging configuration).

FaaS Code Writing Optimization Example #

When writing FaaS code, one of the most fatal mistakes is initializing database connections or loading global configuration inside the handler function. This slows down every new incoming request.

Here’s a comparison of FaaS function code patterns (using AWS Lambda in Node.js) between the anti-pattern and the correct pattern for optimizing warm start reuse:

// ✗ ANTI-PATTERN: Initializing the DB connection inside the Handler
// The database connection is created from scratch on EVERY request, slowing response latency.
exports.handler = async (event, context) => {
  const mysql = require('mysql2/promise');
  // Connection created inside the handler
  const connection = await mysql.createConnection({host: process.env.DB_HOST, database: 'db'});
  
  const [rows] = await connection.execute('SELECT * FROM users WHERE id = ?', [event.pathParameters.id]);
  await connection.end(); // Force-closing the connection
  
  return { statusCode: 200, body: JSON.stringify(rows) };
};

// ✓ CORRECT: Declare the database connection outside the Handler (Global Scope)
// The connection is created only ONCE on Cold Start, and reused on subsequent Warm Starts.
const mysql = require('mysql2/promise');
// Connection pool initialized outside the handler (Global Scope)
const pool = mysql.createPool({
  host: process.env.DB_HOST,
  database: 'db',
  connectionLimit: 1 // Limit connections because FaaS scales horizontally massively
});

exports.handler = async (event, context) => {
  // Reuse the connection pool already in container memory
  const [rows] = await pool.execute('SELECT * FROM users WHERE id = ?', [event.pathParameters.id]);
  
  return {
    statusCode: 200,
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(rows)
  };
};

The Trigger Ecosystem: The Heart of Event-Driven Architecture #

Serverless functions can’t fire on their own without a trigger. In cloud environments, FaaS platforms are deeply integrated with various event sources (triggers). We can categorize these triggers into several interaction models:

flowchart TD
    subgraph EventSources["Event Sources (Triggers)"]
        API["API Gateway<br>(HTTP Sync)"]
        S3["Object Storage<br>(File Upload Async)"]
        SQS["Message Queue<br>(Message Polling)"]
        Cron["EventBridge Scheduler<br>(Time-based)"]
    end
    
    subgraph FaaS["FaaS Platform (Managed Container)"]
        Init["Execution Env Initialization"] --> Handler["Handler Function Execution"]
    end
    
    API -->|"Trigger"| Init
    S3 -->|"Trigger"| Init
    SQS -->|"Trigger"| Init
    Cron -->|"Trigger"| Init
    
    Handler -->|"Return Response"| API
    Handler -->|"Write to DB"| DB[(Managed Database)]

Trigger Model Classification: #

• Synchronous (Request-Response): The client calls the function through an API Gateway and keeps the connection open until the function finishes processing data and returns an HTTP response. Example: Creating an API endpoint for a mobile app login.
• Asynchronous (Event-Driven): The trigger sends an event to the cloud’s internal queue, then immediately replies success to the client without waiting for the function to finish. The cloud platform then calls the function in the background. Example: A user uploads an image to Object Storage (S3), which automatically triggers a thumbnail-generating function.
• Polling (Stream-Based): The FaaS platform constantly monitors a message queue or data stream, then triggers our function by wrapping several messages at once (batching). Example: Processing IoT sensor log data from Kinesis or Kafka streams.

The Cold Start Phenomenon and Mitigation Strategies #

The biggest technical challenge in FaaS architecture is the initial execution latency known as Cold Start.

When a function is called after being idle for a while, the cloud platform has no execution container ready in memory. The platform must go through the following stages from scratch:

1. Allocate Virtual Machine resources and create a new micro container.
2. Download our function package code from internal storage.
3. Initialize the programming language runtime (for example, starting the Node.js V8 engine or Java JVM).
4. Run global initialization code (creating database connections, loading libraries).

This Cold Start process can add 200 milliseconds to 5 seconds of extra latency, depending on the programming language and the size of our application’s zip package. Subsequent requests arriving while the container is still active are processed instantly (Warm Start) with no extra latency.

How to Minimize Cold Start: #

• Choose a Lightweight Runtime: Programming languages compiled directly to binaries (like Go or Rust) or lightweight scripting languages (like Python or Node.js) have much faster cold starts (<300ms) than Java or .NET, which require heavy internal VM initialization (>2 seconds).
• Reduce Dependency Package Size: Use tree shaking or bundling techniques (like esbuild/webpack) to strip unused code libraries so the application zip file stays as small as possible.
• Use Provisioned Concurrency: A paid cloud feature that keeps a number of function containers always warm in memory, ready to accept instant traffic with no cold start at all.
• Increase Memory Allocation: In the cloud, increasing function memory (e.g., from 256MB to 2GB) linearly increases the virtual CPU allocation given to that container. Faster CPUs speed up initial runtime booting.

FaaS Technical Limits You Must Understand #

Serverless isn’t a silver bullet that solves every architectural problem. There are strict limits we must consider before deciding to migrate to FaaS:

1. Execution Timeout: FaaS functions have a maximum runtime limit (usually 15 minutes in AWS Lambda). If our code processes tasks that take hours (like video rendering or mass data migration), the system force-terminates the function midway.
2. No Local State (Stateless): We can’t store temporary files on serverless local drives for later requests, because execution containers can be destroyed at any time. All application state must be stored in external storage like SQL/NoSQL databases or Redis caches.
3. Database Connection Exhaustion: Because FaaS scales horizontally instantly by creating hundreds of standalone containers when traffic spikes, each container opens a new connection to the relational database. This can easily cripple databases (PostgreSQL/MySQL) by exhausting connection quotas (max connections exceeded). We must place a database proxy in the system to manage connection pooling.

Economic Analysis: Serverless vs VM Cost Calculation #

One of FaaS’s main selling points is its pay-as-you-go billing model with precision down to the millisecond. Let’s compare the cost of renting a dedicated IaaS VM versus using FaaS:

Webhook API Application Scenario: #

• Traffic: The application receives 150,000 requests per day.
• Execution Duration: Each request is processed in 300 milliseconds.
• Function Memory: Configured at 512 MB RAM.

Option A: Renting a Dedicated VM (IaaS) #

To guarantee the application is always online with sufficient capacity, we rent 1 small VM instance constantly 24 hours a day.

• VM hourly rental cost: $0.02
• Total monthly rental: $0.02 \times 24 \text{ hours} \times 30 \text{ days} = \mathbf{$14.40}$

Plus operational overhead costs (engineer salary for monitoring the OS, monthly security patching).

Option B: Using FaaS (Serverless) #

The FaaS platform bills based on the formula: $\text{Number of Requests} \times \text{Compute Duration (GB-Seconds)}$.

$$\text{Total Requests per Month} = 150,000 \times 30 = 4,500,000 \text{ requests}$$ $$\text{RAM Capacity in GB} = \frac{512 \text{ MB}}{1,024 \text{ MB}} = 0.5 \text{ GB}$$ $$\text{Total GB-Seconds per Month} = 4,500,000 \text{ requests} \times 0.3 \text{ seconds} \times 0.5 \text{ GB} = 675,000 \text{ GB-seconds}$$

• Standard request cost rate: $0.20 per 1 million requests
• Standard GB-Second compute rate: $0.0000166667 per GB-second

$$\text{Request Cost} = 4.5 \text{ million} \times $0.20 = $0.90$$ $$\text{Compute Cost} = 675,000 \text{ GB-seconds} \times $0.0000166667 = $11.25$$ $$\text{Total Monthly FaaS Cost} = $0.90 + $11.25 = \mathbf{$12.15}$$

Analysis: For medium traffic with lots of idle time, FaaS is cheaper ($12.15) than a VM ($14.40) with zero server maintenance overhead. However, if traffic constantly spikes to 50 million requests per day, FaaS costs skyrocket past a dedicated VM cluster. FaaS is most economical for fluctuating traffic or workloads with idle periods.

Serverless Service Mapping Across Providers #

For cloud architects designing multi-cloud systems, here’s an equivalent terminology table for serverless services across major providers:

Summary #

• Serverless doesn’t mean no servers — it means fully handing over physical server management, OS patching, and scaling automation to the cloud provider.
• FaaS billing is purely pay-as-you-go based on request count and millisecond execution duration, eliminating idle costs when servers aren’t accessed.
• Cold Start is FaaS’s main latency challenge, occurring when a new instance is created from scratch. Choose lightweight runtimes (Go, Python, Node.js) and reduce dependency package size to minimize it.
• Write stateless FaaS code so execution containers can be dynamically created and destroyed without corrupting user data integrity.
• Use external connection pooling when integrating serverless functions with relational databases to avoid database connection exhaustion.
• Evaluate the serverless economic trade-off — FaaS is very cheap for fluctuating or medium traffic, but can become very expensive compared to dedicated VM clusters in constant, giant-scale traffic scenarios.

← Previous: IaaS   Next: PaaS →