6.11.1: Chapter 6

Overview

• Chapter: 6 — Cloud Architecture and Service Layers
• Total Figures Proposed: 8
• Figure Types Used: Architecture Diagram, Comparison Table, Conceptual Illustration, Flowchart, Network Diagram, Infographic

Figure 6.1.1

Title: Layered Cloud Architecture Stack

Detailed Caption: Four wide horizontal bands stack vertically and color-grade upward from physical to abstract. The dark-gray base "Datacenter Layer (Physical)" carries Server Racks, Cooling, and Power glyphs with the stewardship line "Managed by: System Administrators"; above it, a navy "Infrastructure Layer (IaaS)" displays Virtual Machines, Storage Volumes, and Virtual Networks tiles attributed to IT Operations; the teal "Platform Layer (PaaS)" lists Runtime Environments, Databases, and Middleware under Developers; and the warm-gold "Application Layer (SaaS)" caps the stack with Web Apps and End-User Interfaces under End Users. Two vertical arrows flank the figure — "Increasing Abstraction" pointing up on the left and "Increasing Control" pointing down on the right. By pairing each layer with the role that owns it and contrasting the abstraction-vs-control axes, the figure makes vivid that climbing the stack trades hands-on power for ergonomic shortcuts, and that each role lives at a different altitude.

Figure 6.2.1

Title: Shared Responsibility Across Cloud Service Models

Detailed Caption: A 6×9 matrix arrays six service-model columns (On-Premises, IaaS, CaaS, PaaS, FaaS, SaaS) under dark-gray header pills against nine row labels listing the technology stack from Applications at the top down through Data, Runtime, Middleware, OS, Virtualization, Servers, Storage, and Networking. Every cell is filled with one of two flat colors: a soft mint "Customer Managed" or a navy "Provider Managed," and the staircase pattern is the visual punchline — On-Premises is fully mint top to bottom, IaaS adds navy below the OS, CaaS pushes navy above OS into Middleware, PaaS swallows Runtime, FaaS swallows Data, and SaaS turns the entire column navy. A bottom legend decodes the two colors, and a left-to-right arrow underneath reads "Customer Responsibility decreases → Provider Responsibility increases." The staircase makes the abstract claim concrete: each step right shifts the responsibility seam upward by one or two layers, and the customer's surface area shrinks until only Application configuration (or nothing) remains.

Figure 6.3.1

Title: Cloud Building Blocks Mapped to Architecture Layers

Detailed Caption: Four horizontal bands stack vertically with progressively warmer color fills — gray "Physical Layer" at the bottom (Servers, Disks, Network Hardware), navy-bordered "Infrastructure / IaaS" (VMs / Containers, Block Storage / Object Storage, VPCs / Subnets / Load Balancers, Security Groups / Network ACLs), teal-bordered "Platform / PaaS" (Managed Databases (DBaaS), Runtime Environments, CI/CD Pipelines, Messaging / Streaming Services, AI/ML Services), and a gold-bordered "Application / SaaS" cap (SaaS Applications, APIs & Microservices, User Interfaces). Each layer's building blocks appear inside as labeled tiles, and dashed gray lines run vertically from layer to layer to suggest dependency. To the right of the entire stack, two tall vertical bars labeled "Security & IAM" and "Monitoring & Observability" span all four layers, drawn in a muted gray with gold accent borders to mark them as cross-cutting concerns. The figure converts a multi-paragraph survey of cloud primitives into a one-page cheat sheet — students can locate any service by its layer, and the side bars remind them that observability and identity aren't features of one layer but obligations across all of them.

Figure 6.4.1

Title: OSI Model Layers Mapped to Cloud Networking Services

Detailed Caption: Seven labeled layer pills stack vertically on the left, color-graded from navy at Layer 1 (Physical) and Layer 2 (Data Link) to teal at Layers 4–7 (Transport, Session, Presentation, Application), with a steel-blue Layer 3 (Network) acting as a hinge labeled "Mixed: Provider + User." A "Provider-Managed" bracket spans Layers 1–2 and a "User-Configurable" bracket spans Layers 4–7. To the right of each layer, a long arrow points into a paired example pill: L1 → "Data center cabling, fiber optics, NICs, physical switches"; L2 → "SDN (Software-Defined Networking), VLANs, VXLANs"; L3 → "VPCs, Subnets, Route Tables, Network ACLs, IP addressing"; L4 → "Security Groups, Network Load Balancers, TCP/UDP rules"; L5 → "WebSocket APIs, Sticky Sessions, Session Management"; L6 → "TLS termination, API Gateway data transforms, Encryption services"; L7 → "Application Load Balancers, WAFs, DNS (Route 53), API Gateways, HTTP routing." By color-coding the ownership boundary and pairing each OSI layer with concrete AWS-style services, the figure turns a textbook diagram into a working reference — students can decide where in the stack to apply a control (for example, which load balancer type to choose) and immediately see whether the layer is theirs to configure.

Figure 6.5.1

