3.11: Detailed Captions - Chapter 3

Overview

• Chapter: 3 — Technical Foundations of the Cloud
• Total Figures Proposed: 8
• Figure Types Used: Architecture Diagram, Comparison Table, Conceptual Illustration, Flowchart, Network Diagram, Infographic

Figure 3.1.1

Title: Cloud Platform Layered Architecture

Detailed Caption: Four wide horizontal bands stack vertically, color-coded to mark increasing abstraction. The bottom navy band, "Physical Layer (Data Centers)," carries icons for Servers, Storage, and Network; above it sits a teal "Virtualization & Abstraction Layer" showing Hypervisor, VMs, and Containers; next is a medium-blue "Cloud Services & APIs" band listing Compute, Storage, Databases, ML, and Analytics with small service icons; and the top warm-gold band, "User Access Layer," shows Web Portal, CLI, and SDK touchpoints. A vertical "Increasing Abstraction" arrow runs up the left side, while a "Cloud Platform" bracket on the right groups all four bands as a single offering. The figure makes the platform's onion-like structure intuitive: every higher layer hides the messy details of the layer below it, so users only see the surface they need while the cloud provider operates everything else.

Figure 3.1.2

Title: Cloud Service Models — Responsibility Stack Comparison

Detailed Caption: Four columns labeled On-Premises, IaaS, PaaS, and SaaS each contain the same eight stacked stack-layer blocks (top to bottom: Data, Applications, Middleware/Runtime, OS, Virtualization, Servers, Storage, Networking), with each block colored navy ("Customer Managed") or teal ("Provider Managed"). The On-Premises column is fully navy, the IaaS column flips the bottom four layers to teal with a dashed gold "Responsibility Boundary" line cutting across between OS and Virtualization, the PaaS column flips the boundary higher (only Data and Applications remain navy), and the SaaS column is fully teal. A legend at the bottom decodes the navy and teal swatches plus the gold dashed boundary line. The visual makes the security-and-ops trade-off concrete: each step right shifts the boundary upward, transferring more management work to the provider while leaving the customer with progressively less to operate but also less to control.

Figure 3.2.1

Title: OpenStack Modular Architecture

Detailed Caption: A 2×3 grid of six teal service tiles forms the body of the figure — Nova (Compute), Neutron (Networking), Cinder (Block Storage), Swift (Object Storage), Glance (Image Service), and Heat (Orchestration) — each with the project name in white above its functional role. A wide warm-gold bar across the top labeled "Horizon (Dashboard)" sends arrows down to the service grid, while a tall navy column on the left labeled "Keystone (Identity & Auth)" runs the full height with arrows reaching into every service tile. Below the grid, a gray foundation bar reads "Hypervisor / Physical Infrastructure (KVM, Xen, etc.)," and dashed lines weave between services to suggest API-level integration. The placement is the lesson: Keystone authenticates every cross-service call and Horizon offers a single pane of glass over them, so the modular OpenStack stack behaves like one coherent product despite being assembled from independent projects.

Figure 3.3.1

Title: AWS VPC Architecture with Public and Private Subnets

Detailed Caption: A dashed-blue rectangle frames the entire "VPC 10.0.0.0/16," divided vertically into two equal halves labeled "Availability Zone 1 (us-east-1a)" and "Availability Zone 2 (us-east-1b)." Each half contains a light-teal "Public Subnet" (10.0.1.0/24 / 10.0.3.0/24) holding a teal Load Balancer (ALB/ELB) and a NAT Gateway with route note "Route: 0.0.0.0/0 → IGW," and a light-gray "Private Subnet" (10.0.2.0/24 / 10.0.4.0/24) holding two navy App Server (EC2) boxes with route note "Route: 0.0.0.0/0 → NAT GW." Above the VPC, a warm-gold "Internet Gateway (IGW)" sits between an "Internet — Users / Clients" cloud at the very top and the two AZs, with arrows showing the public-side ingress path and dashed teal lines showing private-side egress through the NAT Gateways. The figure crystallizes the AWS networking pattern that students otherwise have to assemble mentally: the same subnet topology mirrored across two AZs for fault tolerance, with strict separation between internet-reachable load balancers and inward-only application servers.

