9.10.1: Chapter 9

Overview

• Chapter: 9 -- Workload Strategy Meets Implementation
• Total Figures Proposed: 8
• Figure Types Used: Architecture Diagram, Flowchart, Comparison Table, Conceptual Illustration, Infographic, Network Diagram

Figure 9.1.1

Title: Bridging Strategy to Implementation -- The Workload Assessment Pipeline

Detailed Caption: Five rounded tiles march left to right against a pale gray backdrop, connected by thin gray flow arrows. The first stage, a navy "Cloud Strategy (Vision & Goals)" with a target/compass icon, hands off to three teal stages — "Stakeholder Interviews & Discovery" (magnifier icon, listing Technical Staff, Executives, Business Leads), "Workload Profiling" (bar-chart icon, listing Compliance, Security, Cost, Recovery, Performance, SLAs), and "Alignment & Categorization" (2×2 tile icon, listing Rehost, Re-platform, Retire) — before terminating in a warm-gold "Migration Plan (Actionable Steps)" with a checklist icon. Two faint dashed brackets above the flow group the first two stages under the italic label "Strategy" and the last two under "Implementation," visually marking where intent crosses over into execution. The figure makes the abstract assessment pipeline scannable, showing readers that profiling is the hinge that turns interviews into an actionable migration plan rather than a vague aspiration.

Figure 9.2.1

Title: On-Premises vs. Cloud Infrastructure Architecture

Detailed Caption: Two rounded panels sit side by side. The left panel, "On-Premises Data Center" inside a solid gray frame subtitled "Static, Manually Provisioned," shows a single vertical chain — Users to a teal Load Balancer to a navy Application Server (Single Instance) to a gold-and-cream Database Server cylinder — with each handoff drawn as a thick gray arrow. The right panel, "Cloud Environment (VPC)" inside a dashed navy frame on a pale blue fill, replaces that linear chain with a layered topology: Users feed an Internet Gateway, which descends into a teal-bordered Public Subnet containing a Cloud Load Balancer that fans out to two navy App Server boxes labeled "Auto-Scaling Group," while a gold NAT Gateway sits to the side with an "Outbound only" arrow back to the Internet Gateway; below that, a gray Private Subnet holds a Managed DB cylinder linked by a dashed arrow to a Multi-AZ Replica. By preserving the same user-to-data flow but multiplying the components and color-coded boundaries, the diagram makes vivid the chapter's core architectural shift — from a fragile single chain of hardware to a resilient, segmented, horizontally redundant cloud topology.

Figure 9.3.1

Title: Horizontal vs. Vertical Scaling Compared

Detailed Caption: A thin vertical divider splits the figure into two contrasting strategies. On the left, "Horizontal Scaling (Scale Out)" shows a teal Load Balancer at the top fanning gray arrows down to three identically sized navy server boxes (Instance 1, 2, 3); a fourth dashed-outline box with a gold "+" icon labeled "Instance N" hints that the row can keep growing, and beneath it the trade-off labels read Fault tolerant, Flexible capacity, Requires stateless design. On the right, "Vertical Scaling (Scale Up)" shows a single server box that grows in three steps from a small light-gray "2 vCPU / 4 GB" instance, to a medium light-teal "4 vCPU / 16 GB," to a large dark-teal "8 vCPU / 32 GB," with gold "Upgrade" arrows linking each size; the trade-offs below read Simple architecture, Single point of failure, Upper capacity limit. The visual pun — many small identical boxes versus one box that physically swells — gives readers an immediate intuition for why horizontal scaling spreads risk across replicas while vertical scaling concentrates capacity (and failure) into a single growing instance.

Figure 9.3.2

Title: Layer 4 vs. Layer 7 Load Balancing

