AlgoDaily - What Is Serverless Computing?

Home > DevOps/SDLC Cheat Sheets > DevOps and SDLC > What Is Serverless Computing?

The One-Sentence Idea

Serverless computing is a cloud execution model where you deploy functions or small services without managing servers or capacity. The platform handles provisioning, scaling, and patching, and you pay per execution time and resources used instead of for idle servers.

Two Flavors: FaaS and BaaS

FaaS (Functions as a Service): you upload functions (handlers) that the platform runs on demand (e.g., HTTP request, queue message, file upload). Examples: AWS Lambda, Google Cloud Functions, Azure Functions, Cloudflare Workers, Vercel Functions.
BaaS (Backend as a Service): you consume managed backends (auth, storage, databases, messaging) via APIs without running them yourself.

Serverless architectures often mix FaaS glue code with BaaS building blocks.

Let's test your knowledge. Click the correct answer from the options.

Which statement best characterizes serverless pricing?

Click the option that best answers the question.

You rent a VM by the hour
You pay for provisioned capacity 24/7 regardless of use
You pay for execution time and resources used

Key Properties (What You Get)

Automatic scaling: from zero to thousands of concurrent executions.
No server management: OS/security patching, capacity planning handled by provider.
Event-driven: functions triggered by events (HTTP, queues, schedules, storage changes).
Granular billing: billed by ms and memory/CPU allocation (provider-dependent).

Important constraints: functions are typically stateless, have execution time limits, ephemeral filesystems, and may suffer cold starts.

Definitions You’ll See

Cold start: the extra latency when a platform initializes a new runtime for a function that isn’t warm yet (e.g., boot language runtime, load code).
Warm start: reusing an existing runtime/container so the handler starts faster.
Provisioned concurrency / min instances: configuration to keep a baseline of warm runtimes to reduce cold starts.
Stateless: each invocation should not rely on prior in-memory state; use external state (DB, cache, object storage).

A Tiny HTTP “Hello”

Using only Node.js, we spin up a tiny HTTP “Hello” response in the serverless style.

Pattern: export a handler(event, context); the platform gives you event/context and expects a response.

xxxxxxxxxx
 
// A minimal serverless-style handler and a local driver (no frameworks).
​
// "Handler" style function the platform would call:
async function handler(event, context) {
  // event: request data (path, query, body), context: metadata (request id, deadline)
  return {
    statusCode: 200,
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ message: "Hello, Serverless!", time: new Date().toISOString() })
  };
}
​
// Local driver to simulate a single invocation:
if (require.main === module) {
  const fakeEvent = { path: "/hello", queryStringParameters: { name: "Ana" } };
  const fakeContext = { requestId: "req-123", deadlineMs: Date.now() + 3000 };
  handler(fakeEvent, fakeContext).then(res => {
    console.log("RESPONSE:", res);
  });
}
​
module.exports = { handler };

Are you sure you're getting this? Is this statement true or false?

A serverless function should be stateless and must not rely on previous invocations’ in-memory variables.

Press true if you believe the statement is correct, or false otherwise.

Common Triggers (Events)

HTTP gateway → function (APIs, webhooks)
Object storage events (file upload) → process/resize
Queue/stream (e.g., message bus) → async jobs
Scheduler (cron) → periodic tasks
DB change streams → reactive workflows

Try this exercise. Could you figure out the right sequence for this list?

Put the steps of an HTTP-triggered function in order:

Press the below buttons in the order in which they should occur. Click on them again to un-select.

Options:

Platform parses HTTP → creates event
Your handler runs with event/context
Platform allocates/wakes runtime (cold or warm)
Platform serializes handler result → HTTP response

Image Thumbnail Worker Implementation

Let's take a look at a sample implementation. Simulate a storage-triggered function that reads a file, "processes" it, and writes an output (no external libs; pretend we resize by truncating bytes).

Takeaway: serverless is excellent for event-driven jobs like file processing.

