8.8.1: Chapter 8

Overview

• Chapter: 8 — Building Cloud-Native Applications
• Total Figures Proposed: 8
• Figure Types Used: Architecture Diagram, Flowchart, Comparison Table, Conceptual Illustration, Network Diagram, Infographic

Figure 8.1.1

Title: Monolithic vs. Microservices Architecture

Detailed Caption: A vertical gold dashed divider splits the figure into two architectures. On the left, "Monolithic Architecture" shows a User icon piping a request into a single tall navy enclosure labeled "Monolith" that contains three lighter-blue interior tiles stacked tightly inside — UI, Business Logic, Data Access — all draining into a gold cylinder labeled "Database" beneath the enclosure. On the right, "Microservices Architecture" sends a User icon through a warm-gold "API Gateway," which fans arrows out to five teal service tiles arranged in a vertical column — User Service, Order Service, Payment Service, Catalog Service, and Notification Service — each paired with its own small navy database cylinder; a dashed vertical spine running alongside the column is labeled "APIs / Messages" to mark inter-service traffic. The visual contrast — one shared database versus five private ones, one block versus five services — gives the reader an immediate spatial intuition for the chapter's central design choice: monoliths centralize concerns at the cost of independence, while microservices trade simplicity for autonomy at every layer of the stack.

Figure 8.2.1

Title: Docker Container Lifecycle

Detailed Caption: Six rounded state nodes are connected by labeled command arrows. A gray "Registry" tile on the upper-left is paired with a navy "Image" tile via docker push and docker pull; from Image, a docker create arrow runs to a gray "Created" tile, while a thick warm-gold docker run arrow cuts diagonally to a teal "Running" state. From Running, paired arrows for docker pause and docker unpause swing to a gray "Paused" tile on the right, and docker stop / docker start arrows connect downward to a "Stopped" tile, which terminates at a dashed-outline "Removed" tile via a red docker rm arrow. A legend in the bottom-left clarifies that the gold trace highlights the most common path and the red trace marks a destructive operation. By color-coding the happy path and the irreversible exit, the figure helps readers separate routine container operations from those that demand deliberate care, and the laid-out state machine makes the relationship between Docker CLI verbs and lifecycle transitions explicit.

Figure 8.2.2

Title: CI/CD Pipeline for a Containerized Microservice

Detailed Caption: A horizontal pipeline reads left to right beneath two banners — a navy "Continuous Integration" header on the left half and a teal "Continuous Delivery" header on the right, separated by a dashed vertical line. Eight stages flow forward: a navy "Code Commit" tile (with a Git node icon), then teal tiles for "Build" (gear), "Unit Tests" (checkmark), and "Build Image" (registry box); after the divider, "Push to Registry," "Deploy Staging," a gold "Tests Pass?" decision diamond, and a final navy "Deploy to Production" tile. A "Yes" branch from the diamond advances to production, while a red dashed "No" branch loops all the way back to Code Commit, annotated "Fix and re-commit." The looping feedback path is the figure's pedagogical anchor: it makes plain that CI/CD is not a straight conveyor belt but a closed quality gate, where failed tests reroute work back to the developer rather than out to users.

Figure 8.3.1

Title: Synchronous vs. Asynchronous Communication in Microservices

Detailed Caption: A vertical gold dashed line splits the figure into two panels. The left panel, "Synchronous (API Calls)," renders three navy service boxes — Order Service at the top with Payment Service and Inventory Service beneath — connected by bidirectional arrows labeled "REST API," each annotated with a small clock icon and the warning "Caller waits." The right panel, "Asynchronous (Event-Driven)," recolors the services teal and inserts a warm-gold "Message Broker / Event Bus" tile in the middle, marked with a lightning bolt; a single gold arrow labeled "Publish: OrderPlaced" leaves Order Service for the broker, and two teal arrows labeled "Subscribe" fan out from the broker downward to the other services. The contrast between waiting clocks on the left and a single fire-and-forget publish on the right captures the core trade-off: synchronous calls couple services in time, while asynchronous events let producers and consumers move independently — at the cost of an additional infrastructure component to manage.

Figure 8.3.2

