Serverless Architecture and Execution Models

Introduction

Serverless computing is a cloud application model in which the cloud provider manages server provisioning, operating systems, runtime infrastructure, patching, and much of the capacity planning required to run application code. The term does not mean that servers do not exist. Rather, servers are abstracted from the application developer, who deploys functions or services and is charged according to use or an allocated service plan.

Serverless architecture is closely associated with Function as a Service (FaaS), in which small units of code execute in response to events. It also includes managed databases, object storage, message queues, API gateways, authentication services, workflow engines, and observability tools. A complete serverless system therefore consists of more than functions alone.

The model is particularly valuable for event-driven and variable-demand workloads. However, serverless systems also introduce constraints: execution time limits, restricted runtime environments, cold starts, statelessness, provider-specific interfaces, and possible vendor lock-in. Effective design requires understanding both the benefits and the boundaries of the execution model.

Learning Objectives

By the end of this chapter, you should be able to:

• describe serverless architecture and distinguish it from traditional server hosting and containers;
• explain the lifecycle of a serverless function invocation;
• analyse triggers, event payloads, stateless execution, and asynchronous processing;
• explain cold starts, scaling behaviour, concurrency, and execution limits;
• select appropriate managed services for a serverless solution;
• identify vendor constraints, portability concerns, security responsibilities, and governance issues; and
• evaluate whether a workload is suitable for serverless execution.

1. The Serverless Architectural Model

In a traditional application, an organisation provisions virtual machines or physical servers, installs an operating system, deploys an application, configures networking, and plans capacity. With containers, the organisation packages the application and its dependencies, but still commonly manages clusters, scheduling, networking, and scaling policies. In a serverless model, the provider manages most of this infrastructure and exposes an application-oriented interface.

A typical serverless request path is:

1. An event is produced by a user, device, schedule, storage system, queue, or another application.
2. An event source routes the event to a function or workflow.
3. The platform selects an execution environment and supplies the event payload.
4. The function initialises, executes its handler, and returns a result or produces another event.
5. The platform records logs and metrics, then may retain, suspend, or destroy the execution environment.

Serverless architecture commonly combines four layers:

The architectural principle is to use managed capabilities for undifferentiated infrastructure work while retaining control over business logic, data design, security policy, and service integration.

FaaS and broader serverless computing

FaaS is the execution component of serverless computing. A function is normally deployed as a package containing code and, where permitted, libraries. It is invoked by an event rather than continuously listening on a manually managed server.

The broader serverless model includes services that may not be functions. A managed database, for example, can be serverless if the provider automatically handles capacity and scaling. Similarly, a serverless workflow service may coordinate functions and queues without requiring the customer to operate a workflow server.

2. Function Lifecycle and Invocation Semantics

A function has both a deployment lifecycle and an invocation lifecycle.

Deployment lifecycle

During deployment, the developer typically:

• writes a handler and configuration;
• declares dependencies and runtime settings;
• assigns an identity and permissions;
• packages or uploads the function;
• configures triggers, memory, timeout, networking, and environment variables; and
• publishes a version or deployable revision.

The provider validates the package and prepares it for execution. Deployment success does not guarantee that every invocation will succeed; permissions, downstream services, event formats, and runtime conditions must also be tested.

Invocation lifecycle

An invocation generally contains the following stages:

Environment selection. The platform selects an isolated execution environment. If an appropriate environment already exists, it may be reused. Otherwise, a new environment must be created.

Initialisation. The runtime is started, code is loaded, dependencies are imported, and initialisation statements outside the handler are executed. This is often called a cold start when a new environment is created.

Handler execution. The platform calls the function handler with an event object and execution context. The handler validates input, performs business logic, calls permitted services, and returns a response or emits a result.

Completion. The platform records the outcome. The environment may remain available for reuse, become idle, or be terminated. Reuse is not guaranteed.

Code outside the handler can be used for safe, reusable initialisation, such as creating a client for a managed database. It must not be assumed to execute only once during the lifetime of the application, because environments can be recreated at any time. Conversely, code inside the handler must be prepared to execute on every invocation.

Synchronous and asynchronous invocation

In a synchronous invocation, the caller waits for a response. API requests and interactive applications commonly use this pattern. A failure can be returned directly to the caller, although retry behaviour must be designed carefully.

In an asynchronous invocation, the event source accepts the event and the function processes it later. The platform or an intermediate queue may retry failed deliveries. This improves resilience and decouples producers from consumers, but it creates a need for idempotency, dead-letter handling, and monitoring of processing delay.

