Cloud-Native, Serverless, and Microservices Foundations

Introduction

Digital transformation has changed how organisations design, deliver, and operate software. Earlier enterprise systems were commonly installed on owned servers and released as large, infrequent packages. Modern organisations increasingly use cloud platforms, automated delivery pipelines, containers, managed services, and event-driven architectures. These approaches enable faster experimentation, elastic capacity, and access to sophisticated infrastructure without requiring an organisation to own every physical resource.

Three ideas are especially important in this transformation. Cloud-native computing describes an approach to building and operating applications that exploit cloud capabilities such as automation, elasticity, managed infrastructure, and distributed operation. Microservices is an architectural style in which an application is divided into independently developed and deployable services. Serverless computing is a cloud execution model in which the provider manages the servers and much of the operational capacity, while the customer concentrates on application code, events, and data.

These concepts are related but not identical. A microservice can run on a virtual machine, container platform, or serverless platform. A serverless application may consist of functions, managed databases, queues, and APIs without using microservices in a strict sense. Cloud-native design is the broader mindset that may include both.

Learning Objectives

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

1. Explain the principal cloud service and deployment models.
2. Describe cloud-native principles and their relationship to digital transformation.
3. Compare monolithic, service-oriented, and microservices architectures.
4. Explain containers and their role in application portability.
5. Distinguish serverless computing, Function as a Service, and Backend as a Service.
6. Select an appropriate architectural approach for a practical business problem.
7. Identify operational, security, financial, governance, and ethical implications.

Cloud Computing as an Operating Model

Cloud computing provides on-demand access to configurable computing resources, including networks, servers, storage, databases, and application services. Resources can generally be provisioned and released rapidly, with limited direct management of physical infrastructure by the customer. Cloud computing is therefore more than renting a server: it changes how capacity is acquired, software is operated, and costs are managed.

Cloud service models

The three traditional service models are Infrastructure as a Service, Platform as a Service, and Software as a Service.

Infrastructure as a Service (IaaS) provides virtual machines, networks, and storage. It offers control and compatibility, but the customer remains responsible for operating-system updates, configuration, security hardening, and often capacity planning.

Platform as a Service (PaaS) provides a managed environment for deploying applications. The provider may manage the operating system, runtime patches, load balancing, and scaling. PaaS reduces operational work but may impose limitations on supported languages, versions, networking, or deployment patterns.

Software as a Service (SaaS) delivers a complete application through a browser or API. The provider manages the application and infrastructure. Customers configure the service and manage organisational policies, identities, and the correctness of data they enter.

A related model is Backend as a Service (BaaS). BaaS supplies reusable backend capabilities such as authentication, object storage, databases, messaging, push notifications, and application programming interfaces. It is particularly useful for small teams and mobile or web applications. However, heavy reliance on a BaaS provider can create portability, pricing, and data-governance concerns.

Deployment models

A public cloud is operated by a provider for multiple customers. A private cloud is dedicated to one organisation, although it may be operated internally or by a third party. A hybrid cloud combines private and public environments, often to meet regulatory, latency, or legacy-system requirements. A multi-cloud strategy uses services from more than one public provider. Multi-cloud may reduce dependence on one provider, but it also increases integration, skills, monitoring, and governance complexity.

Cloud adoption does not automatically produce good architecture. An organisation can reproduce a poorly designed data centre application in the cloud and receive little benefit. Cloud value arises when technology, processes, security, and operating practices are redesigned appropriately.

Cloud-Native Principles

Cloud-native applications are designed to use the capabilities and constraints of distributed cloud environments. The term is not a synonym for “hosted in the cloud.” A cloud-native application normally emphasises automation, independent change, resilience, observability, and elastic use of resources.

Key principles

Automation and infrastructure as code. Infrastructure, policies, networks, and deployment environments should be defined in version-controlled files where practical. Automation improves repeatability and reduces configuration drift.

