Foundations of Serverless Computing and Microservices

Introduction and Context

Cloud computing has transformed software delivery from the ownership of physical infrastructure into the on-demand consumption of computing capabilities. Organisations can now obtain processing, storage, networking, databases and application services through programmable interfaces. Serverless computing and microservices represent two important developments within this broader transformation.

The term serverless does not mean that servers have disappeared. Servers, operating systems, networks and data centres still exist, but their provisioning and routine management are largely handled by a cloud provider. Developers concentrate on application behaviour rather than capacity planning, operating-system patching and server maintenance. Microservices, by contrast, are primarily an architectural approach: an application is decomposed into small, independently deployable services, each aligned with a business capability.

These ideas are related but not identical. A microservice may run on virtual machines, containers or serverless functions. A serverless application may consist of functions, managed databases, queues and other services without being designed as a conventional microservice system. Understanding this distinction is essential for sound cloud architecture.

Learning Objectives

After studying this chapter, you should be able to:

1. Define essential terminology used in cloud, serverless and microservices computing.
2. Distinguish Infrastructure as a Service, Platform as a Service, Software as a Service, Function as a Service and Backend as a Service.
3. Explain the execution model, advantages and constraints of Function as a Service.
4. Describe Backend as a Service and its role in application development.
5. Identify the characteristics, benefits and risks of microservice architecture.
6. Compare serverless and microservice approaches with monolithic systems, service-oriented architecture and traditional hosting.
7. Select an appropriate architectural approach for a practical application.
8. Recognise security, governance, operational and ethical concerns in cloud-native systems.

Essential Terminology

A cloud provider operates shared computing infrastructure and exposes resources through management consoles, APIs and software development kits. A tenant is a customer or organisational user of those resources. Provisioning is the allocation and configuration of computing resources. Deployment is the process of making software available in a target environment.

Elasticity is the ability to increase or decrease resources in response to demand. Scalability is the ability of a system to handle increasing workload by adding resources or improving capacity. Elasticity is commonly associated with automatic, demand-responsive scaling, whereas scalability is the broader engineering property.

Statelessness means that a service does not depend on memory retained in a particular running instance between requests. State is instead stored in a database, object store, cache or client token. Stateless designs are easier to replicate, replace and scale, although stateful services remain necessary in many systems.

An API, or application programming interface, defines how software components communicate. An event is a recorded occurrence that can trigger processing, such as an uploaded file, payment confirmation or message entering a queue. Observability is the ability to understand system behaviour through logs, metrics and traces. Cold start is the delay that may occur when a platform creates or initialises an execution environment before processing a request.

Cloud Service Models

Cloud service models describe the division of operational responsibility between the provider and the customer. The models are conceptual categories rather than rigid product boundaries.

The customer’s responsibility never disappears completely. Identity management, data classification, secure configuration, application vulnerabilities and regulatory compliance often remain customer responsibilities under a shared-responsibility model. The precise boundary varies by provider and service.

Traditional Hosting and IaaS

In traditional hosting, an organisation buys or leases servers and is responsible for hardware, networking, operating systems, middleware, applications and data. IaaS reduces hardware responsibility but usually leaves the customer responsible for virtual machines, operating-system updates, capacity planning and much security configuration. This model provides substantial control and is useful when applications require specialised operating systems, persistent processes or predictable network behaviour.

PaaS and SaaS

PaaS provides a managed application environment. Developers deploy code without administering every server component. PaaS can improve productivity, but the application must generally conform to the platform’s supported runtimes and operational model. SaaS is a complete product consumed by users, such as a hosted customer relationship management system. SaaS customers configure and use the product rather than deploy its internal code.

Serverless Computing

Serverless computing is a cloud execution and service-consumption model in which the provider abstracts much of the infrastructure and charges, directly or indirectly, according to use. Its central characteristics commonly include:

• provider-managed infrastructure;
• automatic or platform-controlled scaling;
• event-driven or request-driven execution;
• reduced operational administration;
• fine-grained deployment units; and
• consumption-based pricing for many services.

Serverless is not simply “using the cloud” and does not guarantee low cost. It shifts engineering attention from server administration to application design, identity, event flow, data management, observability and provider constraints.

Function as a Service