For stream and queue sources, the platform may poll records and invoke the function with a batch. A failure may cause the batch, or part of it, to be retried depending on the service semantics. Developers must understand whether ordering, duplication, checkpointing, and partial failure are supported.

3. Triggers and Event-Driven Design

A trigger is a configured condition that causes a function to run. Common trigger categories include:

• HTTP requests from browsers, mobile applications, or other services;
• scheduled events such as hourly or daily jobs;
• object-storage events, such as a newly uploaded image;
• database change streams;
• queue messages and publish-subscribe topics;
• device or telemetry events; and
• workflow state transitions.

An event is data describing what happened. It is not necessarily the business object itself. For example, an object-storage event may contain a bucket name, object key, event time, and metadata. The function may then retrieve the object using the supplied identifier.

A robust event-driven design should specify:

• the event schema and versioning policy;
• whether delivery is at-most-once, at-least-once, or effectively exactly-once under defined conditions;
• ordering requirements;
• maximum event and batch size;
• retry and back-off behaviour;
• duplicate detection and idempotency; and
• how invalid or permanently failing events are isolated.

The practical default for distributed serverless systems is at-least-once delivery unless the provider explicitly guarantees otherwise. At-least-once delivery means a correctly processed event may be delivered again. A function should therefore make repeated processing harmless. For example, a payment-recording function can use a unique transaction identifier and a conditional database write rather than blindly inserting a new payment on every delivery.

4. Stateless Execution and Durable State

A serverless function should normally be treated as stateless. Statelessness means that correctness does not depend on memory retained by a previous invocation or on a particular execution environment being reused. Local variables disappear when the invocation ends, and local files may disappear when the environment is destroyed.

Durable state should be placed in an external service selected for the access pattern:

Externalising state introduces network latency, cost, consistency questions, and failure modes. Statelessness is therefore not an excuse to ignore state design. It means state is made explicit and managed deliberately.

A useful distinction is between durable state and ephemeral state. Durable state must survive environment termination. Ephemeral state, such as a temporary calculation result or a cached client connection, may be retained locally for performance but must not be required for correctness.

5. Cold Starts and Performance

A cold start occurs when the platform creates a new execution environment before running a function. It may include downloading code, starting the language runtime, loading libraries, establishing network configuration, and executing initialisation code. A warm invocation reuses an existing environment and usually avoids much of this work.

Cold-start latency varies with runtime, package size, initialisation work, networking configuration, provider implementation, and current demand. It is not a fixed property of a programming language or a platform. Applications with strict latency requirements should measure real workloads rather than rely on general claims.

Common mitigation techniques include:

• reducing deployment-package size and unnecessary dependencies;
• moving reusable client creation outside the handler where safe;
• minimising expensive initialisation;
• selecting a suitable runtime and memory configuration;
• using provisioned or pre-warmed capacity where the provider offers it; and
• separating latency-sensitive endpoints from infrequent background jobs.

Pre-warming can reduce cold starts but may increase cost. It also does not remove all sources of latency, such as downstream database connections or network calls.

For a synchronous request, a simplified latency model is:

Here, L_total is total observed latency, and each term represents trigger or gateway delay, environment-start delay, queueing delay, function execution time, downstream-service delay, and response transmission time. The model is a decomposition for diagnosis, not a universal performance law. Terms may overlap in some platforms, and their values can vary between invocations.

6. Scaling, Concurrency, and Capacity

Serverless platforms commonly create multiple execution environments as demand increases. This is horizontal scaling: more concurrent invocations are placed in separate environments. When demand decreases, unused environments may be removed.

A function environment usually processes one invocation at a time, although this is platform- and runtime-dependent. Consequently, concurrent requests may require multiple environments. A simplified concurrency relationship is:

where C is average concurrency, λ is average arrival rate in invocations per second, and W is average time in seconds that an invocation occupies the service. This is an application of Little’s Law under stable conditions and assumes a sufficiently representative average over a defined period. Units are consistent because invocations/second × seconds = invocations, interpreted as concurrent invocations.

For example, if a function receives an average of 40 invocations per second and each occupies the platform for 0.25 seconds, estimated average concurrency is:

A short burst can require much greater concurrency than this average. Provisioning, account quotas, downstream limits, and regional capacity may restrict scaling. Consequently, automatic scaling of functions does not imply unlimited scaling of the whole system.

A common failure pattern is a rapidly scaling function overwhelming a database connection limit. If each of 100 concurrent function environments opens a database connection, the database may become the bottleneck. Connection pooling, proxy services, bounded concurrency, queues, or a database designed for the access pattern may be required.

