What Is Cloud Computing

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.

// 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 };
  });

// 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.