Serverless Computing

Serverless functions are invoked by specific events or triggers, not by continuously running servers. Common triggers include:

• HTTP requests (via API Gateway)
• File uploads to object storage (e.g., S3)
• Database changes (via Change Data Capture)
• Messages arriving in a queue (e.g., SQS, Kafka)
• Scheduled cron jobs Execution is stateless and ephemeral; the runtime environment is created on-demand and destroyed after the function completes.

The cloud provider automatically scales the execution environment from zero to thousands of concurrent instances in response to the incoming event rate. This is granular scaling, where each function instance handles a single request. There is no need to pre-provision capacity or configure auto-scaling groups. Scaling is nearly instantaneous and transparent to the developer.

Billing is based on precise resource consumption, not reserved capacity. You are charged for:

• Execution time: Measured in milliseconds from when your code begins running until it returns or terminates.
• Number of invocations: Each function trigger incurs a cost.
• Allocated memory: You configure the memory for your function, which often directly influences CPU power and cost. Idle time costs nothing, making it highly cost-effective for variable or sporadic workloads.

The core abstraction: developers are not responsible for provisioning, maintaining, patching, securing, or scaling any underlying virtual machines, containers, or physical servers. The cloud provider manages the operating system, runtime, security patches, and the fleet of execution environments. The developer's responsibility is limited to their function code and its configuration.

Serverless platforms are distributed by design. Functions are run across multiple availability zones within a region automatically. If an underlying host fails, the platform instantly routes the event to a healthy instance. This provides high availability without the developer needing to design for redundancy, load balancing, or failover.

Each function invocation is stateless. The execution environment is created fresh for each request and is destroyed afterward. Any required state (user sessions, data) must be stored in external, persistent services like databases, object storage, or caches. This design enforces clean separation between compute and state, aligning with cloud-native principles but requiring careful architecture for stateful workflows.

Serverless functions are triggered by event streams (e.g., from Apache Kafka, Amazon Kinesis) to process data in real-time. This pattern is ideal for:

• Streaming ETL: Transforming and enriching data records on-the-fly.
• Real-time analytics: Calculating aggregations or detecting anomalies as events arrive.
• Change Data Capture (CDC): Reacting to database changes published by tools like Debezium. Execution scales to zero when no data is flowing, eliminating idle compute costs.

Instead of maintaining always-on endpoints, serverless functions can host machine learning models for on-demand or scheduled inference. This is cost-effective for:

• Batch prediction jobs: Processing large datasets on a cron schedule (e.g., nightly customer churn scores).
• Asynchronous API endpoints: Handling variable, unpredictable inference request volumes. Models are loaded from object storage (e.g., Amazon S3) on a cold start, with subsequent requests benefiting from cached instances during a warm start period.

In machine learning pipelines, features often need to be computed or updated based on new data. Serverless functions enable event-driven feature engineering:

• Real-time feature stores: A function is invoked by a database change or message, computes a new feature value (e.g., a 30-day rolling average), and writes it to a low-latency feature store.
• Online transformations: Applying the same preprocessing logic used during training to live inference requests. This ensures feature consistency between training and serving environments.

Complex data and ML workflows can be decomposed into discrete steps, each implemented as a serverless function. Orchestration services (e.g., AWS Step Functions, Azure Durable Functions) manage the workflow's state, retries, and error handling.

• Model training pipelines: Chain functions for data validation, preprocessing, training, and evaluation.
• Multimodal data processing: Orchestrate parallel functions to process video, audio, and text, then a final function to fuse the results. This creates resilient, observable, and modular pipelines without managing scheduler infrastructure.

Serverless functions are the foundational building block for API backends and webhook handlers in data systems.

• Data product APIs: Expose clean, domain-specific interfaces (e.g., a customer embeddings API) that internally queries databases or vector stores.
• Third-party integration webhooks: Receive and validate data from external SaaS platforms, transform it, and forward it to a data lake or message queue.
• Lightweight query engines: Execute parameterized queries against a database with built-in connection pooling and auto-scaling.

