14.7: Detailed Captions - Chapter 14

Overview

• Chapter: 14 — The Future of Cloud Computing
• Total Figures Proposed: 8
• Figure Types Used: Architecture Diagram, Flowchart, Conceptual Illustration, Comparison Table, Infographic, Network Diagram

Figure 14.1.1

Title: Evolution of Serverless Computing: From Simple Functions to Full Workloads

Detailed Caption: A navy "Serverless Core (FaaS)" disk sits at the center of the figure with five teal satellite tiles orbiting it like petals, each connected to the core by a warm-gold spoke. Reading clockwise from the top: Stateful Workflows (linked-loop icon, "Linked steps & orchestration") with the example tag "AWS Step Functions, Durable Functions"; AI/ML Inference (neural-network icon, "GPU-accelerated functions") with "GPU Functions, SageMaker Serverless"; Complex & Long-Running (briefcase icon, "Containerized workloads") with "Cloud Run, Azure Container Apps"; Multi-Cloud & Open (interlocking-rings icon, "Portable frameworks") with "Knative, OpenFaaS"; and Edge & Hybrid (monitor-edge icon, "Near-user compute") with "Lambda@Edge, CloudFlare Workers." A faint dashed teal ellipse traces the orbit to suggest unified scope. The hub-and-spoke composition makes the chapter's argument visible at a glance: serverless began as short stateless functions but has expanded into five distinct directions, and each new petal represents a workload class the original FaaS abstraction could not handle.

Figure 14.2.1

Title: Cloud Infrastructure Stack for Foundation Model Training

Detailed Caption: Four wide horizontal layers stack vertically, color-graded from navy at the bottom to a lighter teal at the top, connected by warm-gold downward arrows. The base "Specialized Hardware" layer (navy) shows three accelerator pills — NVIDIA A100/H100, Google TPU v4/v5, and AWS Trainium / Inferentia — each with a small chip glyph. Above it, a gray "High-Speed Networking" layer lists 100+ Gbps Links, RDMA / InfiniBand, and NVLink as the interconnect fabric. Next, a teal "Distributed Training Frameworks" layer carries DeepSpeed, Horovod, Model Parallelism, and Data Parallelism. The top "Managed ML Platforms" band (lighter teal) displays AWS SageMaker, Google Vertex AI, and Azure ML as the user-facing surface. Off to the right, a dataset cylinder labeled "Petabytes of Training Data" feeds an arrow into the stack. The figure makes the foundation-model-training reality concrete: even with managed platforms at the top, none of the user-facing convenience exists without the carefully co-engineered hardware and high-bandwidth interconnects underneath — and any one weak layer caps the throughput of the whole stack.

Figure 14.2.2

Title: MLOps Lifecycle on Cloud Platforms

Detailed Caption: Six teal rounded-rectangle stages are arranged in a clockwise loop around a central "MLOps · Lifecycle" label, connected by warm-gold arrows. Step 1 "Data Preparation & Feature Engineering" sits at the top, followed by 2 "Model Training & Experimentation" on the right, 3 "Model Evaluation & Validation" on the lower-right, 4 "Model Deployment (CI/CD Pipeline)" at the bottom, 5 "Monitoring & Observability" on the lower-left, and 6 "Retraining Trigger (Data Drift / Performance Decay)" on the upper-left, with the final arrow looping from Step 6 back to Step 1 to close the cycle. Beneath the loop, a footer pill maps the workflow to common platforms: AWS SageMaker | Google Vertex AI | Azure ML. The closed-loop layout makes the chapter's central message visual: ML in production isn't a deploy-and-forget pipeline but a continuous discipline where monitoring and drift detection are first-class steps that route work back into preparation and training — the absence of step 6 turns every other step into one-shot effort.

Figure 14.3.1

Title: CRDT Merge Operation: Conflict-Free Concurrent Updates Across Replicas

Detailed Caption: Three vertical timelines labeled Replica A, Replica B, and Replica C run side by side, each starting at the top with the identical state [0, 0, 0]. Midway down, each replica accepts a local update — A increments its slot to [2, 0, 0], B to [0, 3, 0], and C to [0, 0, 1] — shown as teal-bordered tiles labeled "+2 to slot A," "+3 to slot B," and "+1 to slot C." Two horizontal dashed teal "Sync/Merge" lines bridge the replicas, and at the bottom all three replicas converge to the same gold-bordered state [2, 3, 1] with "Total = 6" emphasized in warm gold under each. A small footer note reads "Merge = element-wise max." By drawing the divergence and convergence on a single canvas, the figure transforms an abstract data-structure result into an immediately graspable principle: with a properly constructed merge function, replicas can accept concurrent writes without coordination and arithmetically guarantee they will agree on the final state — which is the property that lets cloud systems offer high availability without sacrificing eventual consistency.