Scaling modes also differ by trigger. HTTP requests may scale per request; queue consumers may scale by increasing polling or batch workers; stream consumers may be limited by partitions or shards. Architects must examine the scaling semantics of the complete path from producer to function to downstream service.

7. Execution Limits and Platform Constraints

Serverless services impose limits that protect shared infrastructure and make capacity predictable. Limits may include:

• maximum execution duration;
• memory and temporary-storage limits;
• deployment-package size;
• request and response size;
• maximum concurrency;
• event or batch size;
• environment-variable limits;
• network and file-system restrictions; and
• regional quotas or account-level service limits.

Exact values differ by provider, region, runtime, and service tier and may change over time. A professional design must consult current provider documentation and validate limits through testing. The architectural point is more stable than any particular number: a function is not an unlimited general-purpose server.

Long-running tasks should be decomposed into stages, placed in a queue, or coordinated by a workflow service. Large files should normally move through object storage rather than an API payload. Functions that require sustained processing, specialised operating-system features, persistent connections, or custom hardware may be better implemented with containers, virtual machines, or a specialised managed service.

Timeouts require special care. If a caller times out but the function continues running, the operation may be completed even though the caller retries. This is another reason to use idempotency keys and explicit operation status records.

8. Managed Services and Composable Architecture

The strength of serverless architecture comes from composing managed services rather than placing every responsibility in one function. A typical image-processing flow may use an upload endpoint, object storage, an event notification, a queue, an image-processing function, a metadata database, and a notification service.

Managed services reduce operational work, but they do not remove design responsibility. Teams still need to select data models, define permissions, configure retention, manage costs, monitor reliability, and test failure behaviour.

A useful design principle is loose coupling. Producers should not need to know the internal implementation of consumers. Queues absorb temporary bursts and provide retry boundaries. Event buses allow multiple consumers to react to the same business event. Workflow services are preferable to embedding complex multi-step coordination in a single function.

A second principle is least privilege. Each function should have only the permissions required for its task. A function that resizes images should not have unrestricted access to all databases and storage locations.

9. Vendor Constraints and Portability

Serverless applications can become tightly coupled to a provider through:

• proprietary event formats;
• provider-specific identity and permission models;
• unique database APIs;
• deployment descriptors and infrastructure templates;
• specialised messaging semantics; and
• monitoring, tracing, and workflow features.

Portability is not automatically the correct goal. Using a provider-specific service may produce better reliability, productivity, or cost. However, the choice should be deliberate. Teams should identify which components are portable and which are strategic dependencies.

Portability strategies include defining domain logic separately from adapters, using standard protocols where practical, versioning event schemas, keeping data-export procedures, documenting provider assumptions, and testing recovery or migration procedures. Multi-cloud operation can reduce dependence in some contexts, but it also increases operational complexity, duplicated skills, inconsistent semantics, and cost. It should not be adopted merely as a slogan.

10. Security, Governance, and Observability

Serverless security follows a shared-responsibility model. The provider secures the underlying infrastructure, while the customer remains responsible for code, identities, permissions, data classification, secrets, configuration, and regulatory obligations.

Important controls include:

• authentication and authorisation at API and function boundaries;
• least-privilege identities for functions;
• encryption in transit and at rest;
• managed secret storage rather than hard-coded credentials;
• input validation and output encoding;
• dependency scanning and secure deployment pipelines;
• audit logs for administrative and data-access actions; and
• retention and deletion policies appropriate to the data.

Observability is more difficult when one user request crosses many managed services. Correlation identifiers should be propagated through events. Logs should record meaningful context without exposing passwords, tokens, or unnecessary personal information. Metrics should include invocation count, error rate, duration, throttling, retries, queue age, concurrency, and downstream failures.

Serverless also has governance implications. Automatic scaling can create unexpected expenditure, and event duplication can cause repeated external actions. Budgets, quotas, cost alerts, tagging, approval controls, and production-change procedures are therefore essential.

11. Suitable and Unsuitable Workloads

Serverless is often suitable for:

• irregular or bursty web APIs;
• scheduled automation;
• file and image processing;
• event transformation and routing;
• asynchronous notifications;
• lightweight data validation and enrichment;
• IoT event processing;
• back-office integrations; and
• independently deployable application operations.

It may be unsuitable or require careful qualification for:

• applications needing consistently ultra-low latency;
• workloads that run continuously for long periods;
• high-performance computing requiring specialised hardware;
• applications dependent on local in-memory state;
• systems requiring long-lived connections or custom operating-system access;
• workloads with strict data-residency requirements unsupported by the provider; and
• workloads whose traffic pattern makes reserved or dedicated infrastructure cheaper.