Generating synthetic or augmented training data is often computationally intensive but sporadic. Serverless computing provides massive parallel compute for short bursts.

• Image augmentation: A function is triggered for each image in a dataset, applying rotations, flips, and color jitters in parallel.
• Text paraphrasing: Using a hosted language model, thousands of text samples can be rephrased concurrently by independent function instances.
• Sensor data simulation: Generating synthetic time-series data for edge cases. Costs are directly proportional to the volume of data processed, with no upfront provisioning.

Function as a Service (FaaS) is the core execution model within serverless computing. It allows developers to deploy individual functions—stateless blocks of code—that are triggered by events (e.g., an HTTP request, file upload, or database change). The cloud provider manages the underlying compute instances, automatically scaling from zero to handle load and billing only for the execution time of each function invocation, measured in milliseconds.

• Key characteristic: Ephemeral, stateless execution environments.
• Primary use case: Event-driven processing, API backends, and data transformation.
• Examples: AWS Lambda, Google Cloud Functions, Azure Functions.

Backend as a Service (BaaS) refers to cloud-managed, API-accessible services that replace core backend components, such as databases, authentication, and file storage. While not strictly "serverless" in the compute sense, BaaS is a complementary pillar that allows developers to assemble applications without provisioning or managing servers for these supporting services. Combined with FaaS, it enables fully serverless application architectures.

• Key characteristic: Managed, API-driven infrastructure services.
• Primary use case: Offloading undifferentiated heavy lifting (databases, user management).
• Examples: Firebase, AWS Amplify, Supabase.

Event-Driven Architecture (EDA) is the foundational design pattern for serverless systems. In EDA, components communicate by producing and consuming events—discrete notifications of a state change or occurrence. Serverless functions are ideal event consumers. This paradigm enables loose coupling, where functions are triggered by events from various sources (message queues, storage events, database streams), allowing for highly scalable and reactive systems.

• Key characteristic: Decoupled communication via events/messages.
• Primary use case: Building reactive, scalable microservices and data pipelines.
• Enabling Technologies: Apache Kafka, Amazon EventBridge, Cloud Pub/Sub.

Cold start latency is the delay incurred when a serverless function is invoked after being idle, requiring the cloud provider to initialize a new runtime environment (container). This involves loading the function's code, dependencies, and the runtime itself. Warm starts—subsequent invocations on a pre-initialized environment—are significantly faster. Managing cold starts is a critical performance consideration, often addressed through provisioned concurrency, optimized package sizes, and keeping functions active with periodic invocations.

• Impact Factors: Runtime language (Go, Rust start faster than Java), package size, memory allocation.
• Mitigation: Use lighter runtimes, implement connection pooling patterns, leverage provisioned concurrency.

Stateless execution is a core constraint and design principle of serverless functions. Each function invocation is intended to be independent; the runtime environment is ephemeral and may not persist between invocations. Any required state (user sessions, application data) must be externalized to durable, cloud-managed services like databases, caches (Amazon ElastiCache, Redis), or object storage. This constraint enables the cloud provider to scale horizontally by launching thousands of identical, parallel instances without concern for shared memory or disk state.

• Design Implication: All persistent state must be external.
• Benefit: Enables massive, transparent scalability and resilience.

Pay-per-use billing is the fundamental economic model of serverless computing. Instead of paying for pre-allocated, always-on server capacity (e.g., a monthly fee for a virtual machine), you are billed based on precise resource consumption. For FaaS, this is typically the number of function invocations and the duration of execution (rounded to the nearest millisecond), multiplied by the amount of memory provisioned. This model converts capital expenditure (CapEx) on infrastructure into a variable operational expense (OpEx), aligning costs directly with application usage.

• Granularity: Billing in increments of 1ms of execution time.
• Cost Driver: Number of requests, execution duration, and configured memory.