10.9.1: Chapter 10

Introduction to Cloud Computing · LibreTexts

0%

Contents

    Text

    Size
    100%
    Theme
    Typeface
    Line length
    Spacing

    From LibreTexts, under CC BY 4.0, as the source states it; its equations are written in TeX, which the PDF shows typeset. This page at LibreTexts.

    10.9.1: Chapter 10

    Overview

    • Chapter: 10 — Infrastructure Design and Resource Management
    • Total Figures Proposed: 8
    • Figure Types Used: Architecture Diagram, Conceptual Illustration, Comparison Table, Flowchart, Infographic, Network Diagram

    Figure 10.1.1

    Title: Core Principles of Cloud Infrastructure Design

    Detailed Caption: Five navy rounded-rectangle nodes are arranged in a horizontal arc — Scalability, Elasticity, High Availability, Fault Tolerance, and Disaster Recovery — connected by thin gray arrows tipped in warm gold. The Scalability box carries two teal sub-labels, "Vertical" and "Horizontal," and a small italic "feeds" label sits above the arrow flowing into Elasticity, while a teal bracket overhead groups High Availability and Fault Tolerance under the heading "Resilience." A curved arrow loops back from Disaster Recovery to High Availability, annotated "recovery supports availability," and a wide teal foundation bar labeled "Well-Architected Cloud Infrastructure" anchors all five pillars from below via dashed drop lines. The visual reframes these five terms not as a checklist but as a directed flow: scaling capabilities enable elastic response, which feeds the resilience pair, while disaster recovery closes the loop by restoring availability after failure.

    Figure 10.2.1

    Title: Three-Tier Cloud Architecture

    Detailed Caption: Three horizontal bands stack vertically against a light gray backdrop. The top navy band, "Presentation Tier," contains a Web Browser icon, a Mobile device icon, and a teal CDN pill. A vertical arrow labeled "HTTP / HTTPS Requests" in warm gold drops into the middle teal band, "Application Tier," which holds three navy components — API Gateway, App Servers / Lambda, and Load Balancer — wired left to right. A second arrow labeled "Database Queries" descends to the bottom navy "Data Tier," which contains two teal pills, Relational DB and NoSQL DB. Tall warm-gold brackets frame the entire stack, marked "Independent Scaling" on the left and "Security Isolation" on the right. The figure makes the layered separation of concerns concrete: each tier is its own colored slab, the request path is a single vertical channel, and the brackets remind students that the same partition that aids scaling also draws clean security boundaries between client, logic, and data.

    Figure 10.2.2

    Title: Microservices Architecture with API Gateway

    Detailed Caption: A small navy "Clients" box at the top, decorated with browser and mobile glyphs, funnels into a wide navy bar labeled "API Gateway / Load Balancer" that spans the full width of the diagram. From this bar, four parallel gray arrows drop into a row of teal service tiles — Account Service, Catalog Service, Order Service, and Shipping Service — each pinned to its own gray data store directly below (SQL DB, NoSQL DB, SQL DB, and Cache, respectively, signaling polyglot persistence). A long horizontal warm-gold dashed line runs across the service row labeled "REST / Messaging (inter-service communication)," and a light gray banner at the bottom carries the navy text "Shared Infrastructure: Service Discovery, Monitoring, Logging." The figure makes the microservices contract visible at a glance: clients hit one façade, each service owns its store and is independently deployable, peer-to-peer messaging crosses the row, and the cross-cutting concerns belong to a shared platform layer underneath.

    Figure 10.3.1

    Title: Cloud Resource Types Overview

    Detailed Caption: Five equally sized white cards sit in a single row, each topped by a thin warm-gold accent bar and a navy header strip — Compute, Storage, Networking, Databases, and Serverless. Inside each card, a teal sub-type line names the primitives ("VMs, Containers"; "Block, Object, File"; "VPC, Load Balancer, CDN"; "SQL, NoSQL, Cache"; "FaaS, BaaS"), separated by a thin divider from three gray rows that map the category onto AWS, Azure, and GCP — for example Compute lists EC2/ECS, VMs/ACI, GCE/GKE, while Serverless lists Lambda, Functions, and Cloud Functions. The columnar layout turns a sprawling vendor catalog into a single flat lookup table: students can scan horizontally to see how the same primitive shows up across providers, or vertically to see what a single category contains, which is the kind of cross-reference the running text cannot provide compactly.

    Figure 10.3.2

    Title: Virtual Machines vs. Containers

    Detailed Caption: A vertical dashed gray line splits the figure into two stacks under bold navy headers, "Virtual Machines" on the left and "Containers" on the right. Both stacks share an identical foundation — a gray "Physical Hardware" slab and a gray "Host Operating System" slab — but diverge above it: the left side places a teal "Hypervisor" bar carrying three boxed units that each contain a navy "Guest OS" sitting atop a warm-gold "App," while the right side places a teal "Container Runtime" bar carrying three lighter "App + Libs" tiles with no Guest OS layer. A small navy-headed comparison table sits below the stacks, with three rows quantifying the trade-off — Isolation: "Strong (hardware-level)" vs. "Process-level"; Overhead: "High" vs. "Low"; Startup: "Minutes" vs. "Seconds." The visual delivers the architectural punchline directly: the missing Guest OS layer in the right stack is exactly why containers are lighter and start faster, while the matching foundation reminds students that both still depend on the same host kernel.

    Figure 10.4.1

    Title: Infrastructure as Code (IaC) Workflow

    Detailed Caption: Six rounded boxes march left to right across a light gray track, each topped by a warm-gold circular step marker numbered 1 through 6 and connected by thin gray arrows. Step 1 "Write Config" (navy) carries the sub-label "HCL / YAML / JSON"; Steps 2–4 — "Version Control" (Git Repository), "Code Review" (Pull Request), and "Plan / Preview" (terraform plan / changeset) — appear as teal boxes; Step 5 "Apply / Deploy" (terraform apply / stack create) returns to navy; and Step 6 "Running Infrastructure" (VMs, Networks, DBs) is a warm-gold capstone. A long gray return arrow loops underneath from Step 6 back to Step 1, italicized "Update & Iterate," closing the cycle. The numbered markers and the color shift between authoring (navy), review (teal), and live system (gold) make the IaC lifecycle scannable at a glance and emphasize that infrastructure is no longer a one-shot deploy but a versioned, peer-reviewed software artifact that lives in a feedback loop with reality.

    Figure 10.5.1

    Title: Cloud Pricing Models Comparison

    Detailed Caption: A three-column comparison table runs beneath a thin warm-gold accent bar, with navy header pills naming the pricing models — On-Demand, Reserved / Savings Plans, and Spot / Preemptible — and four gray label cells down the left margin: Cost Level, Commitment, Interruption Risk, and Best For. The cells alternate between white and pale-mint shading for readability and read across as a tight summary: On-Demand is "Highest" cost, "None" commitment, "None" interruption, "Variable / unpredictable workloads"; Reserved is "30–60% savings," "1–3 years," "None," "Steady-state 24/7 workloads"; Spot is "Up to 90% savings," "None," "High — can be reclaimed," "Fault-tolerant batch jobs." By placing cost, commitment, risk, and fit on the same row, the table forces the trade-off into a single comparison: cheaper prices buy either a multi-year commitment or the willingness to be evicted, and matching workload character to pricing model is the actionable takeaway.

    Figure 10.6.1

    Title: Cloud Monitoring and Auto-Scaling Feedback Loop

    Detailed Caption: Five rounded nodes are arranged in a clockwise circle around a centered italic gray label, "Continuous Feedback Loop." At the top sits navy "Cloud Resources" (EC2, GKE Pods, App Service); curving right and down to teal "Metrics Collection" (CPU, Memory, Latency, Custom); then along the bottom-right arc to teal "Threshold Evaluation" (CloudWatch Alarms / Azure Alerts); across the bottom to warm-gold "Alert / Action Trigger" (Notify Team / Trigger Policy); and up the left to navy "Auto-Scale Response" (Scale Out / Scale In), which closes the loop back to Cloud Resources. Thin gray arrows tipped in navy connect each node to the next, and the deliberate color rotation — navy live system, teal observation, gold human-or-automated decision, navy actuation — reinforces the lesson that observability and elasticity are not separate systems but a single self-regulating cycle in which every component depends on the one before it.


    This page titled 10.9.1: Chapter 10 was last modified on Tue, 22 Sep 2026 21:42:28 GMT and is shared under a CC BY 4.0 license and was authored, remixed, and/or curated by Felix Amoruwa.