Pageren kl. 3 om natten og prisen på en resize

Kl. 3.04 om natten. Pageren går i gang. CPU’en ligger klistret i loftet, køen hober sig op, og løsningen er oplagt og kedelig: boksen er for lille. Giv den flere cores.

Det gør du ikke. Du genstarter workerne, kaster noget trafik af, ser det humpe videre og opretter en ticket om at kigge på dimensioneringen i næste sprint.

Ikke fordi du er doven kl. 3 om natten. Men fordi en del af dig ved, at en resize koster mere, end den burde, og kl. 3 om natten er det den del af dig, der sidder og regner.

Opskalering er en finansiel beslutning. Det er buggen.

Se på, hvad en resize faktisk forpligter dig til under konventionel cloud-prissætning.

Timegranularitet. Du har brug for fyrre minutter af en større maskine. Du køber en time. Måske to, fordi grænsen lander skævt.

Skraldeeffekten. Du skalerer op under hændelsen, og ingen skalerer nogensinde ned igen. Boksen forbliver stor de næste fjorten måneder. Det er ikke inkompetence: at skalere ned betyder, at nogen skal være sikker på, at det er sikkert, i dagslys, med sit navn på ændringen. Ingen melder sig frivilligt til det. At skalere op er en nødsituation; at skalere ned er en risiko uden opside.

Forpligtelsen. Hvis instansen ligger under en reserved plan eller en savings-aftale, betaler du nu for den kapacitet, du forpligtede dig til, og for den on-demand-instans, du resizede til. Du bliver faktureret to gange for den samme løsning. Din fornuftige omkostningsoptimering fra sidste kvartal opkræver dig nu aktivt et gebyr for at reagere på en nedetid.

Så ingeniøren kl. 3 om natten regner på det, dårligt, på fire timers søvn, og konkluderer, at det er billigere at æde nedetiden.

Og her er den oprigtigt skræmmende del: de har som regel ret.

Nedetid er en omkostning. Den står bare ikke på fakturaen.

Fakturaen registrerer trofast de ekstra 4 dollars, du brugte på cores. Den registrerer ikke de fyrre minutters fejlede checkouts, det error budget du lige har sat ild til, de kunder der prøvede én gang og ikke kom tilbage, eller det faktum at din on-call-ingeniør nu er ubrugelig hele tirsdagen.

De omkostninger er fuldstændig reelle. De betales bare i en valuta, din økonomiafdeling ikke kan se på et kontoudtog — og derfor vinder den usynlige omkostning altid diskussionen mod den synlige kl. 3 om natten.

Det gjorde prissætningen. Ikke ingeniøren.

Hvad vi gør i stedet

Afregning pr. sekund, og ingen forpligtelser at vikle sig ud af. En resize koster det, den faktisk er værd: de sekunder du bruger den i.

Skalér op kl. 3 om natten. Skalér ned igen kl. 9, når du er vågen, har fået kaffe og kan læse grafen ordentligt. Du betaler for seks timer af en større maskine, og det er hele konsekvensen. Der er ingen timeoprunding at købe sig forbi, ingen reserved plan at afstemme, og ingen regning nummer to for kapacitet, du allerede havde lovet at købe — for du lovede aldrig at købe nogen.

En stoppet VM stopper med at fakturere compute. Sluk en maskine, og cores og RAM holder op med at koste dig i det øjeblik, den stopper — ikke først ved næste hele time.

Og så forbeholdet, fordi vi hellere vil have, at du hører det fra os end finder det på et kontoudtog: storage fakturerer videre, så længe disken findes. At stoppe VM’en gør ikke dens volume gratis. De bytes ligger stadig på vores diske, stadig reserveret til dig, og koster stadig os noget at holde på. Compute stopper. Storage gør ikke. Vil du have storage til at stoppe, må du slette volumet — og det bør du ikke gøre, før du har en backup, hvilket, som vi har skrevet andetsteds, ikke er det samme som et snapshot.

Intet af det her er en smart prisinnovation. Det er bare fraværet af det maskineri, der gjorde en resize dyr i første omgang. Fjern timeoprundingen, de flerårige forpligtelser og de rabat-tiers, du skal modellere i et regneark, og det, der er tilbage, er den kedelige sandhed: du lejer en maskine, du betaler for den tid, du havde den, du afleverer den igen.

Det rigtige træk kl. 3 om natten er at gøre maskinen større og gå i seng igen.

Din prismodel burde lade dig gøre det.