Chapter 12: Cloud and services
The chapter introduction frames cloud computing, cloud-native computing, serverless computing, and microservices as popular but vaguely defined ideas, and sets out the chapter’s approach to clarifying them.
After this chapter you will be able to
- Four concepts to clarify. State that the chapter presents mental models for cloud computing, cloud-native computing, serverless computing, and microservices because these widely used terms can have unclear meanings.
- Static and dynamic system topology. Distinguish older systems built from limited, long-lived resources with stable identities and addresses from newer systems built from short-lived resources whose properties, especially network addresses, change. Explain why engineers move from predicting load and failures in advance to observing them and responding reactively.
- On-demand resource elasticity. Explain elasticity as a system's ability to acquire and release resources on demand to meet demand, achieving scalability and reliability. Describe how automated, quick provisioning replaces slow manual requests and maintenance of long-lived machines.
- Cloud resource roles and lifecycle. Explain that a cloud platform provides resources to consumers, who can acquire and release compute or storage resources on demand as their needs change.
- Cloud-native defining qualities. Distinguish an application that merely runs on a cloud platform from one designed to be scalable and reliable by construction through on-demand acquisition and release of resources. Explain that these qualities must be assured by the design, not merely listed as requirements.
- Application-level cloud-native design. Explain why cloud tools alone do not make an existing application scalable and reliable: its design must also handle load and failures. Apply this distinction to the vanilla WordPress example and to lift-and-shift migrations with few application changes.
- Resources and requests model. Describe the minimal model used to discuss serverless computing: a system has computational, network, and storage resources and handles application events called requests. State that the discussion defines serverless computing in terms of cloud computing and cloud primitives.
- Resource and event actions. State the four actions a system must be able to perform: acquire resources, release resources, receive events, and process events. Explain that an event cannot be processed until its required resources have been acquired.
- Event-driven resource acquisition. Explain that a serverless system may acquire resources on demand after an application event enters the system, and must determine the necessary resources from that event.
- Cold and hot event paths. Distinguish the cold path, where resource acquisition occurs between receiving and processing an event, from the hot path, where it does not. Explain that serverless environments may hold acquired resources for a time after an event in anticipation of another event.
- Ambiguous service boundaries. Describe how a simple diagram of services and interactions grows harder to interpret when service rectangles are duplicated and load balancers, autoscalers, databases, queues, and timers are added. State the boundary questions this raises without treating the questions as already answered.
- Service as interaction contract. Explain why, from C1’s local view, a service is a contract governing interaction with the rest of the system, not a particular component or the components implementing it. Illustrate this with the echo service’s HTTP POST and returned request body.
- Stable recommendation service contract. Explain that Get accepts one movie ID and returns a list of movie IDs, and that this contract stays the same even as the components implementing the service change.
- Redundancy and backup recommendations. Describe why the initial single-process, database-backed implementation is not scalable or reliable, and how duplicated processes plus primary and backup groups address load and database failure.
- Smart routing and autoscaling. Explain how a smart load balancer distributes requests between unequal process groups, normally trying a primary process and potentially retrying a backup after an error, while both groups autoscale to mitigate load and failure.
- Shared and accurate mental models. Explain how effective collaboration depends on mental models overlapping both with reality and with one another, and why shallow or differing interpretations of familiar technology terms cause misunderstandings.
What it builds on
- Scalability and reliability (chapter 1) · Introduces scalability and reliability as system concerns.
- Failure mitigation (chapter 3) · Mitigating failures rather than merely detecting them.
- Thinking in partitions (chapter 7) · Thinking about scalability through partitioning.
- Redundancy (chapter 8) · Using redundancy to support reliability.
- Global view vs. local view (chapter 1) · The earlier introduction to global view versus local view.
- Correct mental models (chapter 1) · The importance of mental models matching reality
- Mental models: The foundation of reasoning (chapter 1) · Mental models as a foundation for reasoning
Section by section
Introduction
The chapter introduction frames cloud computing, cloud-native computing, serverless computing, and microservices as popular but vaguely defined ideas, and sets out the chapter’s approach to clarifying them.
- Four concepts to clarify: State that the chapter presents mental models for cloud computing, cloud-native computing, serverless computing, and microservices because these widely used terms can have unclear meanings.
Why it matters: This framing explains why the chapter examines familiar terms rather than assuming everyone means the same thing by them. - Scope of the definitions: Explain that the chapter aims for accurate, concise descriptions consistent with current industry understanding, without claiming that its definitions are industry standards.
Why it matters: The distinction helps you use the chapter’s definitions as clear mental models without treating them as official standards.
Key terms: cloud computing, cloud-native computing, serverless computing, microservices, mental models, accurate and concise definitions, current industry understanding, industry standards
12.1 From proactive to reactive
The section explains how on-demand resources made systems elastic and shifted system design from proactive planning around static resources to reactive adaptation in dynamic environments.
- Static and dynamic system topology: Distinguish older systems built from limited, long-lived resources with stable identities and addresses from newer systems built from short-lived resources whose properties, especially network addresses, change. Explain why engineers move from predicting load and failures in advance to observing them and responding reactively.
Why it matters: This shift explains why cloud systems must adapt as their resources come and go. - On-demand resource elasticity: Explain elasticity as a system's ability to acquire and release resources on demand to meet demand, achieving scalability and reliability. Describe how automated, quick provisioning replaces slow manual requests and maintenance of long-lived machines.
Why it matters: Elasticity connects changing resource allocation to the system goals of scalability and reliability.
Key terms: static topology, dynamic topology, proactive, reactive, self-regulate, elasticity, scalability, reliability, resource allocation
12.2 Cloud computing
Cloud computing separates resource consumers from providers and lets consumers acquire and release resources on demand.
- Cloud resource roles and lifecycle: Explain that a cloud platform provides resources to consumers, who can acquire and release compute or storage resources on demand as their needs change.
Why it matters: This separation and on-demand lifecycle are the section’s core primitives for defining cloud-native and serverless computing. - Public and private cloud scope: Distinguish public from private cloud platforms by whether they offer resources outside their own organization or only within it.
Why it matters: The distinction shows that cloud computing’s core model does not require a publicly available provider.
Key terms: resource consumer, resource provider, cloud platform, on demand, compute resources, storage resources, public cloud platform, private cloud platform
12.3 Cloud-native computing
This section distinguishes cloud-hosted applications from cloud-native applications and explains why scalability and reliability require application design as well as cloud-platform tools.
- Cloud-native defining qualities: Distinguish an application that merely runs on a cloud platform from one designed to be scalable and reliable by construction through on-demand acquisition and release of resources. Explain that these qualities must be assured by the design, not merely listed as requirements.
Why it matters: Hosting an application in the cloud does not, by itself, give it cloud-native behavior. - Cloud resource management roles: Describe how supervisors replace resources believed to have failed, scalers acquire or release resources as demand changes, and load balancers distribute requests among available resources.
Why it matters: These distinct tools help explain how a cloud platform supports reliability and scalability. - Application-level cloud-native design: Explain why cloud tools alone do not make an existing application scalable and reliable: its design must also handle load and failures. Apply this distinction to the vanilla WordPress example and to lift-and-shift migrations with few application changes.
Why it matters: It prevents a move to cloud hosting from being mistaken for a redesign that takes advantage of cloud elasticity. - Technology choices versus definition: Distinguish the section's definition of cloud-native from common descriptions based on containers, microservices, and dynamic orchestration. Explain that those are frequent technology or architectural choices, not necessary conditions for scalability and reliability by construction.
Why it matters: It keeps the focus on what an application achieves rather than on a prescribed technology stack.
Key terms: cloud application, cloud-native application, by construction, by requirement, supervisor, scaler, load balancer, K8s Deployment, K8s HorizontalPodAutoscaler, K8s Service
12.4 Serverless computing
This section introduces a minimal model of resources, requests, and actions for reasoning about serverless computing.
- Resources and requests model: Describe the minimal model used to discuss serverless computing: a system has computational, network, and storage resources and handles application events called requests. State that the discussion defines serverless computing in terms of cloud computing and cloud primitives.
Why it matters: This model gives you a common way to compare traditional and serverless computing. - Resource and event actions: State the four actions a system must be able to perform: acquire resources, release resources, receive events, and process events. Explain that an event cannot be processed until its required resources have been acquired.
Why it matters: The distinction between obtaining resources and processing a request underlies the comparisons that follow.
Key terms: minimal model of computation, resources, application events, requests, cloud primitives, acquire, release, receive events, process events, universal constraint
12.4.1 Traditional
12.4.2 Serverless
Serverless computing can acquire resources after an application event arrives, so it must determine what resources are needed from that event.
- Event-driven resource acquisition: Explain that a serverless system may acquire resources on demand after an application event enters the system, and must determine the necessary resources from that event.
Why it matters: The event determines both when resources may be acquired and which resources the system needs.
Key terms: serverless computing, application event, resources on demand
12.4.3 Cold path vs. hot path
This subsection distinguishes cold and hot paths in serverless event processing by whether resources must be acquired after an event arrives.
- Cold and hot event paths: Distinguish the cold path, where resource acquisition occurs between receiving and processing an event, from the hot path, where it does not. Explain that serverless environments may hold acquired resources for a time after an event in anticipation of another event.
Why it matters: The distinction explains why successive events may take different paths through the same serverless environment.
Key terms: cold path, hot path, resources, application event
12.5 Service
The section introduces the need for a clearer model of a service by showing how service boundaries become ambiguous in architecture diagrams.
- Service terminology and purpose: Explain why the author uses the term service instead of microservice: the latter is popular but has a fuzzy meaning and often provokes debate about what makes a good architecture.
Why it matters: This keeps the discussion focused on what constitutes a service rather than on whether an architecture is good. - Ambiguous service boundaries: Describe how a simple diagram of services and interactions grows harder to interpret when service rectangles are duplicated and load balancers, autoscalers, databases, queues, and timers are added. State the boundary questions this raises without treating the questions as already answered.
Why it matters: A diagram cannot clarify a service-based system until it is clear what counts as a service and what falls within its boundary.
Key terms: microservice, service, microservices-based architecture, service boundaries, autonomous service, load balancer, autoscalar
12.5.1 Global view vs. local view
This section contrasts global and local views of a system and explains why, from a component’s local view, a service is an interaction contract rather than a set of components.
- Global and local visibility: Distinguish the all-knowing observer’s global view of the entire system from a component’s local view of only its own state and its own channel to the network.
Why it matters: A component’s limited view changes how we describe what it interacts with. - Service as interaction contract: Explain why, from C1’s local view, a service is a contract governing interaction with the rest of the system, not a particular component or the components implementing it. Illustrate this with the echo service’s HTTP POST and returned request body.
Why it matters: Thinking of a service as a contract keeps its promised behavior separate from its physical implementation.
Key terms: global view, local view, component, channel to the network, service, contract, rest of the system, logical view, physical point of view, echo service
12.5.2 Example recommendation service
A movie-recommendation example shows how a service can keep a simple, stable contract while its implementation grows into a changing collection of components.
- Stable recommendation service contract: Explain that Get accepts one movie ID and returns a list of movie IDs, and that this contract stays the same even as the components implementing the service change.
Why it matters: A consumer can use the service without knowing how its recommendations are produced. - Redundancy and backup recommendations: Describe why the initial single-process, database-backed implementation is not scalable or reliable, and how duplicated processes plus primary and backup groups address load and database failure.
Why it matters: The example separates an implementation that works functionally from one that can better withstand load and failure. - Smart routing and autoscaling: Explain how a smart load balancer distributes requests between unequal process groups, normally trying a primary process and potentially retrying a backup after an error, while both groups autoscale to mitigate load and failure.
Why it matters: Routing and scaling let the two process groups work together rather than merely coexist. - Redundant shared infrastructure: Describe why load balancers and autoscalers are also made redundant, and why the final model does not imply a one-to-one mapping between components and services.
Why it matters: The visible service need not correspond to a fixed, self-contained set of infrastructure components.
Key terms: Get, ID -> [ID], contract, redundancy, primary, backup, dynamic (real) recommendations, static (fake) recommendations, smart load balancer, autoscaling
12.6 Final thoughts
The section argues that deep, shared, accurate mental models make engineers more effective collaborators and communicators.
- Shared and accurate mental models: Explain how effective collaboration depends on mental models overlapping both with reality and with one another, and why shallow or differing interpretations of familiar technology terms cause misunderstandings.
Why it matters: A shared term helps a team only when people mean roughly the same thing by it—and that meaning fits reality. - Depth of conceptual understanding: Justify the section's advice to keep exploring the core of a concept rather than settling for a shallow familiarity with its name.
Why it matters: Understanding a concept deeply can improve both engineering decisions and the ability to explain them.
Key terms: mental model, reality, cloud, cloud-native, serverless, microservices, core of a concept
12.7 Summary
The chapter summary connects elastic cloud computing, proactive versus reactive resource acquisition, and services as stable logical contracts.
Concepts explained in this chapter
- scalabilityScalability is the ability of a system to maintain its intended behavior as demand or workload increases.
- mental modelAn internal representation of a target system that forms the basis for comprehension, communication, and reasoning.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.