Loose coupling. Components should communicate through explicit contracts and should not depend unnecessarily on another component’s internal implementation. Loose coupling allows parts of a system to evolve independently.

Elasticity. Capacity should increase or decrease in response to demand. Elasticity is distinct from scalability: scalability is the ability to handle greater load, while elasticity emphasises adjusting resources as load changes.

Resilience. Cloud-native systems assume that networks, instances, zones, and dependencies may fail. Techniques include timeouts, retries with limits, circuit breakers, health checks, replication, graceful degradation, and disaster recovery procedures.

Observability. Operators need evidence about system behaviour. Logs record events, metrics measure numerical conditions, and traces show a request’s path across components. Monitoring reports known conditions; observability helps investigate unknown conditions.

Continuous delivery. Small, automated, tested changes are released frequently. Source control, automated testing, security checks, infrastructure automation, and controlled deployment strategies support this practice.

Statelessness where appropriate. If a service does not retain user session state locally, instances can be replaced or scaled more easily. Persistent state must be stored in an appropriate shared data service.

Security by design. Identity, least privilege, encryption, secrets management, dependency scanning, audit logging, and secure defaults should be designed into the delivery lifecycle rather than added at the end.

Cloud-native principles often support organisational transformation. Teams may own a product or service through its lifecycle, allowing developers and operations specialists to collaborate. This does not eliminate the need for architecture, governance, or specialist security expertise; it changes how responsibility is distributed.

From Monoliths to Distributed Architectures

A monolithic application is deployed as a single unit. It may contain presentation, business logic, and data-access functions in one codebase and process. Monoliths are not inherently poor designs. A well-structured monolith can be simple to test, easy to deploy, and efficient for a small product.

Problems arise when a monolith becomes large and tightly coupled. A minor change may require rebuilding and redeploying the whole system. Different parts may require different scaling levels, but the whole application must be scaled together. Teams may interfere with one another, and a failure in one area may affect the complete application.

A monolith may be modular even when deployed as one unit. This is often called a modular monolith. Clear internal boundaries can provide many benefits of decomposition while avoiding the operational complexity of distributed systems. Decomposition should therefore be driven by business and technical needs, not by fashion.

Service-oriented architecture

Service-oriented architecture (SOA) structures capabilities as services that communicate through defined interfaces. Services may be relatively coarse-grained and are often designed for reuse across multiple applications. SOA commonly includes enterprise integration patterns, central governance, service registries, message brokers, and formal contracts.

SOA was influential in addressing problems of application integration and reuse. However, implementations sometimes became dependent on central enterprise service buses, large XML contracts, and heavy governance. These are not essential characteristics of SOA, but they illustrate how an architectural idea can become operationally burdensome.

Microservices architecture

Microservices architecture structures an application as a set of small, autonomous services. Each service typically represents a business capability, owns its implementation, and can be deployed independently. Services communicate through lightweight APIs or messaging. A service should have a clear responsibility and should minimise knowledge of other services’ internals.

Microservices are not simply small programs. The essential characteristics are autonomy, bounded responsibility, independent deployment, and alignment with business capabilities. A system made of many tiny but tightly coupled services is distributed monolith, not a successful microservices architecture.

Bounded contexts and data ownership

A useful method for identifying service boundaries is to examine business capabilities and bounded contexts. A bounded context is a boundary within which terms, rules, and models have a particular meaning. For example, “customer” may mean an individual with contact details in a marketing context, but an account holder with credit history in a billing context.

A microservice should generally own the data needed to enforce its business rules. Other services access that capability through an API or event rather than directly querying its tables. This reduces coupling but introduces challenges such as data duplication, eventual consistency, and more complex transactions.

A transaction that crosses several services cannot always use one simple database transaction. Teams may use an orchestration or choreography pattern, compensating actions, and explicit business states. For example, if payment succeeds but shipment creation fails, the system may issue a refund or place the order in a review state. The correct solution depends on business consequences and regulatory requirements.

