--- title: 'Service Models' source: 'https://academia.sh/en/courses/cloud-fundamentals/service-models' course: 'Cloud Fundamentals' language: en updated: '2026-09-13T05:07:33+00:00' license: 'CC BY-SA 4.0' objectives: - 'Builds a decision set and counts item by item how many decisions are handed over across three service models' - 'Separates handed-over decisions by recoverability: parameter, contract window, embedded in the service' - "Measures the handover's return by the operating touches it lifts, and its cost by the requirement requests it cannot meet" --- # Service Models The measure of infrastructure, platform, and software service: in a set of 26 decisions, decisions handed over climbing from 5 to 23 and 25, the yearly touches on kept decisions dropping from 91 to 82, 19, and 4, the share of handovers recoverable via a parameter falling from 40% to 39% and 12%, 6, 5, 4, and 1 of six requirement requests being met, and the carried-over decision share at exit dropping from 100% to 92%, 69%, and 35%. The previous lesson rented a single thing — capacity — and handed over three decisions. But the depth of renting is not fixed. Renting only the machine is not the same as renting the machine together with the runtime on top of it and its scaling behavior; the difference between the two is **how many decisions leave your hands**. This lesson counts that difference item by item. The depth of renting is named as three **service models**. **Infrastructure service** rents the machine, the storage, and the network; everything on top of that stays with the customer. **Platform service** also rents the runtime; the customer supplies the code and its configuration. **Software service** rents the work itself; the customer supplies only data and access decisions. These three definitions carry no decision on their own — what carries a decision is how the same decision set is split across the three models. ## The Decision Set The example is the course's fictional **regional measurement network**: the water-meter reading collector, the validator, billing and work-order services, a nightly batch job, and five teams. Both the network and the services are fictional; the decision set and service models below are a **model** — there is no real service catalog or real settings list. **CC7:** the decisions that must be made to keep the reading collector service running split into 26 items across ten domains. **CC8:** a decision either stays kept (`E`) in a given model or is handed over; a handed-over decision's recoverability falls into three classes — recovered via a parameter (`P`), waits on a contract window (`S`), embedded in the service (`G`). **CC9:** how many times a year each decision is touched is fixed. **CC10:** a requirement request is met the same day if the decision is `E`, in 1 day if `P`, in 30 days if `S`; if `G` it can never be met. These durations are fictional. **CC11:** every kept decision touch produces one operating item. **CC12:** at exit, every handed-over decision must be given back; those in class `G` additionally require a new solution in its place. ```js // cloud/decision.mjs — decision set and three service models for the fictional measurement // network (model): no real service catalog, real settings list, or real contract exists. No randomness. export const MODEL = ["own", "infrastructure", "platform", "software"]; // cell: E kept, P recovered via a parameter, S waits on a contract window, G embedded in the service export const WINDOW = { E: 0, P: 1, S: 30 }; // time to fulfill the request (fictional days) export const DECISION = ` hardware machine-model E P G G 2 hardware disk-type E P G G 2 hardware failure-replacement E G G G 3 facility physical-siting E S S G 1 facility power-and-cooling E G G G 1 operating-system distro-choice E E G G 1 operating-system version E E G G 2 patching security-patch E E G G 12 patching restart E E S G 6 runtime language-version E E P G 3 runtime library-version E E E G 9 runtime build-option E E S G 2 scaling threshold E E P G 4 scaling min-max E E P S 4 scaling shape E E G G 1 backup frequency E E P S 2 backup retention E E P S 2 backup restore-drill E E S G 2 monitoring metric-set E E P S 6 monitoring alert-threshold E E E P 6 network address-plan E E S G 1 network security-rule E E P S 9 network egress-path E E S G 2 identity user-directory E E P P 1 identity permission-model E E E E 4 identity session-duration E E P P 3` .trim().split("\n").map((r) => { const [domain, decision, ...k] = r.trim().split(/\s+/); return { domain, decision, touch: +k[4], cell: Object.fromEntries(MODEL.map((m, i) => [m, k[i]])) }; }); export const AREA = [...new Set(DECISION.map((k) => k.domain))]; export const count = (m, ...h) => DECISION.filter((k) => h.includes(k.cell[m])).length; export const touches = (m) => DECISION.filter((k) => k.cell[m] === "E") .reduce((a, k) => a + k.touch, 0); // Six requirement requests: each touches a single decision. export const REQUEST = [ ["upgrade the runtime version", "language-version"], ["lower the scaling threshold", "threshold"], ["extend backup retention", "retention"], ["change the egress path", "egress-path"], ["pin the operating-system version", "version"], ["shorten the failure-replacement time", "failure-replacement"], ].map(([name, decision]) => ({ name, decision, cell: DECISION.find((k) => k.decision === decision).cell })); ``` ```js // cloud/measure.mjs — how many decisions are handed over in three service models, how many come back. import { DECISION, MODEL, AREA, REQUEST, WINDOW, count, touches } from "./decision.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 LABEL = { own: "own hw.", infrastructure: "infrastructure", platform: "platform", software: "software" }; console.log(`decision set: ${DECISION.length} decisions, ${AREA.length} areas; ` + `${DECISION.reduce((a, k) => a + k.touch, 0)} total decision touches per year`); const A = [-18, 12, 16, 11, 10]; console.log("\n1. decisions kept per area (decisions in the area / kept)"); write(A, "area", ...MODEL.map((m) => LABEL[m])); for (const a of AREA) { const g = DECISION.filter((k) => k.domain === a); write(A, a, ...MODEL.map((m) => `${g.length} / ${g.filter((k) => k.cell[m] === "E").length}`)); } const B = [-30, 12, 16, 11, 10]; console.log("\n2. decisions handed over and whether they come back"); write(B, "measure", ...MODEL.map((m) => LABEL[m])); for (const [name, f] of [ ["decisions kept", (m) => count(m, "E")], ["decisions handed over", (m) => count(m, "P", "S", "G")], [" recovered via a parameter", (m) => count(m, "P")], [" waits on a contract window", (m) => count(m, "S")], [" embedded in the service", (m) => count(m, "G")], ["recoverable / handed over", (m) => `${count(m, "P")}/${count(m, "P", "S", "G")}`], ["kept touches per year", (m) => touches(m)], ["touches lifted per handover", (m) => (count(m, "P", "S", "G") ? (touches("own") - touches(m)) / count(m, "P", "S", "G") : 0) .toFixed(1)]]) write(B, name, ...MODEL.map(f)); const C = [-38, 12, 16, 11, 10]; console.log("\n3. can the six requirement requests be met (fictional days; - = cannot be met)"); write(C, "request", ...MODEL.map((m) => LABEL[m])); const time = (h) => (h === "G" ? "-" : WINDOW[h]); for (const i of REQUEST) write(C, i.name, ...MODEL.map((m) => time(i.cell[m]))); write(C, "requests met (out of 6)", ...MODEL.map((m) => REQUEST.filter((i) => i.cell[m] !== "G").length)); write(C, "total wait of the met ones", ...MODEL.map((m) => REQUEST.filter((i) => i.cell[m] !== "G") .reduce((a, i) => a + WINDOW[i.cell[m]], 0))); const D = [-38, 12, 16, 11, 10]; console.log("\n4. what is renegotiated at exit"); write(D, "measure", ...MODEL.map((m) => LABEL[m])); for (const [name, f] of [ ["decisions to renegotiate", (m) => count(m, "P", "S", "G")], [" needs a fresh solution (embedded)", (m) => count(m, "G")], [" carries over with the same setting", (m) => count(m, "P", "S")], ["carried-over decision share (%)", (m) => Math.round((count(m, "E", "P", "S") / DECISION.length) * 100)]]) write(D, name, ...MODEL.map(f)); ``` ``` decision set: 26 decisions, 10 areas; 91 total decision touches per year 1. decisions kept per area (decisions in the area / kept) area own hw. infrastructure platform software hardware 3 / 3 3 / 0 3 / 0 3 / 0 facility 2 / 2 2 / 0 2 / 0 2 / 0 operating-system 2 / 2 2 / 2 2 / 0 2 / 0 patching 2 / 2 2 / 2 2 / 0 2 / 0 runtime 3 / 3 3 / 3 3 / 1 3 / 0 scaling 3 / 3 3 / 3 3 / 0 3 / 0 backup 3 / 3 3 / 3 3 / 0 3 / 0 monitoring 2 / 2 2 / 2 2 / 1 2 / 0 network 3 / 3 3 / 3 3 / 0 3 / 0 identity 3 / 3 3 / 3 3 / 1 3 / 1 2. decisions handed over and whether they come back measure own hw. infrastructure platform software decisions kept 26 21 3 1 decisions handed over 0 5 23 25 recovered via a parameter 0 2 9 3 waits on a contract window 0 1 6 5 embedded in the service 0 2 8 17 recoverable / handed over 0/0 2/5 9/23 3/25 kept touches per year 91 82 19 4 touches lifted per handover 0.0 1.8 3.1 3.5 3. can the six requirement requests be met (fictional days; - = cannot be met) request own hw. infrastructure platform software upgrade the runtime version 0 0 1 - lower the scaling threshold 0 0 1 - extend backup retention 0 0 1 30 change the egress path 0 0 30 - pin the operating-system version 0 0 - - shorten the failure-replacement time 0 - - - requests met (out of 6) 6 5 4 1 total wait of the met ones 0 0 33 30 4. what is renegotiated at exit measure own hw. infrastructure platform software decisions to renegotiate 0 5 23 25 needs a fresh solution (embedded) 0 2 8 17 carries over with the same setting 0 3 15 8 carried-over decision share (%) 100 92 69 35 ``` The numbers are in the **measurement** class; their inputs are CC7–CC12. ## The Handover Is Not Linear The first table shows the handover domain by domain. Infrastructure service takes over only two domains — hardware and facility — completely; 21 decisions across the remaining eight domains stay kept. Platform service takes over eight more domains and leaves three items behind: the library version, the alert threshold, the permission model. In software service, a single decision remains — the permission model. The first two rows of the second table reduce this to a single number: decisions handed over **0 → 5 → 23 → 25**. The jump sits between infrastructure and platform; that single step hands over eighteen decisions. By contrast, the move from platform to software hands over only two more decisions. **The service models are not an evenly spaced staircase**; the biggest handover is the middle step, and that step is usually described as the easiest one to take. ## Can the Handed-Over Decision Be Taken Back The number of decisions handed over says nothing on its own; **the recoverability** of what is handed over is a separate item. In infrastructure, two of the five handovers are recovered via a parameter, one waits on a contract window, and two are embedded. In platform, of 23 handovers, nine are parameter, six are window, eight are embedded. In software, of 25 handovers only three are recovered via a parameter, and **seventeen are embedded**. The parameter ratio is 2/5, 9/23, and 3/25 in turn — roughly 40%, 39%, and 12%. In the first two steps the ratio stays nearly constant: platform hands over many decisions but gives back a similar fraction of them as a setting. In the third step the ratio drops to a third. **In software service, most of the handed-over decisions were not designed to be taken back**; what the service offers is precisely that the decision has already been made. What is received in exchange is in the last two rows. The yearly touches on kept decisions drop from 91 to 82, 19, and 4. Infrastructure service lifts only 10% of the touches — that is all handing over five decisions buys. Platform lifts 79% of them. Touches lifted per handover are 1.8, 3.1, and 3.5; by this measure, the least efficient step is infrastructure. The reason for the difference is visible inside the decision set. At 12 touches a year, the heaviest item is the security patch, and it stays kept under infrastructure service; the library version logs 9, the network security rule 9, the alert threshold 6, and the restart 6 touches. Yet the five decisions infrastructure hands over log a combined nine touches a year. **The weight of a handed-over decision is measured not by its count but by how many times a year it is touched**; handing over five decisions lifts nine touches, handing over eighteen decisions lifts sixty-three. ## When a Requirement Arrives The third table runs the same six requests across four setups. Under own hardware, all six are met the same day. Under infrastructure, five are met; the failure-replacement time is no longer the customer's decision. Under platform, four are met and the total wait climbs to 33 days — three at one day each, one at thirty days. Under software service **only one of the six requests** is met, and it too waits thirty days. This table says the opposite of the second table. Software service is the model that lifts the most touches per handover (3.5), yet that same model cannot meet five of the six requirements. **Lifting the operating load is paid for by failing to meet the requirement**; read separately, the two numbers make the same model look both the best and the worst. The 33-day wait under platform service is a separate item too. The decision is technically recoverable, but the speed of recovering it now belongs to the contract, not the customer. A number that was zero under own hardware climbs to thirty days once the decision is handed over. The most-touched items in the decision set carry extra weight when making the choice. If a team touches the alert threshold six times a year, whether that item is `E`, `P`, or `G` matters more than the other twenty-five decisions in the table combined. **The choice of service model is made not over the whole decision set, but over the tenth of that set that is touched most often**; the rest is noticed only once a year. ## What Is Given Back at Exit The fourth table counts the exit. The number of decisions to be given back at exit is the number handed over: 0, 5, 23, 25. Of these, the ones that carry over with the same setting are 3, 15, and 8; **the ones that need a new solution in their place** are 2, 8, and 17. The carried-over decision share drops from 100% to 92%, 69%, and 35%. The difference between platform and software is clearest here. The number of decisions handed over rises by only two, from 23 to 25, but the number embedded climbs from 8 to 17 and the carried-over share drops from 69% to 35%. **The exit cost is determined not by the number of decisions handed over, but by the recoverability of what was handed over.** ## Summary - In the 26-decision set, decisions handed over run 0 → 5 → 23 → 25; the biggest jump sits between infrastructure and platform (eighteen decisions), and the service models are not an evenly spaced staircase. - The share of handovers recoverable via a parameter is 2/5, 9/23, and 3/25; the ratio holds through the first two steps, drops to a third in software service, and 17 of the 25 handovers are embedded. - What is received in exchange is a drop in operating load: yearly decision touches run 91 → 82 → 19 → 4; touches lifted per handover are 1.8, 3.1, and 3.5. - The number of the six requirement requests that are met is 6, 5, 4, and 1; the total wait is 33 days under platform and 30 under software. The model that looks most efficient per handover cannot meet five of the requests. - The carried-over decision share at exit runs 100% → 92% → 69% → 35%; while only two more decisions are handed over from platform to software, the embedded count climbs from 8 to 17 — the exit cost is determined by recoverability, not by count. ## Next Step This lesson counted **how much** was rented and split the handed-over decision into three by recoverability. But every number so far came out under one silent assumption: the rented service is drawn from a pool open to everyone. Yet the same service type can also be built in a setup reserved for a single organization, or part of the workload can run in one and the rest in the other. The next lesson runs the same workload across three deployment setups and compares, item by item, **the item that stays under control, the fixed cost, the elasticity window**, and the constraint on where data can reside.