Title: Monolithic vs. Microservices Architecture

Detailed Caption: A vertical dashed divider splits the figure into two architectures. On the left, "Monolithic Architecture" shows a single tall navy enclosure labeled MONOLITH, with a User icon piping a request into it from above and four lighter blue interior tiles stacked tightly inside — UI, Business Logic, Data Access, and a pair of side-by-side Auth and Notifications tiles — all draining into a single gray Database cylinder beneath the enclosure, captioned "Single deployable unit." On the right, "Microservices Architecture" shows a User icon feeding a warm-gold "API Gateway," which fans gray arrows out to a row of five teal service tiles — User Service, Catalog Service, Auth Service, Notification Service, and a separately positioned Order Service — each paired with its own small gray cylinder for per-service storage; dashed gold inter-service connectors imply REST/messaging traffic and the footer reads "Independent deployable services / Inter-service communication." The before/after framing externalizes the chapter's central trade-off: the monolith concentrates everything inside one perimeter and one database, while microservices replace internal lines with network calls and distribute data ownership — buying independent deployment and scaling at the cost of new operational concerns.

Figure 6.6.1

Title: Serverless Three-Tier Web Application Architecture

Detailed Caption: A vertical color-coded ribbon down the left edge labels three horizontal tiers — gold Presentation Tier, teal Business Logic Tier, and navy Data Tier — separated by thin dashed lines. The top tier shows a Browser icon flowing into a gold "Amazon CloudFront (CDN)" tile, which branches to a gold "Amazon S3 (Static Assets)" tile and a parallel gold "Amazon Cognito (Authentication)" tile. The middle tier centers on a teal "API Gateway (REST/HTTP)" that fans arrows to three teal "AWS Lambda" tiles labeled User Function, Order Function, and Notification Function, with a dashed line from Cognito to the User Function suggesting JWT-token validation. The bottom tier hosts navy "Amazon DynamoDB (NoSQL Database)" and "Amazon S3 (File Storage)" tiles, each connected by arrows up to the Lambda functions. The figure makes vivid that the classical three-tier pattern survives the move to serverless — the layers are still there, but every box is a fully managed AWS service, and "the server" disappears into the cloud provider, leaving only request flow and data ownership for the developer to reason about.

Figure 6.7.1

Title: Analytics Data Pipeline Reference Architecture

Detailed Caption: Five rounded color-coded stage cards march left to right, connected by thick gray flow arrows. Stage 1 (navy) "INGEST" lists Kafka / Kinesis, Event Hubs, IoT Endpoints, Batch Uploads with a "Real-time & batch ingestion" footer, fed from the far left by four data-source tiles (Web/Mobile, IoT Devices, Databases, Log Files); Stage 2 (slate-blue) "STAGE RAW" lists S3 / Data Lake Storage, Message Queues, and Raw Data Landing Zone with "Immutable raw storage"; Stage 3 (teal) "PROCESS" lists Spark / EMR / Databricks, Stream Analytics / Flink, AWS Glue / Dataflow ETL, and Lambda (lightweight) under "Clean, enrich, transform"; Stage 4 (deep teal) "STORE" lists Data Warehouse (Redshift, BigQuery, Synapse), Elasticsearch, and Curated Data Lake (Parquet on S3); and Stage 5 (warm gold) "ANALYZE" lists BI Dashboards (QuickSight, Tableau), ML Training (SageMaker, Azure ML), Real-time Alerts, and Application APIs. A gold dashed "Feedback Loop" arrow curves underneath all five stages from Analyze back to Ingest, and a footer legend groups the colors into Ingest & Raw Storage, Process & Analytics Storage, and Analyze & Consume. The figure converts a sprawling tooling landscape into one canonical reference flow, and the feedback loop reminds readers that analytics insights typically generate new ingestion sources rather than ending the pipeline.

Figure 6.8.1

Title: Single-Cloud, Multi-Cloud, and Hybrid Cloud Deployment Models

Detailed Caption: Three equal-width vertical columns sit beneath color-coded header pills — navy "Single-Cloud," teal "Multi-Cloud," and warm-gold "Hybrid Cloud" — each topped by a small schematic illustration: one cloud holding several services, three labeled clouds (A, B, C) standing apart, and one cloud bridged to an on-prem rack. Below each illustration, a uniform four-section card lists Advantages, Risks, Best For, and Examples in identical positions: Single-Cloud highlights deep integration and simpler operations against vendor lock-in, naming Netflix (AWS) and Capital One (AWS); Multi-Cloud highlights avoiding lock-in, best-of-breed services, and negotiating leverage against high complexity and skill fragmentation, naming Apple iCloud (AWS + GCP) and Twitter/X (AWS + GCP); Hybrid Cloud highlights gradual migration and data sovereignty against networking complexity and dual management, naming Dropbox (private infra + cloud) and enterprises in transition. The parallel four-row format lets students compare any single dimension across the three models at a glance, and reframes the deployment-model decision as a structured trade-off rather than a popularity contest.