Suitability should be evaluated against latency, duration, state, traffic variability, integration requirements, security, compliance, cost, and team capability. “Serverless” is an architectural option, not a universal replacement for all other deployment models.

Applied Case: Illustrative Online Image-Processing Service

Background

A small media company receives user-uploaded photographs. Each image must be checked, resized into three standard formats, have metadata extracted, and become available through a web gallery. Upload volume varies significantly: normal traffic is modest, but marketing campaigns can create large bursts.

Problem

A permanently running server would need enough capacity for campaign peaks, leaving much of that capacity idle during normal periods. The company also wants automatic retries when image processing fails and does not want the web application to wait for all transformations to finish.

Analysis

The workload is event-driven, naturally parallel, and variable. Image files are durable objects rather than request-sized data. Processing can be asynchronous, and each image can be handled independently. These characteristics favour a serverless design.

Approach and solution

1. The upload API authenticates the user and issues a controlled upload request.
2. The client stores the original image in object storage.
3. An object-created event places a message on a queue.
4. A processing function reads the message, retrieves the image, creates the required formats, and stores them back in object storage.
5. Metadata is written to a managed database.
6. A notification or status event informs the gallery service that processing is complete.
7. Failed messages are retried and eventually moved to a dead-letter queue for investigation.

The function uses the object identifier and a processing version as an idempotency key. Before writing a derivative, it checks whether that derivative already exists or whether a durable processing record indicates completion. The function does not rely on local files after termination. Concurrency is bounded so that the database and storage service are not overwhelmed.

Outcome

The company can absorb ordinary bursts through queue buffering and increase processing concurrency within configured quotas. Costs align more closely with image volume than with peak server capacity. However, it must monitor queue age, function duration, storage growth, retry counts, and processing cost. If image transformations become very long or require specialised libraries, a managed container worker may become more appropriate.

Learning points

The case illustrates that serverless suitability depends on workload characteristics, not merely on the desire to avoid servers. Durable storage, asynchronous integration, idempotency, bounded concurrency, and operational monitoring are central to a successful design.

Best Practices

1. Design functions around clear business responsibilities rather than arbitrary technical fragments.
2. Keep handlers small, testable, and explicit about input and output contracts.
3. Treat events as versioned interfaces.
4. Assume retries and duplicate delivery unless stronger guarantees are documented.
5. Externalise durable state and use local state only as an optimisation.
6. Measure cold starts, downstream latency, and end-to-end performance.
7. Set concurrency and quota controls to protect downstream systems.
8. Use queues and workflows for asynchronous or multi-step processes.
9. Apply least privilege and store secrets in managed secret services.
10. Monitor cost, errors, retries, throttling, and business outcomes.
11. Document provider-specific dependencies and migration assumptions.
12. Test timeout, partial failure, duplicate events, and downstream unavailability.

Chapter Summary

Serverless architecture abstracts infrastructure management while exposing functions and managed services through event-driven interfaces. Function invocations pass through environment selection, initialisation, handler execution, and completion; environments may be reused, but reuse cannot be assumed. Cold starts arise when a new environment is created and can affect latency.

Serverless functions are normally stateless. Durable state belongs in managed storage, databases, queues, caches, or workflow services. Event delivery commonly involves retries and possible duplication, making idempotency and failure isolation essential. Automatic scaling creates more concurrent execution environments, but quotas and downstream capacity remain important constraints. The relationship C ≈ λ × W provides a useful estimate of average concurrency under stable conditions.

Managed services improve operational efficiency but introduce provider-specific semantics, cost considerations, and possible vendor lock-in. Security, governance, observability, and data protection remain customer responsibilities. Serverless is well suited to event-driven, bursty, modular workloads, but long-running, stateful, specialised, or consistently latency-sensitive workloads may require containers or other infrastructure models.

Key Terms

Serverless computing: A cloud model that abstracts server management from application developers.

Function as a Service (FaaS): A service that executes deployed functions in response to events.

Function: A deployable unit of application logic invoked by a platform.

Invocation: One execution of a function handler.

Trigger: A condition or event that causes a function to execute.

Event: Data describing something that has happened in a system.

Handler: The function entry point called by the execution platform.

Cold start: Latency caused by creating and initialising a new execution environment.

Warm invocation: An invocation using an already initialised environment.

Statelessness: A design property in which correctness does not depend on retained local execution state.

Durable state: Information that survives function-environment termination.