Figure 14.3.2

Title: Saga Pattern for Distributed Transactions in Microservices

Detailed Caption: A horizontal "Forward Transactions (Happy Path)" track runs across the top with three teal tiles connected by gold arrows — Reserve Flight (Local Transaction T1), Reserve Hotel (Local Transaction T2), and Process Payment (Local Transaction T3). Below the third tile, a red X and the label "Payment Fails!" mark the failure point, with a downward red arrow leading to a "Compensating Transactions (Rollback)" track running right-to-left at the bottom: Refund Payment (no-op: payment failed), Cancel Hotel (Compensating action C2), and Cancel Flight (Compensating action C1), all rendered as red-outlined cream tiles connected by gold arrows. A legend in the lower-left identifies solid teal as "Local Transaction (forward)" and red-bordered as "Compensating Action (rollback)." The deliberate top-to-bottom symmetry makes the saga pattern click: each forward transaction has a paired compensating action, and on failure the system unwinds the work in reverse order — replacing the all-or-nothing guarantee of a distributed transaction with a designed-in rollback choreography.

Figure 14.4.1

Title: Carbon-Aware Workload Scheduling Across Cloud Regions

Detailed Caption: A central navy "Carbon-Aware Scheduler" tile — annotated with a clock icon and "Temporal Shifting: delay to low-carbon hours" — receives a feed from a "Batch Job Queue" on the left (queued workload tiles) and a warm-gold "Grid Carbon Intensity API (Real-time) — WattTime, Electricity Maps" on the right. From the scheduler, three downward arrows fan out to three Region tiles: a teal-bordered Region A (Solar-heavy Grid) with a sun icon and a green "Low CO₂ — 50 g/kWh" badge marked "PREFERRED"; Region B (Mixed Grid) with a yellow "Med CO₂ — 300 g/kWh" badge; and Region C (Coal-heavy Grid) with a smokestack icon and a red "High CO₂ — 600 g/kWh" badge. The arrow into Region A is bold and teal; arrows to Regions B and C are dashed gray, signalling deprioritization. The figure makes carbon-aware scheduling concrete: the same workload routed to a different region — or delayed by a few hours — can produce dramatically different emissions, and a real-time grid signal is what turns that knowledge into automated routing decisions.

Figure 14.5.1

Title: Internal Developer Platform Architecture

Detailed Caption: Three horizontal tiers stack vertically in the figure. The top tier, "Product Development Teams," holds three navy person/avatar icons (Team A, Team B, Team C) inside a light-gray frame and emits gold "Self-Service Requests" arrows downward. The middle tier is a wide teal "Internal Developer Platform (IDP)" panel containing five sub-tiles: Developer Portal & Service Catalog, CI/CD Pipelines, Infrastructure as Code (Terraform), Observability (Logs, Metrics, Traces), and Security & Governance Policies. From the IDP, gold "Automated Provisioning" arrows drop into the bottom tier, "Cloud Infrastructure," which holds three provider tiles — AWS (Kubernetes, Lambda, RDS), Azure (AKS, Functions, Cosmos DB), and GCP (GKE, Cloud Run, BigQuery). On the far left, a navy "Platform Engineering Team" tile with the caption "Builds & Maintains" sends an arrow into the IDP. The three-tier composition delivers the chapter's argument visually: the IDP isn't an extra layer of bureaucracy but a deliberately curated abstraction that lets product teams ship via self-service while the platform team owns multi-cloud complexity, governance, and standardization underneath.

Figure 14.6.1

Title: Emerging Cloud Roles and Their Interdisciplinary Skill Domains

Detailed Caption: Six navy role tiles stack vertically on the left — AIOps Engineer, FinOps Analyst, Cloud Sustainability Officer, Platform Engineer, Multi-Cloud Architect, and ML Engineer (Cloud) — and five teal vertical skill-domain bars stand on the right, headed Software Engineering, Data Science / AI, Finance / Business, DevOps / Infrastructure, and Environmental Science. Warm-gold horizontal lines connect each role to its constituent skills, marked by gold dots where the line intersects a domain column: AIOps connects to Software Engineering and Data Science / AI; FinOps connects to Finance / Business and DevOps / Infrastructure; Cloud Sustainability Officer reaches across to DevOps / Infrastructure and Environmental Science; Platform Engineer hits Software Engineering and DevOps / Infrastructure; Multi-Cloud Architect spans the same two; and ML Engineer (Cloud) connects to Software Engineering and Data Science / AI. The matrix layout makes the chapter's hiring-and-skills thesis visible at a glance: cloud careers no longer fit into single disciplinary silos, and the gold connector lines double as a learning roadmap — pursuing any one of these roles requires building competence in two or more of the underlying skill domains.