Figure 3.3.2

Title: Virtual Machines vs. Containers — Structural Comparison

Detailed Caption: Two parallel stacks rise from a shared dark-gray "Physical Hardware" foundation. On the left, "Virtual Machines" stacks a navy "Hypervisor" layer above the hardware, then three identical dashed-bordered VM towers (VM 1, VM 2, VM 3), each containing a teal "App + Libs" tile, a gray "Guest OS" tile, and a "Binaries" tile beneath; a tall vertical bracket on the far left signals their relative height. On the right, "Containers" stacks a navy "Host Operating System" directly on the hardware, then a single warm-gold "Container Runtime (Docker)" bar, then three smaller dashed-teal containers each holding only an "App + Libs" tile; a shorter bracket on the far right signals their compactness. Footers underneath read "Full OS per instance · Strong isolation · Larger footprint" versus "Shared OS kernel · Lightweight · Fast startup," summing up the trade. The bracketed height delta is the punchline: containers strip away the duplicated guest-OS layers, which is precisely why they boot in seconds and pack densely on a host.

Figure 3.4.1

Title: Monolithic vs. Microservices Architecture

Detailed Caption: On the left, "Monolithic Architecture" shows a single user icon piping a request into one big navy enclosure containing four tightly stacked sub-modules — User Interface, Business Logic, Data Access, and Database — labeled "Single deployable unit." On the right, "Microservices Architecture" sends the user request through a warm-gold "API Gateway" that fans out gold arrows to five separately framed teal services — User Service, Catalog Service, Payment Service, Recommendation Service, and Search Service — each paired with its own small gray "DB" cylinder; dashed inter-service connectors are tagged "REST / Messaging," and a footer reads "Independent services, independently deployable." The contrast is structural: the monolith presents one perimeter and one release artifact, while the microservice diagram exposes per-service borders, per-service data, and an API gateway that becomes the new front door — explaining why microservices scale and ship faster, but also why they need new infrastructure (gateways, service registries, network policies) the monolith never did.

Figure 3.5.1

Title: CAP Theorem — Trade-offs in Distributed Systems

Detailed Caption: Three large overlapping circles in a triangular layout — Consistency (C) at top in navy, Availability (A) at bottom-left in teal, and Partition Tolerance (P) at bottom-right in warm gold — form a classic CAP Venn diagram. Each two-way overlap is labeled with its acronym and a representative system: "CA — Traditional RDBMS (single node)" in the C∩A region, "CP — Google Cloud Spanner / HBase, MongoDB" in the C∩P region, and "AP — DynamoDB, Cassandra / CouchDB" in the A∩P region. The three-way center holds a red "no-entry" prohibition icon with the caption "Cannot achieve all three," and a footer note reads, "In the presence of network partitions, a system must choose between consistency and availability." The figure turns Brewer's theorem into a quick architectural compass — given a real cloud datastore, students can read off what it gave up to get what, and whether a workload that needs different guarantees would be better served elsewhere.

Figure 3.6.1

Title: Netflix on AWS — High-Level Cloud Architecture

Detailed Caption: TV, Phone, and Laptop client icons feed downward through a warm-gold "CloudFront CDN / Open Connect" tile and a gray "Elastic Load Balancer," entering a large dashed "AWS Cloud" frame footed with three "AZ 1, AZ 2, AZ 3" labels. Inside, a teal "EC2 Auto-Scaling Group (Microservices)" panel groups three service tiles (Search, Recommendations, Playback) above an "Auto-scaling instances" indicator; arrows connect those services to a navy "Data Services" stack on the right (DynamoDB / RDS / ElastiCache), and to a navy "Video Storage (S3)" tile and gray "SQS / SNS" messaging tile below. A separate dashed "Analytics" panel houses EMR / Big Data and SageMaker (ML), and a pixel-art "Chaos Monkey" badge labeled "Resilience Testing" sits to the side as a nod to Netflix's failure-injection philosophy. The figure compresses Netflix's well-known architecture into one canonical view, showing how one streaming request fans across CDN, compute, multiple data tiers, async messaging, and offline analytics — all underwritten by multi-AZ resilience.