Containers and Orchestration

A container packages an application and its dependencies into an isolated user-space environment while sharing the host operating system kernel. A container image is an immutable package from which containers are created. Containers are generally lighter and faster to start than full virtual machines because virtual machines include separate guest operating systems.

Containers improve consistency between development, testing, and production. They also provide a useful packaging boundary for microservices. Nevertheless, containers are not a complete security boundary in every situation, and they do not remove the need to patch hosts, images, libraries, and application code.

An image should be built from a trusted and minimal base, scanned for vulnerabilities, versioned immutably, and promoted through controlled environments. Secrets should not be embedded in images. Runtime permissions should follow least privilege.

Container orchestration platforms schedule containers, restart failed instances, expose services, manage configuration, and support rolling deployment. They may also provide service discovery, autoscaling, and policy controls. Orchestration is powerful but introduces a substantial operational surface: clusters, networking, ingress, identity, observability, storage, upgrades, and security policies all require expertise.

Serverless Computing

Serverless computing is a cloud model in which the provider manages server provisioning, capacity allocation, much of the operating environment, and often scaling. The term does not mean that servers do not exist. It means that developers do not normally manage those servers directly.

Serverless applications commonly use two categories of service:

• Function as a Service (FaaS): customers deploy small units of code that execute in response to events or requests.
• Backend as a Service (BaaS): customers consume managed backend capabilities such as databases, authentication, storage, queues, and notifications.

A serverless solution may combine FaaS and BaaS. For example, an image-upload event may invoke a function that validates the file, stores metadata in a managed database, and publishes a message for a thumbnail service.

Function as a Service

A FaaS function usually has a defined handler, input event, output or side effect, resource limit, and execution timeout. The provider starts an execution environment when required, may reuse it for later invocations, and may create multiple environments during periods of high demand.

Developers should assume that functions are stateless between invocations. Temporary local storage may be available during one execution environment’s lifetime, but it should not be treated as durable shared storage. Long-running work should normally be placed in a queue or workflow rather than hidden inside a request function.

A function may experience a cold start, in which the platform must initialise a new execution environment. Warm execution may be faster, but applications should not depend on warm state for correctness. Functions should be small enough to understand, but not fragmented so aggressively that every simple operation becomes a network call.

Event-driven design

In an event-driven architecture, a producer emits an event describing something that has happened, such as OrderPlaced or PaymentConfirmed. Consumers react independently. This reduces direct coupling and can support asynchronous processing.

Events should have clear schemas, versioning rules, identifiers, timestamps, and ownership. Systems must consider duplicate delivery, ordering, retries, poison messages, and dead-letter handling. A consumer should often be idempotent: processing the same event more than once should not produce an incorrect additional effect.

Serverless advantages and limitations

Serverless is especially suitable for irregular workloads, APIs with variable traffic, scheduled jobs, event processing, automation, and rapid prototypes. It may be less suitable for applications requiring long-running processes, specialised operating-system control, stable low-latency performance, or highly predictable costs at sustained high utilisation.

Choosing an Architectural Approach

Architecture should follow requirements. The following questions support a reasoned decision:

1. How complex is the domain, and are business boundaries understood?
2. Does the workload vary significantly over time?
3. Are independent releases required by multiple teams?
4. What latency, throughput, availability, and data-residency requirements apply?
5. Is the organisation able to operate distributed systems?
6. Which services require specialised runtimes or hardware?
7. What degree of provider dependence is acceptable?
8. How will identity, audit, privacy, backup, and disaster recovery be managed?

A modular monolith is often a strong starting point for a new product with one team and uncertain boundaries. Containers may be appropriate when teams need runtime control and portability. Microservices are justified when independent scaling, deployment, or team ownership provides measurable value. FaaS is attractive for event-driven or intermittent workloads. BaaS can accelerate delivery but should be evaluated against data portability and long-term cost.