xxxxxxxxxx
    print(handler({"bucket": "uploads", "key": "cat.jpg"}, {"request_id": "local"}))
 
import os
from datetime import datetime
​
def handler(event, context):
    """
    event = {"bucket": "uploads", "key": "cat.jpg"}
    context = {"request_id": "req-1", "deadline_ms": 0}
    """
    src = os.path.join("data", event["bucket"], event["key"])
    dst = os.path.join("data", "thumbnails", event["key"] + ".thumb")
​
    os.makedirs(os.path.dirname(dst), exist_ok=True)
    with open(src, "rb") as f:
        data = f.read()
​
    # "Process": write the first 1024 bytes to simulate a small thumbnail
    with open(dst, "wb") as f:
        f.write(data[:1024])
​
    return {
        "status": "ok",
        "src_bytes": len(data),
        "dst": dst,
        "time": datetime.utcnow().isoformat() + "Z"
    }
​
if __name__ == "__main__":
    os.makedirs("data/uploads", exist_ok=True)
    # Write a fake binary file

Architecture: Glue + Managed Services

A typical serverless backend:

HTTP/API → function for routing/validation.
Business logic → functions that write to a database/object storage.
Async tasks → queue/stream-triggered workers.
Scheduled jobs → cron functions.
Authentication/authorization → BaaS auth provider.

Are you sure you're getting this? Fill in the missing part by typing it in.

Keeping a baseline number of warm function instances to reduce cold starts is called provisioned __________.

Write the missing line below.

When to Use (and When Not)

Great fit:

Spiky or unpredictable traffic
Event processing pipelines (files, messages)
APIs with modest latency needs
Prototypes/MVPs and teams without ops bandwidth

Maybe not ideal:

Long-running jobs beyond platform time limits
Extremely low-latency, high and constant throughput (consider containers/VMs)
Heavy reliance on local state or custom OS dependencies

Are you sure you're getting this? Click the correct answer from the options.

Which best describes stateless execution?

Click the option that best answers the question.

Function can rely on memory from previous calls
Function must encode all needed state in inputs or external stores
Function writes state to local /tmp and expects it forever

Cost Thinking (Back-of-Envelope)

Serverless charges by duration × memory/CPU setting × invocations (exact math varies). Compare:

A small VM 24/7 could cost X/month even when idle.
A function that runs only on requests might cost far less if traffic is sporadic.

Simple Router Function

Here's an example of a simple router function: one function handling multiple paths using only standard lib parsing.

xxxxxxxxxx
module.exports = { handler };
 