Function as a Service executes small units of code in response to events or requests. A function normally has an input, performs a bounded operation and produces an output or side effect. Triggers may include an HTTP request, a message, a scheduled time, a database change or an object uploaded to storage.

A simplified invocation flow is:

1. A trigger produces an event.
2. The platform authenticates and routes the event.
3. An execution environment is selected or created.
4. The function code runs with configured permissions.
5. The result, log records and downstream events are produced.
6. The environment may be retained temporarily or discarded.

Functions should normally be designed to be idempotent: processing the same event more than once should not create an incorrect result. This is important because distributed systems may retry delivery when a timeout or network failure makes the outcome uncertain.

FaaS platforms commonly impose limits on execution duration, memory, temporary storage, package size, concurrency, network access and supported runtimes. These restrictions encourage focused functions but make long-running, highly stateful or specialised workloads less suitable.

FaaS Cost Reasoning

Many FaaS pricing models combine an invocation charge with a charge related to execution duration and allocated memory. A simplified estimate can be expressed as:

where C_total is estimated execution cost, C_requests is the request-related charge, N is the number of invocations, d is average duration, m is allocated memory or a provider-specific resource unit, and r is the price per resource-unit time. The units and pricing increments differ by provider, so this equation is a planning model rather than a universal billing formula. It excludes related charges such as network transfer, databases, queues, monitoring and storage.

For example, if a workload has 100,000 invocations, each averaging 0.2 seconds, and the provider’s resource charge is represented as 1 cost unit per invocation-second, the resource component is 100,000 × 0.2 = 20,000 cost units before request charges and other services. This calculation is useful only when the chosen resource unit and price are explicitly defined.

Strengths of FaaS

FaaS can reduce the need to maintain fleets of servers, scale rapidly for irregular workloads and support rapid experimentation. It is particularly effective for image processing, scheduled automation, data transformation, API endpoints, notification handlers and integration workflows. Small deployment units can enable independent delivery by different teams.

Constraints of FaaS

Cold starts can increase latency, especially for large packages or specialised runtimes. Execution limits make FaaS unsuitable for some long-running processes. Debugging distributed functions is more difficult than debugging one local process. Costs can become difficult to predict when invocation volume rises or when inefficient functions trigger expensive downstream services. Provider-specific APIs may create vendor lock-in. Excessive decomposition can also produce a “distributed monolith” in which many tightly coupled functions must be changed together.

Backend as a Service

Backend as a Service provides ready-made backend capabilities through APIs or software development kits. Examples include managed authentication, user profiles, push notifications, file storage, databases, hosting, analytics and synchronisation. A development team can build a mobile or web client without implementing every backend capability from the beginning.

BaaS differs from FaaS in emphasis. FaaS provides an execution mechanism for customer-defined code. BaaS provides managed backend functionality that the customer configures and consumes. A system may use both: a BaaS authentication service may protect an application, while FaaS functions process payments or react to database events.

BaaS improves development speed and can provide professionally operated infrastructure. However, teams must evaluate data location, authentication design, service availability, export mechanisms, pricing, contractual terms and portability. A BaaS product should not be treated as automatically secure; weak access rules or excessive client privileges can expose sensitive data.

Microservices Architecture

Microservices architecture structures an application as a collection of small services. Each service is responsible for a well-defined business capability and communicates with other services through explicit interfaces, commonly HTTP APIs, gRPC, messaging systems or event streams.

A useful microservice is not defined only by its number of lines of code. It is independently deployable, has a clear responsibility, owns or controls its data boundary and can evolve with limited coordination. The appropriate size depends on business boundaries, team structure, operational capability and non-functional requirements.

Important characteristics include:

• Business capability alignment: services reflect capabilities such as catalogue, billing or delivery rather than arbitrary technical layers.
• Independent deployment: a service can be released without rebuilding the entire application.
• Decentralised data ownership: each service is authoritative for its own data, while cross-service consistency is designed explicitly.
• Explicit communication: APIs and events define contracts between services.
• Failure isolation: a failure in one service should be contained where practical.
• Technology flexibility: teams may select suitable technologies, although excessive diversity increases operational burden.
• Team autonomy: ownership of code, deployment and operation is assigned to a responsible team.