A simple cost model

Cloud cost analysis should include more than invocation price. A useful conceptual model is:

The terms represent monetary costs over a chosen period. Compute cost may depend on execution duration, allocated memory, or provisioned capacity; storage cost may depend on stored volume and requests; data transfer cost may depend on traffic direction and destination. The model is not a provider-specific pricing formula and must be replaced by the selected provider’s current pricing rules.

For example, suppose a function performs 2,000,000 invocations in a month, each lasting 0.2 seconds, with 512 MB allocated memory. The total execution time is:

This calculation describes workload volume only. Actual cost also depends on the provider’s free tier, billing granularity, request charges, architecture, region, and related services. It is therefore unsafe to conclude a price without current pricing data.

Applied Case: Illustrative Online Retail Platform

Background

A fictional retailer operates an online store with a product catalogue, shopping cart, payment processing, order fulfilment, and customer notifications. The original application is a single deployable unit backed by one relational database.

Problem

During seasonal campaigns, catalogue browsing increases sharply while payment traffic rises more moderately. A change to product search requires a full application release. A failure in notification processing delays unrelated order operations. The organisation wants faster releases and elastic handling of traffic but has limited cloud-operating experience.

Analysis

The team first maps business capabilities and identifies catalogue, cart, order, payment, fulfilment, and notification responsibilities. It discovers that the existing database contains shared tables and that business terms are inconsistent. Immediate decomposition would create network calls without clear boundaries and could increase failure modes.

Approach and solution

The team adopts a staged strategy:

1. Refactor the existing application into well-defined internal modules.
2. Establish automated testing, source control policies, deployment automation, and central observability.
3. Move static product images to object storage and place a content delivery service in front of them.
4. Extract notification processing as an asynchronous service using a queue and a serverless function. Failed messages are sent to a dead-letter queue.
5. Extract catalogue search only after defining its ownership and synchronisation events.
6. Keep payment processing in a carefully controlled service with strong audit records and explicit reconciliation procedures.
7. Use containers for services requiring stable runtime control and managed services where operational benefits outweigh portability concerns.

The notification function is designed to tolerate duplicate events by using an event identifier. It does not assume that events arrive in order. Payment data is minimised, access is restricted, and sensitive information is not written to ordinary logs.

Outcome

The retailer can deploy notification changes independently and scale asynchronous processing during campaigns. Catalogue traffic is handled separately from payment traffic. The team avoids converting every module into a service, reducing unnecessary operational complexity. The case demonstrates that cloud-native transformation is an incremental engineering programme rather than a single migration exercise.

Learning points

• Architectural boundaries should reflect business responsibilities.
• A queue can isolate slow or failing work from the user request path.
• Serverless functions require idempotency, observability, and failure handling.
• A modular monolith may be a deliberate and valuable intermediate state.
• Security and data governance must be designed alongside decomposition.

Professional, Ethical, and Governance Considerations

Cloud architectures create shared responsibility. Providers secure facilities and many managed components, while customers remain responsible for identity configuration, data classification, application vulnerabilities, permissions, and appropriate use of services. The exact division varies by service model.

Privacy laws and sector regulations may govern personal, financial, health, or educational data. Architects should identify where data is stored and processed, how long it is retained, who can access it, and how it can be deleted. Logs and traces can accidentally contain personal information or credentials and therefore require classification and protection.

Vendor lock-in is not automatically unethical or unacceptable. Managed services can provide substantial productivity and reliability benefits. However, organisations should understand exit costs, portability limits, proprietary data formats, and contractual commitments. Critical services may require documented recovery procedures and tested alternatives.

AI-enabled development tools can accelerate code generation, testing, and operational analysis. They can also introduce insecure code, licensing uncertainty, data leakage, and unverified assumptions. Generated code must undergo review, testing, security scanning, and appropriate human approval. AI should support professional judgement rather than replace accountability.

Contemporary Developments and Best Practices

