What is Serverless? FaaS, Cold Start, and When to Go Serverless

Serverless is a cloud computing model that lets you deploy and run code without worrying about servers — the cloud automatically allocates resources, scales on demand, and bills only for actual usage. This article explains what Serverless is, the difference between FaaS and BaaS, how cold starts work, the function execution lifecycle, and when you should (or shouldn't) choose a serverless architecture.

What is Serverless?

Serverless is a cloud computing execution model where developers only write and deploy code — typically individual functions — while the cloud provider (AWS, GCP, Azure) fully handles server provisioning, operations, and scaling.

The name "serverless" can be misleading: servers still exist, but you don't manage them. You don't worry about OS patching, load balancer configuration, disk monitoring, or capacity planning. All of that is abstracted away from the developer.

Two properties define serverless:

• No server management: The cloud automatically provisions, scales, and reclaims compute resources.
• Pay-per-invocation: You pay for each function invocation and actual CPU time consumed, not for idle server capacity.

Serverless encompasses two main branches: FaaS (Function as a Service) and BaaS (Backend as a Service). The next section explains the distinction clearly.

FaaS vs BaaS

Although both fall under the serverless umbrella, FaaS and BaaS serve different purposes:

FaaS — Function as a Service is a model where you write individual functions, deploy them to the cloud, and they're invoked by events (HTTP requests, queue messages, cron schedules, and so on). Once the function completes, the cloud immediately reclaims the resources. Key examples:

• AWS Lambda — the most widely adopted FaaS platform, supporting Python, Node.js, Go, Java, Ruby, and more.
• Google Cloud Functions — deeply integrated with Firebase and the GCP ecosystem.
• Azure Functions — strong integration with Microsoft services (Event Hub, Service Bus).
• Vercel Edge Functions — optimized for Next.js and frontend use cases, running at edge nodes closest to the user.

BaaS — Backend as a Service provides pre-built backend services that you call directly from the frontend without writing server code. Key examples:

• Firebase (Google) — realtime database, auth, file storage, and push notifications.
• Supabase — PostgreSQL with realtime subscriptions, auth, and storage; open source.
• AWS Amplify — integrates auth (Cognito), GraphQL (AppSync), and storage (S3) for frontend apps.

The core distinction: FaaS lets you run custom business logic server-side; BaaS provides pre-built infrastructure for common needs. In practice, many projects combine both — using Firebase Auth (BaaS) alongside AWS Lambda (FaaS) in the same application.

What is an API Gateway? The Front Door of Microservice Architecture

Cold Start vs Warm Start

Cold start latency is one of the most practical challenges when adopting serverless.

Warm start occurs when a function was invoked recently and its container is still alive in the cloud's memory. The next invocation is served immediately — latency is only your handler execution time, typically under 10ms for simple business logic.

Cold start occurs when:

• The function is invoked for the first time after a deploy.
• The function has been idle long enough that the cloud reclaimed its container.
• A traffic spike exceeds the number of currently warm instances.

During a cold start, the cloud must complete the full initialization chain:

1. Provision container — create a new isolated execution environment.
2. Load runtime — start the interpreter, JVM, or language runtime.
3. Fetch deployment package — download and decompress your code.
4. Init module — run module-level initialization code (imports, DB connections, config parsing).
5. Execute handler — finally run your actual function.

Typical cold start durations by runtime:

Strategies to reduce cold starts:

• Provisioned Concurrency (AWS Lambda): Keeps a set number of instances warm, completely eliminating cold starts — at an additional cost.
• Reduce package size: Remove unused dependencies, apply tree-shaking.
• Avoid heavy initialization: Don't open database connections in module scope; use lazy initialization.
• Choose lightweight runtimes: Go and Node.js have significantly shorter cold starts than Java/Spring.
• Scheduled warm-up: Use a CloudWatch cron to ping your function every 5 minutes to keep it warm.

Execution Lifecycle: from Trigger to Terminate

Every time a serverless function is invoked, it passes through a fixed four-phase lifecycle:

1. Trigger An external event fires the function — an HTTP request through API Gateway, a message from SQS or Kafka, a file upload to S3, or a scheduled cron event. The cloud receives the event and decides which instance to dispatch it to (warm or cold start).

2. Init This phase only occurs on a cold start. The cloud creates the execution environment, loads the runtime, and runs all module-level code (outside the handler function). Database connections, config parsing, and heavy imports should live here so they're reused across warm invocations.

3. Execute Your handler function is called with the event object and the context object. This is the code you write; it returns a result. With AWS Lambda, this is lambda_handler(event, context).

4. Terminate After the handler returns, the cloud "freezes" the execution environment — the container isn't immediately destroyed, but is held for potential warm reuse. After a period of idleness (typically 15–45 minutes for Lambda), the cloud truly reclaims the container.

Code Examples

AWS Lambda (Python)

 1import json
 2import boto3
 3
 4# Init phase: runs once and is reused across warm invocations
 5s3_client = boto3.client('s3')
 6
 7def lambda_handler(event, context):
 8    """
 9    Main Lambda handler.
10    event: dict containing trigger data (HTTP request, SQS message, etc.)
11    context: object with execution metadata (request_id, remaining timeout, etc.)
12    """
13    # Read HTTP method and path from API Gateway proxy event
14    http_method = event.get('httpMethod', 'GET')
15    path = event.get('path', '/')
16
17    # Business logic
18    if http_method == 'GET' and path == '/hello':
19        body = {
20            'message': 'Hello from AWS Lambda!',
21            'requestId': context.aws_request_id,
22        }
23        status_code = 200
24    else:
25        body = {'error': 'Not Found'}
26        status_code = 404
27
28    # Return HTTP response in API Gateway proxy integration format
29    return {
30        'statusCode': status_code,
31        'headers': {
32            'Content-Type': 'application/json',
33            'Access-Control-Allow-Origin': '*',
34        },
35        'body': json.dumps(body),
36    }

Vercel Edge Function (JavaScript)

 1// api/hello.js — Vercel Edge Runtime
 2// Runs at the edge node closest to the user for lower latency than standard Lambda
 3
 4export const config = {
 5  runtime: 'edge',
 6};
 7
 8export default async function handler(request) {
 9  const { searchParams } = new URL(request.url);
10  const name = searchParams.get('name') || 'World';
11
12  // Edge functions use Web standard Request and Response objects
13  return new Response(
14    JSON.stringify({
15      message: `Hello, ${name}! Powered by Vercel Edge.`,
16      region: process.env.VERCEL_REGION || 'unknown',
17    }),
18    {
19      status: 200,
20      headers: {
21        'Content-Type': 'application/json',
22        'Cache-Control': 's-maxage=60, stale-while-revalidate',
23      },
24    }
25  );
26}

Event Triggers

Serverless functions can be invoked by a variety of event sources:

HTTP / API Gateway The most common trigger — API Gateway receives an HTTP request and forwards it to Lambda as a normalized event object. Ideal for REST APIs, webhook endpoints, and backend-for-frontend patterns.

Queue Message (SQS / Kafka / Pub/Sub) Functions are triggered when new messages arrive in a queue. Lambda polls SQS in batches and processes messages in parallel. Ideal for async task processing and event-driven architectures.

What is Kafka? Message Queue for Distributed Systems

Schedule (Cron Job) AWS EventBridge Scheduler triggers Lambda on a cron schedule — for example, generating a revenue report at midnight or running cleanup jobs every Sunday. A complete replacement for traditional server crontabs.

Storage Event (S3 / Cloud Storage) Functions automatically trigger when files are uploaded to an S3 bucket. Widely used for image processing pipelines — user uploads a photo → S3 triggers Lambda → Lambda resizes to multiple dimensions → saves to a CDN bucket.

Database Stream (DynamoDB Streams / Firestore) Every database change (insert/update/delete) generates an event that triggers a function. Used for syncing data to Elasticsearch, sending notifications, or invalidating caches.

Serverless vs Container vs VM

When designing a system, here is a practical comparison matrix to help choose the right compute model:

What is Kubernetes? Container Orchestration for Production

When to choose Serverless:

• Intermittent, bursty, or unpredictable traffic patterns.
• High development velocity with minimal infrastructure operations.
• Event-driven tasks: image processing, webhooks, ETL pipelines, scheduled jobs.
• MVPs or small microservices with a tight budget.

When NOT to choose Serverless:

• Functions that need to run continuously beyond 15 minutes.
• Applications that require in-memory state between requests.
• Continuously high traffic where costs escalate.
• Fine-grained runtime, networking, or GPU control required.
• Sub-millisecond latency that cannot tolerate cold start delays.

Real-World Use Cases

1. Image Resize Pipeline User uploads a photo → S3 triggers Lambda → Lambda uses Pillow/Sharp to resize into 3 dimensions (150px thumbnail, 600px medium, 1200px large) → saves to an S3 CDN bucket. Near-zero cost when no uploads are happening; auto-scales when traffic spikes.

2. Webhook Handler Stripe sends a payment webhook → API Gateway receives it → Lambda verifies the signature, updates the order status in the database, and sends a confirmation email. Serverless is ideal because webhooks are sporadic — you pay exactly for what you use.

3. Scheduled Report Job EventBridge Scheduler triggers Lambda every morning at 6 AM → Lambda queries BigQuery/Redshift, aggregates the previous day's revenue report → sends a Slack notification to the team channel. No server running 24/7 just to perform a 2-minute task once a day.

What is an API Gateway? The Front Door of Microservice Architecture

What is Kafka? Message Queue for Distributed Systems

What is Kubernetes? Container Orchestration for Production