Microservices introduce distributed-systems problems. Network calls can fail, messages can be delayed or duplicated, clocks differ and partial failure is normal. A design that replaces an in-process function call with a remote call must account for timeouts, retries, circuit breakers, authentication, versioning and observability.

Data and Consistency

In a monolith, multiple modules may share a transaction and database. In microservices, independent data ownership often means that a business process crosses several services. Strong global transactions may be expensive or unavailable. Systems therefore use patterns such as transactional outbox, sagas, compensating actions and eventual consistency.

Eventual consistency means that replicas or services may temporarily disagree but converge if updates are successfully propagated and no new conflicting updates occur. It is appropriate only when the business process can tolerate intermediate states. Financial settlement, safety decisions and legal records may require stronger controls.

Monoliths, SOA, Microservices and Serverless Compared

A monolith is an application delivered as one deployable unit. It may be internally modular and can be an excellent choice for a small team or early product because local calls, transactions and testing are comparatively simple. Its disadvantages appear when independent scaling, release coordination or team autonomy becomes important.

Service-Oriented Architecture (SOA) also decomposes functionality into services, but traditionally emphasises enterprise-wide reuse, formal service contracts, central governance and often an enterprise service bus. Microservices generally favour smaller autonomous teams, lightweight communication, independent deployment and decentralised governance. The boundary is not absolute: an organisation can use SOA principles with microservices, and a microservice platform may contain central governance.

Serverless concerns the operational execution and managed-service model, whereas microservices concern application decomposition. The following combinations are possible:

The choice should follow workload and organisational needs rather than fashion.

Comparative Evaluation

Applied Case: Illustrative Online Retail Order Flow

Background

Consider an illustrative online retailer experiencing seasonal demand. Its original system is a monolith hosted on virtual machines. The catalogue, customer accounts, checkout, payment coordination, stock management and notifications are deployed together.

Problem

During sales events, checkout traffic rises sharply. The whole application must be scaled even though catalogue browsing generates most requests. Releases are slow because a change to notifications requires testing and deploying the entire system. A server failure can affect unrelated functions. The operations team also spends significant time patching hosts and adjusting capacity.

Analysis

The retailer identifies business capabilities rather than immediately splitting code by technical layer. Catalogue, order management, payment coordination, inventory and notification delivery are considered separate bounded contexts. Payment and inventory require careful security and consistency controls; notification delivery can tolerate asynchronous processing.

Approach and Solution

The catalogue API is initially deployed as a conventional containerised service because it requires predictable low latency and sustained traffic. Order submission is exposed through an API service. After an order is accepted, an event is placed on a managed queue. FaaS handlers consume the event to initiate payment coordination, reserve inventory and send notifications. A database is assigned to each service according to its ownership needs. The payment provider is integrated through a secure service boundary rather than exposing payment credentials to client applications.

Because messages may be delivered more than once, handlers use an order identifier and an idempotency record. Timeouts and bounded retries are configured for external calls. Failed messages move to a dead-letter queue for investigation. Centralised logs, correlation identifiers and distributed traces allow the team to follow one order across services.

The retailer does not migrate everything at once. It first extracts notification processing, then selected order workflows, while retaining the monolith for capabilities that are not yet stable. This incremental approach reduces migration risk.

Outcome

The illustrative design allows notification processing to scale independently and prevents temporary email-provider failure from blocking the customer-facing request. It reduces host administration for event-driven components. However, the system now requires stronger observability, more sophisticated testing and explicit handling of partial failure. The migration is therefore an organisational and operational change, not merely a code restructuring exercise.

Learning Points

1. Decomposition should follow business capability and ownership.
2. Serverless components are most valuable where event boundaries and workload variability are clear.
3. Data consistency and duplicate delivery must be designed, not assumed away.
4. Incremental migration is usually safer than a complete rewrite.
5. A measurable operational benefit must justify every additional service boundary.

Security, Governance and Ethical Considerations

Cloud-native systems expand the number of identities, interfaces and data flows. Least privilege should be applied to functions, services, developers and automated pipelines. Credentials should be stored in managed secret facilities rather than source code. APIs require authentication, authorisation, input validation, rate limiting and secure transport.