Current cloud-native practice increasingly includes platform engineering, internal developer platforms, policy as code, software supply-chain security, confidential computing, and event-driven integration. Organisations are also adopting workload portability standards and hybrid approaches where regulatory or latency requirements demand them.

Recommended practices include:

• Begin with explicit business and quality requirements.
• Prefer the simplest architecture that meets those requirements.
• Define service ownership, interfaces, schemas, and failure behaviour.
• Automate testing, deployment, infrastructure, and security checks.
• Apply least privilege and rotate secrets.
• Instrument logs, metrics, and traces before production release.
• Test backups, restoration, failover, and disaster recovery.
• Use budgets, alerts, tagging, and usage reviews for cost governance.
• Design for duplicate messages, timeouts, retries, and partial failure.
• Document provider dependencies and operational responsibilities.

Challenges and Limitations

Distributed architectures replace some forms of complexity with others. Network calls are slower and less reliable than in-process calls. Debugging requires correlation identifiers and distributed traces. Data consistency may become eventual rather than immediate. More services create more deployments, permissions, dashboards, alerts, and potential attack surfaces.

Serverless platforms reduce infrastructure administration but may constrain execution time, runtime choice, networking, and observability. Automatic scaling can amplify an upstream failure or unexpectedly increase cost. Containers improve packaging but do not remove operational responsibility. Microservices can improve team autonomy but may fail when boundaries are poorly chosen or when an organisation lacks testing and platform capability.

The central professional lesson is that no architecture is universally superior. Sound design balances simplicity, changeability, resilience, security, cost, performance, and organisational capability.

Chapter Summary

Cloud computing provides managed access to computing resources through models ranging from IaaS to SaaS. PaaS, BaaS, and FaaS shift increasing operational responsibility to the provider, although customers retain responsibility for appropriate configuration, data, identity, and application behaviour. Cloud-native computing is a design and operating approach based on automation, elasticity, resilience, observability, loose coupling, continuous delivery, and security by design.

Monoliths can be effective when well structured, while SOA and microservices divide capabilities into services with different degrees of granularity, autonomy, and governance. Microservices require clear boundaries, independent deployment, and disciplined data ownership. Containers provide a portable packaging mechanism, and orchestration platforms manage groups of containers but introduce operational complexity.

Serverless computing abstracts server management. FaaS executes code in response to events or requests, while BaaS supplies managed backend capabilities. Serverless systems require attention to cold starts, statelessness, retries, duplicate events, observability, quotas, vendor dependence, and cost. The appropriate architecture depends on business boundaries, workload behaviour, security, regulation, organisational capability, and total cost—not on technology fashion.

Key Terms

Cloud computing: On-demand access to configurable computing resources through a network.

IaaS: A service model providing virtualised infrastructure such as compute, storage, and networking.

PaaS: A managed application platform that reduces responsibility for operating systems and runtime infrastructure.

SaaS: A complete software application delivered and managed by a provider.

BaaS: Managed backend capabilities such as authentication, databases, storage, and messaging.

FaaS: Execution of customer-supplied functions in response to events or requests.

Cloud-native: An approach that exploits cloud capabilities through automation, elasticity, resilience, and distributed design.

Monolith: An application deployed as one primary unit.

SOA: An architecture that organises capabilities as services communicating through defined interfaces.

Microservices: An architecture of autonomous, independently deployable services aligned with business capabilities.

Bounded context: A domain boundary within which concepts and rules have a consistent meaning.

Container: A packaged application environment that shares the host operating-system kernel.

Orchestration: Automated management of containers or workloads, including scheduling and recovery.

Event-driven architecture: An architecture in which components communicate through events representing occurrences.

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

Elasticity: The ability to adjust resource capacity in response to changing demand.

Observability: The ability to understand internal system behaviour from outputs such as logs, metrics, and traces.

Vendor lock-in: Dependence on a provider that makes changing platforms difficult or costly.

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