Detailed Caption: Two stacked panels mirror each other with a deliberately different routing logic. The top panel, "Layer 4 Load Balancer (Transport Layer)," shows a pale-blue input pill labeled "TCP/UDP Packets" feeding a teal "L4 Load Balancer" box marked "Routes by: IP + Port," whose three identical gray arrows fan out to undifferentiated navy boxes Server A, B, and C, with a small italic note reading "Round-robin / Least connections." The bottom panel, "Layer 7 Load Balancer (Application Layer)," replaces the input with "HTTP/HTTPS Requests" feeding a teal "L7 Load Balancer" labeled "Inspects: URL, Headers, Cookies" and "Content-based routing, SSL termination"; here the three exit arrows are individually annotated in gold with path patterns — /images/* to Image Servers, /api/* to API Servers, and /* to Web Servers. By keeping the topology identical but swapping the routing labels, the figure isolates the single conceptual difference between the two layers: L4 sees only addresses while L7 reads content, which is what makes blue-green deployments and path-based microservice routing possible.

Figure 9.4.1

Title: VPC Network Architecture with Public and Private Subnets

Detailed Caption: A gray "Internet" cloud at the top sends traffic through a teal Internet Gateway into a large dashed-navy frame labeled "VPC (10.50.0.0/16)," which is bisected vertically into two columns titled Availability Zone A and Availability Zone B. A long gold Application Load Balancer bar spans both zones near the top, with arrows feeding navy Web Server boxes inside teal-bordered Public Subnets (10.50.1.0/24 and 10.50.2.0/24); each public subnet also carries a gold NAT Gateway with a dashed "Outbound only" line back up to the Internet Gateway, and a small SG hexagon icon marks security groups. Below, gray-bordered Private Subnets (10.50.11.0/24 and 10.50.12.0/24) each hold a teal App Server, both pointing into a single gold-cream "Database (Multi-AZ)" cylinder that straddles the AZ divider. Off to the right, a gray "On-Premises Data Center" box connects via a navy VPN Gateway and a dashed line annotated "IPsec VPN Tunnel." The diagram operationalizes the chapter's network-design principles: a single VPC can be both internet-reachable and tightly compartmentalized, with redundancy across AZs, controlled egress through NAT, and a hybrid bridge to existing corporate infrastructure.

Figure 9.5.1

Title: Migration Strategy Decision Framework

Detailed Caption: A six-column matrix sits beneath a navy header row reading Strategy, Also Known As, Effort, Risk, Best For, and Example, with alternating white and pale-mint row fills that aid horizontal scanning. Five strategies stack from top to bottom — Rehost (Lift-and-Shift), Re-platform (Lift-and-Reshape), Repurchase (SaaS Replacement), Refactor (Re-architect), and Retire (Decommission) — and the Effort and Risk cells use color as a fast signal: teal "Low" for Rehost and Retire, plain navy "Medium" for Re-platform and Repurchase, and gold "High" for Refactor. The Best For and Example columns translate each strategy into a one-line situation and concrete instance — e.g., Refactor pairs "High-value apps needing cloud-native features" with "Monolith broken into microservices," while Retire pairs "Unused or redundant systems" with "Legacy archive system shut down." The color-coded effort/risk pairing lets a planner compare options at a glance before reading the prose, reinforcing that the cheapest moves (Rehost, Retire) and the most transformative one (Refactor) sit at opposite ends of the same spectrum.

Figure 9.6.1

Title: Phased Cloud Migration Timeline

Detailed Caption: A horizontal bar runs left to right from Month 0 to Month 24, segmented into five color-graded blocks — navy "Phase 1: Assess & Plan" (months 0–3), dark-teal "Phase 2: Pilot Migration" (3–6), teal "Phase 3: Non-Critical Prod" (6–12), light-teal "Phase 4: Critical Production" (12–18), and warm-gold "Phase 5: Optimize & Decommission" (18–24) — with white diamond milestone markers punctuating each phase boundary. Below the bar, five matching white callout cards spell out the activities of each phase: stakeholder interviews and landing-zone setup early on; small-app pilots and process validation; internal apps, batch systems, and staff retraining; revenue systems with dry runs and back-out plans; and finally right-sizing, cost optimization, and data-center shutdown. Above and below the timeline, two soft trend curves tell the meta-story — a navy "Cloud Maturity" curve climbs steadily from left to right while a gray "Migration Risk" curve drifts upward through the middle phases as critical workloads cut over. The infographic gives readers a defensible default cadence they can stretch or compress and visually communicates that maturity and risk both grow during a migration; success is about managing the gap between them.

Figure 9.7.1

Title: Continuous Cloud Optimization Cycle

Detailed Caption: Six rounded rectangles are arranged as a clock face around a central navy label reading "Optimization Cycle," each connected to the next by a curved gray arrow that traces a clockwise loop. Step 1 "Measure" sits at the top in navy with a bar-chart icon and the sub-label "Collect metrics, costs, usage data"; the cycle then moves through teal-filled boxes — 2 "Analyze" (magnifier icon, "Identify bottlenecks & waste"), 3 "Prioritize" (checklist icon, "Rank by cost impact & SLA risk"), 4 "Implement" ("Resize, retune, refactor"), and 5 "Verify" (checkmark, "Confirm improvements, no regressions") — before closing on a warm-gold step 6 "Repeat" labeled "Continuous improvement," whose return arrow loops back to Measure. By drawing optimization as a closed loop with no terminal endpoint and color-coding only the entry (Measure) and the return arc (Repeat), the figure communicates the chapter's central message that cloud workloads drift constantly and that disciplined teams treat tuning as a recurring rhythm rather than a one-shot project.