Logging must avoid unnecessary personal or payment information. Data protection obligations may require purpose limitation, retention controls, deletion processes, encryption and knowledge of geographic data location. Organisations should assess whether a provider’s subcontractors, transfer arrangements and incident-notification practices satisfy applicable law and contracts.

Governance should include service ownership, architecture standards, cost budgets, dependency review, backup and recovery testing, vulnerability management and incident response. Automated deployment improves speed but can also spread a faulty configuration rapidly; staged releases, policy checks and rollback mechanisms are therefore important.

Ethically, teams should consider accessibility, availability for vulnerable users, algorithmic effects in automated decisions and the environmental cost of unnecessary computation and data transfer. A serverless architecture is not automatically sustainable: efficient code, appropriate data retention and sensible invocation patterns remain necessary.

Contemporary Developments and Best Practices

Current cloud-native practice increasingly combines serverless functions with containers, managed databases, event streaming and workflow orchestration. WebAssembly-based runtimes, serverless containers and edge execution seek to reduce startup time or move processing closer to users. AI services are also commonly integrated through APIs or event-driven pipelines, but AI introduces additional concerns involving privacy, model reliability, bias, prompt and data security, and cost control.

Recommended practices include:

• begin with business and quality requirements rather than a preferred technology;
• keep functions focused, stateless where practical and idempotent;
• design API contracts and event schemas deliberately;
• use timeouts, bounded retries and dead-letter handling;
• establish service ownership and a clear data authority;
• automate testing, security scanning and infrastructure configuration;
• measure latency, error rate, throughput, concurrency and cost;
• use correlation identifiers, structured logs, metrics and traces;
• test failure, recovery, load and dependency degradation;
• document provider-specific dependencies and exit strategies; and
• introduce microservices incrementally when the benefits exceed the coordination cost.

Chapter Summary

Serverless computing abstracts much of the infrastructure required to run software and commonly provides automatic scaling, event-driven execution and consumption-oriented operation. Function as a Service allows developers to deploy bounded code units, while Backend as a Service supplies managed capabilities such as authentication, storage and databases. Neither model removes responsibility for secure application design, data governance, observability or cost management.

Microservices decompose applications into independently deployable services aligned with business capabilities. They can improve team autonomy, scaling and release independence, but introduce distributed-systems challenges such as network failure, duplicated messages, eventual consistency and operational complexity. Monoliths remain valuable where simplicity and transactional cohesion are more important than independent scaling. SOA and microservices overlap, but SOA traditionally emphasises enterprise service reuse and central governance, while microservices emphasise autonomy and independent deployment.

The central architectural lesson is that serverless and microservices are means rather than goals. Sound design begins with requirements, workload characteristics, organisational capability, security obligations and total cost. A carefully chosen hybrid architecture is often more effective than ideological adoption of one model.

Key Terms

Cloud computing: On-demand access to computing resources and services over a network.

IaaS: A cloud model providing virtualised infrastructure while the customer manages much of the software stack.

PaaS: A managed application platform that reduces infrastructure and runtime administration.

SaaS: A complete software product delivered and operated by a provider.

Serverless computing: A model in which the provider manages infrastructure and applications consume managed execution or services.

Function as a Service: Event- or request-driven execution of provider-managed function code.

Backend as a Service: Managed backend capabilities accessed through APIs or SDKs.

Function: A bounded unit of executable application logic.

Cold start: Initialisation delay when an execution environment is created or resumed.

Statelessness: Operation without depending on local retained state between requests.

Idempotence: Property whereby repeated processing produces the same intended result as one successful processing.

Microservice: An independently deployable service organised around a focused business capability.

Monolith: An application delivered as one deployable unit.

SOA: Service-Oriented Architecture, an approach that structures enterprise functionality as communicating services.

API: A defined interface through which software components interact.

Event: A record of a significant occurrence that may trigger processing.

Eventual consistency: A consistency model in which distributed data converges after updates propagate.

Observability: The ability to infer internal system behaviour from logs, metrics and traces.

Vendor lock-in: Difficulty moving from one provider or technology to another because of dependencies.

Shared responsibility: Security and operational responsibilities divided between provider and customer.

Review Questions

Short Answer Questions