Title: Service Mesh Architecture with Sidecar Proxies

Detailed Caption: A wide warm-gold "Control Plane" bar across the top contains four sub-tiles — Config, Certs, Policies, and Telemetry — and emits gold dashed arrows downward into a dashed-bordered rectangle labeled "Data Plane." Inside the data plane, three teal service tiles (Service A, Service B, Service C) are each fused to a smaller navy "Proxy" sidecar, and the navy proxies — not the services themselves — are connected to one another by solid arrows, with one arrow explicitly labeled "mTLS." A legend at the bottom identifies the proxy as an Envoy or Linkerd sidecar and the dashed lines as configuration distribution. The visual cleanly separates the two responsibilities students often conflate: the control plane defines policy in one place, while every byte of east-west traffic actually moves through the proxies — meaning encryption, retries, and observability are added by the mesh without changing a single line of application code.

Figure 8.4.1

Title: Kubernetes Cluster Architecture

Detailed Caption: The whole figure is enclosed in a dashed rectangle labeled "Kubernetes Cluster." A wide navy "Control Plane" bar at the top houses four lighter-blue tiles — API Server, Scheduler, Controller Manager, and etcd — and sends navy dashed arrows down to two gray "Worker Node" rectangles below. Each worker node contains two or three teal "Pod" tiles with nested "Container" boxes inside them, plus small gray "kubelet" and "kube-proxy" agents along the bottom; a User icon on the far left flows through a gold "Load Balancer / Ingress" tile that fans arrows into both worker nodes. A legend underneath maps the color code: navy for control plane components, teal for application pods, gold for networking, and gray for node agents. The diagram's payoff is the clear vertical separation between brain (control plane) and muscle (worker nodes), letting students see at a glance why Kubernetes can heal a failed pod, reschedule work, and route traffic without any single component knowing the whole system.

Figure 8.4.2

Title: AWS Three-Tier Serverless Cloud-Native Architecture

Detailed Caption: The diagram is divided into three horizontal bands by gray dashed lines and labeled along the left margin in colored type — Presentation (navy), Application (teal), and Data (gold). The top band shows a User icon flowing into a navy "Amazon CloudFront (CDN)" tile that branches to an "S3 (Static Assets)" tile and downward into the middle tier. The middle band centers on a teal "API Gateway" fed by an "Amazon Cognito" auth box and fanning out to three teal Lambda functions — User, Order, and Payment — with a gold "Amazon SNS / SQS" tile catching events between them. The bottom band hosts three navy data stores — DynamoDB and RDS as cylinders and an "S3 (Data)" tile — receiving downward arrows from the Lambdas. A vertical teal dashed bar on the far right labeled "CloudWatch / X-Ray (Monitoring)" spans all three tiers, signaling that observability is cross-cutting. The figure shows readers how the classical three-tier pattern survives the move to serverless: the layers are still there, but each box has been replaced by a fully managed AWS service, and "the server" disappears into the cloud provider.

Figure 8.5.1

Title: The Three Pillars of Observability

Detailed Caption: Three equal-width columns sit side by side, each topped by a colored header — navy "Logs," teal "Metrics," and navy "Traces" — and each posing a question in italic gray text: "What happened?", "How is it performing?", and "Where is the bottleneck?" The Logs column shows a dark terminal panel with timestamped INFO, WARN, and ERROR lines, the ERROR line highlighted in gold to flag a corr-id correlation ID; the Metrics column displays a teal time-series line chart with data points climbing toward a red dashed "Threshold" line; and the Traces column renders a Gantt-style waterfall where Service A (120ms, navy), Service B (80ms, teal), and Service C (45ms, gold) cascade beneath a vertical "Trace ID" axis. Beneath each column, descriptive text and a tool-stack pill list common implementations — ELK Stack and CloudWatch Logs, Prometheus and Grafana, Jaeger and AWS X-Ray — and a wide gold bar at the bottom labeled "Complete System Observability" unifies the three. The figure's pedagogical message is that no single signal type is sufficient on its own: logs tell you what, metrics tell you how much, and traces tell you where — and only together do they answer the operational questions cloud-native systems pose.