Review Questions

5 Short Answer Questions

1. What is the main difference between IaaS and PaaS?
2. Define cloud-native computing.
3. Why should a microservice generally own its business data?
4. What is a cold start in FaaS?
5. Name the three principal forms of observability data.

5 Long Answer Questions

1. Compare monolithic, SOA, and microservices architectures, including one advantage and one limitation of each.
2. Explain how containers support cloud-native application delivery and why they do not eliminate security responsibilities.
3. Describe the relationship between FaaS and BaaS in a serverless application.
4. Explain why resilience and observability are essential in distributed systems.
5. Discuss the main factors an organisation should evaluate before adopting a multi-cloud strategy.

3 Analytical / Application Questions

1. A small team is building its first version of a booking application. Requirements are uncertain, the team has limited operations experience, and traffic is initially predictable. Recommend an initial architecture and justify your choice.
2. An event-driven payment notification is sometimes delivered twice. Analyse the risk and propose design controls that prevent an incorrect duplicate customer charge.
3. A retailer experiences highly variable image-processing demand but requires specialised libraries and long-running processing. Compare FaaS, containers, and a managed batch platform, and recommend an approach using workload, operational, and cost considerations.

Multiple Choice Questions with Answers

Question 1

Which cloud service model gives the customer the greatest responsibility for managing the operating system?

A. Software as a Service

B. Platform as a Service

C. Infrastructure as a Service

D. Backend as a Service

Correct Answer: C. Infrastructure as a Service

Question 2

Which characteristic most directly distinguishes a microservice from merely a small program?

A. It is written in a modern programming language

B. It can be independently deployed and represents a focused capability

C. It always uses a separate physical server

D. It never communicates with another service

Correct Answer: B. It can be independently deployed and represents a focused capability

Question 3

What is the primary purpose of a container image?

A. To define a business transaction

B. To package an application and its dependencies

C. To replace identity management

D. To guarantee unlimited scaling

Correct Answer: B. To package an application and its dependencies

Question 4

Which statement about serverless computing is correct?

A. Servers do not exist in serverless systems

B. Customers must manually provision every execution server

C. The provider manages much of the server infrastructure and capacity

D. Serverless applications cannot use databases

Correct Answer: C. The provider manages much of the server infrastructure and capacity

Question 5

Why should an event consumer often be idempotent?

A. To ensure duplicate delivery does not create an incorrect additional effect

B. To prevent all events from being delivered

C. To make every event arrive in alphabetical order

D. To eliminate the need for monitoring

Correct Answer: A. To ensure duplicate delivery does not create an incorrect additional effect

Question 6

Which combination is most closely associated with observability?

A. Logs, metrics, and traces

B. Images, containers, and kernels

C. Budgets, invoices, and contracts

D. Passwords, tokens, and certificates

Correct Answer: A. Logs, metrics, and traces

Question 7

Which architecture is usually the simplest starting point for one team with uncertain domain boundaries?

A. A modular monolith

B. Hundreds of independent microservices

C. A separate physical server for every function

D. A multi-cloud service mesh

Correct Answer: A. A modular monolith

Question 8

A serverless function performs 1,000 invocations, each lasting 0.5 seconds. What is the total execution time, ignoring billing granularity?

A. 50 seconds

B. 500 seconds

C. 1,000.5 seconds

D. 2,000 seconds

Correct Answer: B. 500 seconds

Question 9

What is a principal risk of allowing several microservices to directly share the same database tables?

A. It guarantees stronger service autonomy

B. It increases coupling between services

C. It eliminates consistency concerns

D. It prevents all database failures

Correct Answer: B. It increases coupling between services

Question 10

Which practice best supports secure cloud-native delivery?

A. Embedding credentials in container images

B. Disabling audit logs to reduce cost

C. Applying least privilege and automated security checks

D. Relying only on the provider for application security

Correct Answer: C. Applying least privilege and automated security checks