1. What is the principal distinction between serverless computing and microservices architecture?
2. Define Function as a Service and give two examples of possible triggers.
3. Why is idempotence important in event-driven systems?
4. State two differences between IaaS and PaaS.
5. What is meant by Backend as a Service?

Long Answer Questions

1. Explain the characteristics, benefits and limitations of serverless computing.
2. Discuss how microservices differ from a monolithic architecture in deployment, scaling, data management and operations.
3. Compare FaaS and BaaS, including a situation in which both may be used together.
4. Explain why microservices create distributed-systems challenges and describe suitable control mechanisms.
5. Compare traditional hosting, SOA, microservices and serverless computing, identifying when each may be appropriate.

Analytical / Application Questions

1. A university application receives highly variable traffic for admissions deadlines, but its reporting process runs continuously for several hours. Recommend an architecture for each workload and justify your decision.
2. Design an event-driven order-processing flow that remains safe when messages are delivered more than once. Identify the roles of queues, idempotency, retries and dead-letter handling.
3. An organisation wants to split a stable monolith into thirty services immediately because “microservices are more scalable.” Critically evaluate this proposal and recommend a staged decision process.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes serverless computing from microservices?

A. Serverless is an operational execution model, while microservices are primarily an architectural decomposition approach.

B. Serverless always means that an application has exactly one function.

C. Microservices can run only on physical servers.

D. Serverless eliminates the need for security and governance.

Correct Answer: A. Serverless is an operational execution model, while microservices are primarily an architectural decomposition approach.

Question 2

Which cloud service model usually leaves the customer responsible for the operating system of a virtual machine?

A. Software as a Service

B. Infrastructure as a Service

C. Backend as a Service

D. Function as a Service

Correct Answer: B. Infrastructure as a Service

Question 3

Why should an event-processing function commonly be idempotent?

A. To ensure that repeated delivery does not produce an incorrect additional effect.

B. To guarantee that every function runs without a network connection.

C. To prevent the provider from creating execution environments.

D. To make all database transactions globally synchronous.

Correct Answer: A. To ensure that repeated delivery does not produce an incorrect additional effect.

Question 4

Which is a typical FaaS trigger?

A. A physical keyboard attached to a developer workstation

B. An object uploaded to cloud storage

C. A manually patched operating-system kernel only

D. A permanent process running without an event or request

Correct Answer: B. An object uploaded to cloud storage

Question 5

What does Backend as a Service primarily provide?

A. Ready-made backend capabilities accessed through APIs or SDKs

B. Only physical data-centre construction services

C. A requirement that customers manage all database servers

D. A replacement for every client-side application

Correct Answer: A. Ready-made backend capabilities accessed through APIs or SDKs

Question 6

Which characteristic is most closely associated with a well-designed microservice?

A. It must share all tables with every other service.

B. It is independently deployable and aligned with a focused business capability.

C. It must contain the entire organisation’s business logic.

D. It cannot communicate through events.

Correct Answer: B. It is independently deployable and aligned with a focused business capability.

Question 7

Which problem is especially associated with excessive decomposition into microservices?

A. The disappearance of all network failures

B. A distributed monolith with tightly coupled services

C. Guaranteed elimination of operational work

D. Inability to use APIs

Correct Answer: B. A distributed monolith with tightly coupled services

Question 8

A cold start is best described as:

A. The delay caused when a platform creates or initialises an execution environment.

B. The permanent deletion of a function after one invocation.

C. The encryption of data before storage.

D. The process of converting a monolith into a database.

Correct Answer: A. The delay caused when a platform creates or initialises an execution environment.

Question 9

Which practice best supports diagnosis across several microservices?

A. Removing all logs to reduce storage costs

B. Using correlation identifiers, structured logs, metrics and traces

C. Allowing every service to use unrestricted administrator privileges

D. Disabling timeouts on external calls

Correct Answer: B. Using correlation identifiers, structured logs, metrics and traces

Question 10

In the illustrative retail case, why were queues useful?

A. They made payment credentials public to all clients.

B. They decoupled asynchronous processing and helped absorb temporary demand or dependency failure.

C. They guaranteed that every message could be processed only once without application design.

D. They removed the need for monitoring and recovery procedures.

Correct Answer: B. They decoupled asynchronous processing and helped absorb temporary demand or dependency failure.