function json(statusCode, obj) {
  return {
    statusCode,
    headers: { "content-type": "application/json" },
    body: JSON.stringify(obj)
  };
}
​
async function handler(event) {
  const path = event.path || "/";
  const method = (event.httpMethod || "GET").toUpperCase();
​
  if (method === "GET" && path === "/health") {
    return json(200, { ok: true });
  }
​
  if (method === "POST" && path === "/echo") {
    const body = typeof event.body === "string" ? event.body : JSON.stringify(event.body || {});
    return json(200, { youSent: body });
  }
​
  return json(404, { error: "not found", path, method });
}
​
if (require.main === module) {
  (async () => {
    console.log(await handler({ path: "/health", httpMethod: "GET" }));
    console.log(await handler({ path: "/echo", httpMethod: "POST", body: { a: 1 } }));
  })();

Observability, the Serverless Way

Structured logging: include request IDs, durations.
Metrics: invocations, errors, duration percentiles, cold vs warm starts.
Tracing: distributed traces across functions, queues, DB calls.
Dead-letter queues (DLQ): capture failed events for later reprocessing.

Are you sure you're getting this? Is this statement true or false?

Because serverless autoscales, you don’t need rate limiting.

Press true if you believe the statement is correct, or false otherwise.

Patterns for State & Performance

Use idempotency keys so re-tried events don’t double-apply work.
Cache config/metadata in memory per container (it may survive between warm calls).
Prefer small bundles to reduce cold start time.
For hot paths, consider provisioned concurrency or platforms with low cold starts (edge runtimes).

Security Basics

Principle of least privilege: functions get only the permissions they need.
Secrets via managed secret stores, not env-hardcoding.
Validate all inputs (even from internal events).
Keep dependencies minimal to reduce attack surface.

Are you sure you're getting this? Fill in the missing part by typing it in.

The practice of making a function safe to run multiple times for the same event (so duplicates don’t corrupt state) is called __________.

Write the missing line below.

Local Dev & Testing

Handlers as pure functions: write them so they can be called locally with fake events.
Unit tests: pass in fixture events/contexts.
Contract tests: validate JSON schemas for events/payloads.
Emulate schedules and queues with small drivers.

JAVASCRIPT

1// hello_test.js (super lightweight "test" without frameworks)
2const { handler } = require("./lambda_hello");
3
4(async () => {
5  const res = await handler({ path: "/test" }, { requestId: "t1" });
6  console.log("status", res.statusCode);
7  console.log("ok", res.body.includes("Hello"));
8})();

Build your intuition. Click the correct answer from the options.

Which workloads are a good fit for serverless?

Click the option that best answers the question.

Constant high-throughput low-latency trading system
Spiky webhook processing and file transforms
Long-running batch jobs exceeding time limits

Edge & “Serverless at the Edge”

Some platforms run functions close to users (edge POPs) with lightweight runtimes (V8 isolates, WebWorkers-style). Benefits: low latency, fast cold starts, but with constraints (e.g., limited CPU time, restricted APIs).

Conclusion

You now know what serverless computing is, when to use it, its trade-offs, and how to structure small handlers. Start by wrapping a single endpoint or cron job as a function, wire it to a queue or storage event, and grow from there—one tiny, stateless piece at a time.

One Pager Cheat Sheet

Serverless computing is a cloud execution model in which you deploy functions or small services without managing servers, letting the platform handle provisioning, scaling, and patching, and paying based on per execution time and resources used.
In serverless architectures, FaaS (Functions as a Service) involves uploading functions that run on demand, while BaaS (Backend as a Service) allows consumption of managed backends via APIs without running them yourself, often mixed together for serverless applications.
Serverless pricing is characterized by paying for execution time and resources used, with charges per invocation, compute time, resource allocation, and operations performed, leading to a consumption-based model that minimizes idle costs but directly ties total cost to actual usage patterns and resource choices.
Key Properties (What You Get) include Automatic scaling to thousands of concurrent executions, No server management with OS/security patching handled by the provider, Event-driven functions triggered by various events, and Granular billing per ms and memory/CPU allocation, while important constraints include functions being stateless, having execution time limits, ephemeral filesystems, and potentially suffering cold starts.
Definitions of Cold start, Warm start, Provisioned concurrency / min instances, and Stateless in the context of serverless computing.
Node.js is used to create a serverless HTTP response by exporting a handler(event, context) function that takes event and context inputs and provides a response.
Serverless platforms require stateless functions that do not depend on in-memory variables due to the lack of guarantees about invocation reuse, emphasizing the use of external, durable state stores for shared or persistent data.
Common Triggers (Events) include HTTP gateways for functions, Object storage events like file uploads for processing and resizing, Queue/stream mechanisms for async jobs, Schedulers for periodic tasks, and DB change streams for reactive workflows.
Serverless HTTP functions follow the sequence of parsing the HTTP request to create an event, allocating or waking the runtime, executing the handler with the event and context, and serializing the handler result into an HTTP response to ensure proper functionality and communication with clients.
Image Thumbnail Worker Implementation is a sample scenario where a serverless storage-triggered function processes files by simulating resizing through byte truncation, showcasing the effectiveness of serverless architecture for event-driven jobs like file processing.
The serverless backend architecture uses Glue to connect HTTP/API, business logic, async tasks, scheduled jobs, and authentication/authorization services managed by BaaS providers.
The correct phrase is provisioned concurrency, where a set amount of ready execution environments are pre-allocated to reduce cold starts and improve latency in serverless platforms.
Use serverless computing when dealing with spiky or unpredictable traffic, event processing pipelines, APIs with modest latency needs, prototypes/MVPs, and teams without ops bandwidth, but it may not be ideal for long-running jobs beyond platform time limits, extremely low-latency high and constant throughput, and heavy reliance on local state or custom OS dependencies.
Stateless execution means an invocation cannot rely on any durable, instance-local memory or filesystem, requiring the function to encode all needed state in inputs or external stores for work to continue correctly across invocations, crashes, and scaled instances.
Serverless computing charges are based on the formula duration × memory/CPU setting × invocations, which can be compared to the cost of running a small VM 24/7 or a function that runs only on requests.
Simple Router Function is an example of a function that can handle multiple paths using standard lib parsing.
Observability in serverless environments includes structured logging with request IDs and durations, metrics for invocations and errors, tracing across functions and calls, and dead-letter queues to capture failed events for reprocessing.
Serverless platforms autoscale compute, but rate limiting is still necessary due to fixed capacity of downstream systems, potential for amplified failures and costs with autoscaling, limits and throttles imposed by cloud providers and accounts, importance of security and abuse prevention, potential impact on latency and user experience, and risks of retries and retry storms; common mitigation techniques include edge throttling, per-user or per-API-key limits, reserved/provisioned concurrency limits, queuing/backpressure with SQS or Kinesis, circuit breaker and exponential backoff, and monitoring metrics.
Patterns for State & Performance include utilizing idempotency keys for event retries, caching config/metadata in memory per container, prioritizing small bundles to decrease cold start time, and considering provisioned concurrency or edge runtimes for hot paths.
Security Basics include implementing the principle of least privilege, using managed secret stores for secrets instead of env-hardcoding, validating all inputs including those from internal events, and minimizing dependencies to reduce attack surface.
Idempotency ensures that an operation can be safely run multiple times without changing the result beyond the initial application, preventing duplicates from corrupting state.
Handlers should be written as pure functions so they can be tested locally with fixture events, validated using JSON schemas, and emulated with small drivers for schedules and queues.
Event-driven, short-lived, highly parallelizable, and bursty workloads are well-suited for serverless platforms due to their automatic scaling, pay-per-use billing, and seamless integration with managed event sources/storage, offering cost efficiency and parallel processing capabilities.
Serverless at the Edge involves running functions close to users in edge POPs using lightweight runtimes, such as V8 isolates and WebWorkers-style, offering benefits like low latency and fast cold starts but with constraints like limited CPU time and restricted APIs.

The One-Sentence Idea

Two Flavors: FaaS and BaaS

Let's test your knowledge. Click the correct answer from the options.

Click the option that best answers the question.

Key Properties (What You Get)

Definitions You’ll See

A Tiny HTTP “Hello”

Are you sure you're getting this? Is this statement true or false?

Common Triggers (Events)

Try this exercise. Could you figure out the right sequence for this list?

Options:

Image Thumbnail Worker Implementation

Architecture: Glue + Managed Services

Are you sure you're getting this? Fill in the missing part by typing it in.

When to Use (and When Not)

Are you sure you're getting this? Click the correct answer from the options.

Click the option that best answers the question.

Cost Thinking (Back-of-Envelope)

Simple Router Function

Observability, the Serverless Way

Are you sure you're getting this? Is this statement true or false?

Patterns for State & Performance

Security Basics

Are you sure you're getting this? Fill in the missing part by typing it in.

Local Dev & Testing

Build your intuition. Click the correct answer from the options.

Click the option that best answers the question.

Edge & “Serverless at the Edge”

Conclusion

One Pager Cheat Sheet

Programming Categories

Popular Lessons