Serverless Computing Concepts: Function-as-a-Service (FaaS) & Event Triggers

In traditional cloud infrastructure models—Infrastructure as a Service (IaaS) and Container as a Service (CaaS)—engineering teams remain responsible for server capacity planning, operating system patching, hypervisor security, load balancer scaling, and paying for idle CPU cycles when traffic fluctuates. When an application receives zero requests in the middle of the night, provisioned virtual machines continue billing at full hourly rates.

Serverless computing and Function-as-a-Service (FaaS) eliminate this operational friction by shifting the entire infrastructure management paradigm directly to the cloud provider. Under an event-driven serverless architecture, developers author granular business logic functions that execute strictly in response to discrete system events, scaling automatically from zero to thousands of parallel invocations, with organizations billed exclusively for exact execution milliseconds.

Deconstructing "Serverless": Managed Infrastructure Reality

A common misconception in modern computing is that "serverless" literally means servers no longer exist. In reality, servers still physically exist: physical enterprise server chassis, multi-core CPU sockets, RAM modules, network interface cards, and host operating systems still execute every line of application code. The term "serverless" simply signifies that the cloud provider manages the underlying server infrastructure, completely abstracting hardware provisioning, capacity planning, OS patching, and hypervisor maintenance from the software engineer:

The FaaS Execution Lifecycle: Cold vs Warm Starts

Unlike persistent virtual machines that keep application processes resident in memory indefinitely, FaaS platforms execute code within isolated, ephemeral micro-environments:

1. Event Invocation: An event source (e.g., an HTTP request or file upload) triggers the function.
2. Cold Start Instantiation: If no idle execution environment is currently available, the cloud provider allocates a worker node, downloads the application container/zip artifact, initializes the runtime engine (Node.js, Python, Java, or .NET), and executes global initialization code (database connection pools, SDK clients). This cold start latency typically introduces a 100 ms to 1,500 ms delay depending on language runtime and package bundle size.
3. Handler Execution: The runtime invokes the specific handler function, passing the event payload and context object.
4. Idle Freeze / Warm Start: After execution completes, the provider freezes the execution environment for a short duration (typically 5 to 15 minutes). If another event arrives while the environment is warm, it executes instantly in single-digit milliseconds, bypassing the initialization overhead.
5. Teardown: If no subsequent requests arrive before the idle timeout elapses, the provider terminates the worker and reclaims all memory.

Stateless Design: The Fundamental Architectural Rule

Because FaaS execution environments are ephemeral and can be destroyed at any moment by the cloud provider's scheduler, serverless functions must be engineered to be strictly stateless:

• No In-Memory Session State: Never store user login sessions, shopping cart contents, or transactional counters in local global variables. If Request 1 lands on Worker A and Request 2 lands on Worker B, local memory is completely unshared.
• Ephemeral Local Storage: Platforms provide temporary scratch space (such as /tmp), but this disk space is purged when the environment reclaims. All permanent files must be streamed directly to cloud object storage (e.g., Amazon S3 or Azure Blob Storage).
• State Offloading: State must be externalized to fast, distributed cloud databases (Amazon DynamoDB, Azure Cosmos DB) or in-memory caches (Redis / Memcached).

Event-Driven Trigger Typologies

Serverless functions are activated by three distinct event invocation patterns:

Implementation Example: AWS Lambda Architecture & Scaling Controls

To understand how vendor-neutral serverless concepts materialize in production, consider AWS Lambda as an industry-standard implementation example. Note that the following resource-allocation and scaling models are specific to AWS Lambda, rather than universal specifications across all FaaS providers:

• Firecracker MicroVM Isolation: AWS Lambda executes customer code within ephemeral, hardware-virtualized microVMs managed by the open-source Firecracker hypervisor on Linux KVM.
• Memory-to-CPU Proportionality: In AWS Lambda, administrators configure function memory (from 128 MB to 10,240 MB). CPU allocation is not configured independently; rather, AWS scales vCPU compute power strictly proportional to the allocated memory. At 1,769 MB of RAM, a function receives the equivalent of one full vCPU core.
• Reserved Concurrency: Guarantees a dedicated slice of the regional account concurrency pool (default: 1,000) for a specific critical function, preventing other noisy-neighbor functions from exhausting pool capacity, while also setting an upper ceiling to throttle spend.
• Provisioned Concurrency: Pre-initializes a requested number of execution environments (downloading the deployment package and executing initialization handlers in advance). This completely eliminates cold starts for latency-sensitive interactive production workloads, keeping environments permanently warm at a modest baseline cost.