Skip to main content

Function as a Service (FaaS)

What Is FaaS?​

Function as a Service is a cloud computing model where:

  • You write a single function (not a full application)
  • The cloud provider runs it on-demand
  • You pay only for execution
  • Scaling is automatic and transparent

Simple Explanation​

What it is​

FaaS is the most focused form of serverless: you write one small function and the platform runs it only when an event happens.

Why we need it​

It is the fastest path from idea to running code, especially for small tasks that should not justify a full server.

Benefits​

  • Tiny, focused units that are easy to deploy and replace.
  • Automatic scaling without tuning infrastructure.
  • Pay only for work done, not for idle time.

Tradeoffs​

  • Short execution limits compared to long-running servers.
  • Stateless design required for every invocation.
  • More functions to manage if you split too much.

Real-world examples (architecture only)​

  • Form submission → Function → Validate input → Store record.
  • Queue message → Function → Process one item.

FaaS vs. Other Models​

ModelYou ManageProvider Manages
VMs (EC2)OS, runtime, appNetwork, hardware
Containers (ECS)Container, appNetwork, orchestration
FaaS (Lambda)Code onlyEverything else

Key Characteristics of FaaS​

1. Stateless​

Each invocation is independent. Don't rely on data from previous invocations.

# ✅ Good: Read data from external store each time
def handler(event, context):
    data = get_from_database()
    return process_result(data)

# ❌ Bad: Assuming state persists
counter = 0
def handler_bad(event, context):
    global counter
    counter += 1
    return counter  # Not safe across invocations

What this does: The first function reads state from an external store on every invocation (safe and scalable). The second keeps state in memory, which is unreliable in serverless.

2. Ephemeral​

Your function lives only during execution, then disappears.

  • Execution environment is fresh each time
  • No persistent local storage
  • Use external services (S3, DynamoDB) for state

3. Triggered by Events​

Functions don't run continuously. An event causes them to wake up.

Events can be:

  • HTTP requests (API Gateway)
  • File uploads (S3)
  • Database changes (DynamoDB Streams)
  • Scheduled timers (EventBridge)
  • Messages (SNS, SQS)

4. Automatically Scaled​

AWS runs multiple copies of your function in parallel for concurrent requests.

Automatic scaling

No configuration needed.

FaaS Limitations​

  1. Cold Starts — Startup latency varies by runtime and configuration
  2. Timeout — Max execution time varies by provider and generation
  3. Memory Constraints — Memory limits vary by provider and generation
  4. Stateless Only — Can't store data in function memory between invocations
  5. Language Support — Limited to AWS-supported runtimes

FaaS Use Cases​

Use CaseGood?Why
REST API✅Scales automatically, pay-per-request
Real-time data processing✅Event-driven, no idle costs
Batch processing✅Process files as they arrive
Background jobs✅Async, triggered by events
24/7 always-on service❌Costly, better with traditional servers
Machine learning inference✅Good for predictions triggered on-demand

FaaS Pricing Formula​

Cost = (Requests × Request Price) + (GB-Seconds × GB-Second Price)

Example:

  • Pick your provider's request price
  • Measure average duration and memory
  • Plug into the formula using official pricing

Best Practices for FaaS​

  1. Keep functions small — One responsibility per function
  2. Minimize cold starts — Use efficient runtimes and code
  3. Avoid long-running tasks — Break into smaller, parallel functions
  4. Externalize state — Use databases, caches, filesystems
  5. Monitor and alert — Track execution time and errors

Key Takeaway​

FaaS is perfect for event-driven, variable workloads. Write focused functions, let the platform handle scaling, and pay only for what you use.

Project (Cloud-Agnostic)​

Design a simple event-driven workflow: when a file is uploaded, generate a thumbnail and store metadata.

Deliverables:

  1. Describe the vendor-neutral architecture (event source, compute, state, observability).
  2. Map each component to AWS or GCP services.
  3. Explain why each service is the right fit for cost, performance, and simplicity.

If you want feedback, email your write-up to [email protected].

References​