Idempotency: The property that repeated processing produces the same intended result as one successful processing.

Concurrency: The number of invocations executing at the same time.

Horizontal scaling: Increasing capacity by running more execution environments.

Managed service: A provider-operated service that reduces customer infrastructure administration.

Queue: A service that buffers and delivers messages, often enabling asynchronous processing.

Dead-letter queue: A destination for messages that cannot be successfully processed.

Vendor lock-in: Dependence on provider-specific technology that makes migration difficult.

Shared responsibility: The division of security duties between cloud provider and customer.

Review Questions

Short Answer Questions

1. What is meant by serverless computing, and why does the term not imply that physical servers are absent?
2. Describe the main stages of a function invocation lifecycle.
3. Why should durable state normally be stored outside a serverless function environment?
4. What is a cold start, and identify two factors that can influence it.
5. Why is idempotency important when processing events from queues or asynchronous sources?

Long Answer Questions

1. Compare serverless functions with virtual machines and containers in terms of infrastructure management, scaling, operational responsibility, and constraints.
2. Explain how triggers, queues, event buses, and workflow services can be combined to create a loosely coupled serverless application.
3. Discuss the causes and effects of vendor lock-in in serverless systems and evaluate practical portability strategies.
4. Explain the security and governance responsibilities that remain with a customer using managed serverless services.
5. Evaluate the advantages and limitations of serverless architecture for a high-volume online retail application.

Analytical / Application Questions

1. A function receives 80 invocations per second, and each invocation occupies the platform for an average of 0.15 seconds. Estimate average concurrency using C ≈ λ × W. State why a burst could require more capacity than the estimate.
2. Design an event-driven architecture for a document-upload service that validates files, extracts text, stores results, and handles failed processing. Identify triggers, managed services, retry behaviour, durable state, and security controls.
3. A team reports that its serverless API scales successfully but its managed database frequently rejects connections. Analyse the likely architectural cause and propose at least three corrective measures.

Multiple Choice Questions with Answers

Question 1

Which statement best describes serverless computing?

A. It eliminates all physical servers from the cloud

B. It requires customers to patch the operating system of every function

C. It abstracts much infrastructure management while allowing code to run in response to events

D. It is another name for a dedicated physical server

Correct Answer: C. It abstracts much infrastructure management while allowing code to run in response to events

Question 2

What is a cold start?

A. A failed database transaction caused by low temperature

B. The delay involved in creating and initialising a new function environment

C. The time required to delete an old software version

D. A queue that contains no messages

Correct Answer: B. The delay involved in creating and initialising a new function environment

Question 3

Which design principle is most important when asynchronous event delivery may retry a message?

A. Idempotency

B. Unlimited local memory

C. Manual server patching

D. Disabling all logging

Correct Answer: A. Idempotency

Question 4

Where should durable application state normally be stored in a serverless design?

A. Only in local variables inside the handler

B. In an external managed data or storage service

C. In the temporary memory of one execution environment

D. In the function's console output

Correct Answer: B. In an external managed data or storage service

Question 5

A function receives 40 invocations per second and each occupies the service for 0.25 seconds. Using C ≈ λ × W, what is the estimated average concurrency?

A. 4

B. 10

C. 40

D. 160

Correct Answer: B. 10

Question 6

Which component is most suitable for buffering work and supporting asynchronous processing?

A. Message queue

B. Static HTML file

C. Environment variable

D. DNS record

Correct Answer: A. Message queue

Question 7

Why can automatic function scaling still overload a database?

A. Scaling functions always disables database authentication

B. Many concurrent function environments may create more database demand than the database can accept

C. Functions cannot communicate with databases

D. Database capacity increases faster than function capacity

Correct Answer: B. Many concurrent function environments may create more database demand than the database can accept

Question 8

Which workload is generally well suited to serverless execution?

A. A continuously running operating-system kernel

B. An event-driven image-processing task with variable demand

C. A workload requiring permanent local memory on one server

D. A process that must run indefinitely without interruption

Correct Answer: B. An event-driven image-processing task with variable demand

Question 9

What is a dead-letter queue used for?

A. Storing successfully completed events permanently

B. Holding messages that repeatedly fail processing for later investigation

C. Increasing the memory available to a function

D. Replacing authentication controls

Correct Answer: B. Holding messages that repeatedly fail processing for later investigation

Question 10

Which practice best reduces excessive permissions in a serverless application?

A. Give every function administrator access

B. Use one shared credential for all services

C. Apply least-privilege identities to individual functions

D. Remove audit logs from production

Correct Answer: C. Apply least-privilege identities to individual functions