--- title: 'What Is Cloud Computing' source: 'https://academia.sh/en/courses/cloud-fundamentals/what-is-cloud-computing' course: 'Cloud Fundamentals' language: en updated: '2026-09-13T05:07:33+00:00' license: 'CC BY-SA 4.0' objectives: - 'Measures elasticity as a duration and compares the time from capacity request to use across two acquisition methods' - 'Counts two costs together in the same demand curve: unmet requests and idle capacity' - "Shows the demand pattern where renting's payoff drops to zero and counts the items that remain at exit" --- # What Is Cloud Computing The measure of on-demand resources: in the same 120-day demand curve, the time from capacity request to use dropping from 30 days to 1 day, unmet requests under the peak-forming load falling from 84,689 to 1,260 and the days capacity ran short dropping from 15 to 2, idle capacity falling from 764 to 254 unit-days, while under a flat load the requests saved stay at zero, and the eight items that remain at exit dropping to four. The previous curriculum did the same thing across eight courses: it took the machine, the network, storage, and the cluster one at a time, made a decision in each, and counted that decision's cost. All of those layers shared one silent assumption — the hardware had **already been purchased**. This lesson removes that assumption and asks a single question: which number changes if the same layers are **rented** instead of purchased. **Cloud computing** is the renting of computing resources **on-demand** instead of purchasing them, paying only for what is used. What renting is really selling is called **elasticity**: the ability to raise and lower capacity as demand changes. Elasticity is a layer above M19's **scaling** — scaling asks how many nodes will run, elasticity asks **how long** it takes to obtain that node. "The cloud is fast" carries no decision; the measure of speed is a duration, and that duration produces two costs. ## Elasticity Is a Number The example is the course's fictional **regional measurement network**: a service that collects water-meter readings, a service that validates the readings, billing and work-order services, a nightly batch job, and five teams. Both the network and the services are fictional. **CC1:** the model runs a 120-day window; the measured service is the reading collector. **CC2:** one capacity unit serves 1,200 requests per day. **CC3:** with own hardware, 30 days pass from capacity request to use, the smallest purchase is 4 units, and acquired capacity is never given back. **CC4:** under renting the same duration is 1 day, the smallest purchase is 1 unit, and capacity can be reduced in the same duration. **CC5:** if the highest demand of the last three days exceeds 85% of capacity, a capacity request is triggered; the target is that peak plus a 20% margin. **CC6:** unmet requests are the portion by which demand exceeds capacity; idle capacity is the portion by which capacity exceeds the required unit, and it is summed in unit-days. The demand curve and the two acquisition methods are a **model**; there is no real measurement network, real demand record, or real lead time. The generator for the daily wave is written in-house, and its seed is visible. ```js // cloud/demand.mjs — the fictional regional measurement network's demand curve and capacity // acquisition model (model): no real measurement network, demand record, or lead time exists. export const DAYS = 120; // the model runs a 120-day window export const UNIT = 1200; // one capacity unit serves 1,200 requests per day export const THRESHOLD = 0.85, MARGIN = 1.2; // once past the threshold, target = peak + 20% margin // the generator is written in-house, seed is visible: a linear congruential generator, only for the daily wave export function generator(seed) { let s = seed >>> 0; return () => ((s = (s * 1103515245 + 12345) >>> 0) % 1000) / 1000; } const BASE = { flat: () => 5000, peak: (d) => 5000 + (d >= 55 && d < 75 ? 13000 * Math.sin(((d - 55) / 20) * Math.PI) : 0), growing: (d) => 4000 + 90 * d, }; export function curve(name) { const r = generator(20260401); return Array.from({ length: DAYS }, (_, d) => Math.round(BASE[name](d) * (0.94 + 0.12 * r()))); } // mode: delay = days from capacity request to use, block = smallest purchase unit, shrink = can it be given back export const MODE = { own: { delay: 30, block: 4, shrink: false }, rent: { delay: 1, block: 1, shrink: true }, }; export function run(curveName, modeName, override = {}) { const T = curve(curveName), { delay, block, shrink } = { ...MODE[modeName], ...override }; const roundUp = (b) => Math.ceil(b / block) * block; let cap = roundUp(Math.ceil((Math.max(T[0], T[1], T[2]) * MARGIN) / UNIT)); const queue = []; // pending capacity requests const s = { requests: 0, wait: 0, short: 0, loss: 0, idle: 0, leased: 0, peakCap: cap }; for (let d = 0; d < DAYS; d++) { for (const i of queue.filter((x) => x.arrival === d)) cap = i.target; const window = Math.max(...T.slice(Math.max(0, d - 2), d + 1)); const target = roundUp(Math.ceil((window * MARGIN) / UNIT)); const pending = queue.filter((x) => x.arrival > d); const lastTarget = pending.length ? pending[pending.length - 1].target : cap; const grow = window > THRESHOLD * cap * UNIT && target > lastTarget; const cut = shrink && target < lastTarget && pending.length === 0; if (grow || cut) { queue.push({ arrival: d + delay, target }); if (grow) { s.requests++; s.wait += delay; } } const served = Math.min(T[d], cap * UNIT); if (T[d] > served) { s.short++; s.loss += T[d] - served; } s.idle += Math.max(0, cap - T[d] / UNIT); s.leased += cap; s.peakCap = Math.max(s.peakCap, cap); } return { ...s, wait: s.requests ? (s.wait / s.requests).toFixed(1) : "-" }; } // What remains at exit: "+" carries over, "-" embedded in the service, "none" the item does not exist in that form. export const EXIT = ` collected measurement data + + service configuration + + provisioning procedure + + operational information + + the hardware itself + none facility contract + none scaling decision + - measured performance history + -` .trim().split("\n").map((r) => { const p = r.trim().split(/\s{2,}/); const [a, b] = p[1].split(/\s+/); return { item: p[0], own: a, rent: b }; }); ``` ```js // cloud/measure.mjs — elasticity is a number: wait, unmet requests, idle capacity, exit. import { run, curve, EXIT, DAYS, UNIT } from "./demand.mjs"; const write = (w, ...s) => console.log(s.map((v, i) => (w[i] < 0 ? String(v).padEnd(-w[i]) : String(v).padStart(w[i]))).join("")); const CURVE = ["flat", "peak", "growing"]; const R = {}; for (const c of CURVE) for (const m of ["own", "rent"]) R[`${c}-${m}`] = run(c, m); const t = curve("peak"); console.log(`${DAYS}-day window, ${UNIT} requests/day per unit; the peak curve's ` + `lowest day is ${Math.min(...t)}, highest day is ${Math.max(...t)} requests`); const A = [-32, 14, 12]; console.log("\n1. same workload in the peak-forming curve, two acquisition methods"); write(A, "measure", "own hardware", "renting"); for (const [name, f] of [["capacity requests (count)", (r) => r.requests], ["request to use (days)", (r) => r.wait], ["days capacity ran short", (r) => r.short], ["unmet requests", (r) => r.loss], ["idle capacity (unit-days)", (r) => r.idle.toFixed(0)], ["peak capacity (units)", (r) => r.peakCap]]) write(A, name, f(R["peak-own"]), f(R["peak-rent"])); const B = [-10, 14, 13, 13, 12]; console.log("\n2. the same measure across three demand curves (loss = unmet requests)"); write(B, "curve", "own loss", "own idle", "rent loss", "rent idle"); for (const c of CURVE) write(B, c, R[`${c}-own`].loss, R[`${c}-own`].idle.toFixed(0), R[`${c}-rent`].loss, R[`${c}-rent`].idle.toFixed(0)); const C = [-10, 18, 21, 21]; console.log("\n3. what elasticity bought, and what was leased for it"); write(C, "curve", "requests saved", "leased unit-days", "requests / unit-day"); for (const c of CURVE) { const k = R[`${c}-own`].loss - R[`${c}-rent`].loss, bg = R[`${c}-rent`].leased; write(C, c, k, bg, (k / bg).toFixed(1)); } const E = [-24, 10, 12, 16, 16]; console.log("\n4. as lead time shortens (peak curve, 4-unit block, no giving back)"); write(E, "request to use (days)", "requests", "short days", "unmet", "idle unit-days"); for (const lead of [30, 14, 7, 3, 1]) { const r = run("peak", "own", { delay: lead }); write(E, lead, r.requests, r.short, r.loss, r.idle.toFixed(0)); } const D = [-30, 16, 12]; console.log("\n5. what remains at exit (8 items; none = the item does not exist in that form at all)"); write(D, "item", "own hardware", "renting"); for (const c of EXIT) write(D, c.item, c.own, c.rent); const count = (a, sym) => EXIT.filter((c) => c[a] === sym).length; write(D, "PORTABLE / EMBEDDED / NONE", `${count("own", "+")} / ${count("own", "-")} / ` + `${count("own", "none")}`, `${count("rent", "+")} / ${count("rent", "-")} / ${count("rent", "none")}`); ``` ``` 120-day window, 1200 requests/day per unit; the peak curve's lowest day is 4714, highest day is 18619 requests 1. same workload in the peak-forming curve, two acquisition methods measure own hardware renting capacity requests (count) 3 10 request to use (days) 30.0 1.0 days capacity ran short 15 2 unmet requests 84689 1260 idle capacity (unit-days) 764 254 peak capacity (units) 20 19 2. the same measure across three demand curves (loss = unmet requests) curve own loss own idle rent loss rent idle flat 0 459 0 204 peak 84689 764 1260 254 growing 32784 123 0 239 3. what elasticity bought, and what was leased for it curve requests saved leased unit-days requests / unit-day flat 0 705 0.0 peak 83429 892 93.5 growing 32784 1175 27.9 4. as lead time shortens (peak curve, 4-unit block, no giving back) request to use (days) requests short days unmet idle unit-days 30 3 15 84689 764 14 3 13 81223 953 7 3 8 38341 1001 3 3 4 7647 1024 1 3 0 0 1037 5. what remains at exit (8 items; none = the item does not exist in that form at all) item own hardware renting collected measurement data + + service configuration + + provisioning procedure + + operational information + + the hardware itself + none facility contract + none scaling decision + - measured performance history + - PORTABLE / EMBEDDED / NONE 8 / 0 / 0 4 / 2 / 2 ``` The numbers are in the **measurement** class; their inputs are CC1–CC6. The first table reduces elasticity to a single line: **30.0 days versus 1.0 day, request to use.** This one number determines everything else. ## The Cost of Waiting and Idle Capacity The thirty-day wait shows up in two places. In the peak-forming curve, own hardware opens three capacity requests, but by the time capacity arrives the peak has already passed: capacity **stays short for 15 days** and **84,689 requests go unmet**. Under renting the same curve produces ten capacity requests, each one coming into use the next day, and the short days drop from 15 to 2 and unmet requests drop to 1,260. The cause of the remaining 1,260 requests is not the lead time but the decision rule: after the threshold is crossed, a one-day wait still applies. The second cost runs in the opposite direction. Because own hardware cannot be given back, it stays on hand even after the peak has passed and produces **764 unit-days** of idle capacity; under renting the same figure is **254 unit-days**, because capacity comes back down. The peak capacities are nearly identical (20 versus 19); the difference is not in the size of the capacity but in **how long it is held**. The growing curve shows how these two costs trade places. There, own hardware's idle capacity is at its lowest (123 unit-days) — because it is constantly falling behind. That same lag produces 32,784 unmet requests. **Low idle capacity is not good news; it is another name for insufficient capacity.** Read separately, both costs mislead, but read together, they carry a decision. ## What Renting Costs You The third table ties elasticity's payoff to a single ratio: leased unit-days per request saved. In the peak-forming curve, renting saves 83,429 requests and does it with 892 unit-days of leasing — 93.5 requests per unit-day. In the growing curve the ratio drops to 27.9. **In the flat curve the ratio is 0.0.** Under a steady, predictable load, renting gains nothing from elasticity: both forms lose zero requests. The only difference in the table is in idle capacity (459 versus 204 unit-days), and that difference comes not from elasticity but from **the smallest purchase unit** — a four-unit block puts eight units on top of a 4.2-unit need. When the unit shrinks, the gap closes; as long as demand stays flat, renting's measured payoff is zero and all that is left in hand is decisions that have been handed over. This does not mean the cloud is "expensive"; it means **something whose measured payoff is zero does not have a cost of zero**. ## Is Shortening the Lead Time Enough The fourth table shortens only the lead time and leaves everything else under own hardware's rule: a four-unit block, no giving back. Unmet requests are 84,689 at 30 days, 81,223 at 14 days, 38,341 at 7 days, 7,647 at 3 days, and zero at 1 day. Halving the lead time does not halve the loss — the first step, from 30 to 14 days, erases only 4% of the loss, because the peak lasts twenty days and a fourteen-day delay still falls inside the peak. **The wait only gains meaning when compared against the width of the peak.** The idle capacity next to the same column runs the opposite direction: it climbs from 764 to 1,037 unit-days. Because capacity arrives earlier, it sits on hand longer, and because it cannot be given back, it stays there. Cutting the lead time to one day zeroes out unmet requests, but drives idle capacity up to 1,037 unit-days instead of renting's 254. **Elasticity is two separate decisions: how quickly capacity can be obtained, and whether it can be given back.** Without the second, the first only moves the cost around. ## What Remains at Exit The fifth table counts renting's silent item. Of the eight items, all eight remain in hand under own hardware. Under renting, four carry over (data, configuration, the provisioning procedure, operational information), two are embedded in the service (the scaling decision and the measured performance history sit inside the service), and two items **do not exist at all**: the hardware and the facility contract. The last two rows are both renting's gain and its cost. The absence of hardware is the reason the thirty-day wait disappears; that same absence also means there is no asset left to carry away on exit. The number of decisions handed over here is three — when to acquire capacity, how much to acquire, and where the hardware sits — and what is received in exchange is a single number: 30 days dropping to 1 day. This triple is the smallest form of the calculation that repeats through the rest of the course: an item is rented, a few decisions leave your hands, a number improves in exchange, and the item that must carry over at exit shrinks. What is being counted is nowhere "the cloud"; what is being counted is **which decision sits with whom**. ## Summary - Elasticity is a duration: 30.0 days versus 1.0 day, from capacity request to use. In the same peak-forming curve this difference drops the short days from 15 to 2 and unmet requests from 84,689 to 1,260. - Two costs are counted together: own hardware produces 764 unit-days of idle capacity, renting 254; the peak capacities, however, are nearly identical (20 versus 19). - In the growing curve, own hardware's idle capacity is at its lowest (123 unit-days), and that is exactly why 32,784 requests go unmet; low idle capacity is another name for insufficient capacity. - Elasticity's payoff is a ratio: 93.5 (peak), 27.9 (growing), **0.0 (flat)**, per unit-day. Under a steady load, the only remaining difference comes from the smallest purchase unit, not from elasticity. - Shortening the lead time alone drops the loss from 84,689 to zero, but idle capacity climbs from 764 to 1,037 unit-days; without the ability to give capacity back, speed only relocates the cost. - At exit, all eight items remain in hand under own hardware, but only four under renting; two are embedded in the service, two do not exist at all — and that same absence is the reason the wait disappears too. ## Next Step This lesson rented a single thing: capacity. Three decisions were handed over, and twenty-nine days were gained in exchange. Yet how much of what is rented gets handed over is not fixed; there is a large difference between renting only the machine and renting the machine together with the runtime that sits on top of it. The next lesson opens the same decision set item by item and counts, across three service models, **how many decisions are handed over, how many stay in hand**, and which of the handed-over decisions can be **taken back**.