Drop dine right-sizing-regneark
Du overprovisionerede ikke, fordi du er dårlig til kapacitetsplanlægning. Du overprovisionerede, fordi prissætningen straffer dig for at gætte forkert, og den eneste billige fejl er at gætte for stort.
Tænk på incitamenterne. Gæt for småt, og din service vælter kl. 2 om natten, din pager går i gang, og en resize betyder et stop, en genstart og et vindue med nedetid, du selv skal planlægge. Gæt for stort, og du betaler en smule mere i timen, for evigt, og ingen lægger mærke til det. Den ene fejl vækker dig. Den anden dukker op som en afrundingsfejl på en regning, ingen læser linje for linje. Så alle runder op. De 30 % luft på hver eneste boks er ikke dovenskab — det er den rationelle reaktion på asymmetrisk smerte.
Katalog-labyrinten
Så er der kataloget. Du vælger ikke CPU og RAM. Du vælger en shape: et bogstav, et tal, et generationssuffiks, der koder et memory-til-core-forhold, du selv må regne baglæns ud fra en pristabel. Du har brug for 6 cores og 40 GB. Der findes ikke en 6-og-40. Der findes en 8-core/32-boks og en 8-core/64-boks, så du tager 64’eren og æder de cores, du ikke har brug for, eller du tager en memory-optimeret familie og æder de cores, du har brug for, til en højere pris.
Kataloget findes for at få et kontinuert problem — “hvor meget compute vil jeg have” — til at ligne en menu. Menuer er nemmere at prissætte og sværere at optimere. Det er hele pointen. Hver shape, du ikke kan få, er en shape, der skubber dig op til den næste, der koster mere.
Timeafregning belønner oprunding
Timeafregning gør arbejdet færdigt. En boks, der kører i 70 minutter, afregnes som to timer. Et batch-job, der tager 12 minutter, afregnes som en time. Så du holder op med at spinne ting op og rive dem ned igen, fordi granulariteten gør kortvarigt arbejde dyrt. Du lader boksen køre. Du beholder luften. Afregningsintervallet træner dig stille og roligt til at behandle engangs-compute som permanent.
Og så autoscaling, til at fikse det prissætningen ødelagde
Autoscaling sælges som svaret, men se på, hvad det i virkeligheden er: et kontrolsløjfe, du nu selv skal drive for at undvige en prismodel. Du skriver scaling-policies. Du tuner cooldowns, så du ikke hakker frem og tilbage. Du modellerer opvarmningstid, så nye instanser er klar, før belastningen rammer, hvilket betyder, at du præ-provisionerer for at skalere, hvilket er oprunding i forklædning. Du tilføjer en load balancer, health checks og et dashboard til at holde øje med den autoscaler, du byggede for at holde øje med belastningen. Kompleksitetsskatten er reel, og du betaler den i ingeniørtimer for at spare penge, som prissætningen tog i første omgang.
Hvad vi gjorde i stedet
Vi mener, at det meste af det forsvinder, hvis prissætningen holder op med at straffe præcision. Derfor afregner Kaligon Cloud pr. sekund, og sekund-måleren er loftlagt månedligt — efter cirka 730 timer stopper måleren, så en boks, du lader køre, simpelthen lægger sig på en fast månedspris. Et 12-minutters job koster 12 minutter. Ingen oprunding til to timer, ingen grund til at lade ting stå tændt.
Der er intet instanskatalog. Du sætter cores og RAM, hvor du vil have dem — 1 til 96 vCPU’er, 1 til 512 GB — og du kan hot-resize en kørende boks i stedet for at gætte ved oprettelsen og leve med det. Træk i sliderne på pris-konfiguratoren, og estimatet opdateres undervejs, så du dimensionerer mod et reelt tal og ikke et regneark, du genopbygger hvert kvartal.
Én fast pris pr. ressource. Ingen reserved tiers, ingen spot-budgivning, ingen committed-use-rabatter at fremskrive tre år ud i fremtiden. Pointen er ikke at være smart med omkostningerne — det er at gøre det ærlige gæt til det billige. Provisioner det, du har brug for, resize når du gætter forkert, og betal for det, du brugte, i stedet for det, du var bange for, at du måske fik brug for.
Du kan slette dit right-sizing-regneark. Vi ville alligevel aldrig have læst det.