Cloudregningen afkodet og sænket
Cloudregningen består i praksis af fire typer poster: beregning (servere der kører din kode), lagring (databaser og filer), datatrafik ud af skyen og færdige tjenester. Den vokser sjældent på grund af én dårlig beslutning, men på grund af glemte miljøer og overdimensionering. En kvartalsvis gennemgang med de rigtige spørgsmål holder den i skak.
En voksende cloudregning uden en tydelig årsag er en af de mest almindelige kilder til ubehag hos kunder. Hundredvis af linjer med kryptiske tjenestenavne, en slutsum der kryber opad, og ingen der rigtig kan forklare hvorfor. Men bag linjerne ligger der kun en håndfuld poster. Når du forstår dem, kan du både budgettere driften og stille spørgsmål ved den.
De fire poster du faktisk betaler for
Næsten alt på regningen kan sorteres i fire kategorier.
- Beregning. Servere, containere og funktioner der kører din kode. Næsten altid den største post. Prisen styres af hvor meget kapacitet du reserverer, og hvor mange timer den kører, ikke af hvor meget den faktisk bliver brugt.
- Lagring. Databaser, filer og backups. Billig per gigabyte, men vokser støt fordi data sjældent bliver slettet. Data der læses ofte, koster mere end arkivdata der ligger urørt.
- Datatrafik. Trafik ind i skyen er som regel gratis, trafik ud prissættes per gigabyte. Det er den post der oftest forvirrer, især for produkter der leverer filer, video eller store API-svar.
- Færdige tjenester. Managed databaser, køer, e-mailudsendelser, AI-kald, overvågning. Bekvemme byggeklodser du slipper for at drifte selv, men hver af dem har sit eget prisskilt, og de lægger sig oven i hinanden.
Det meste af det der virker uforståeligt på regningen, er i virkeligheden bare én af disse fire, udtrykt i leverandørens produktnavne.
Et konkret eksempel
Lad os sige at du drifter en webapplikation: et par containere bag en load balancer, en managed database, fillagring og overvågning. Beregningen er din tungeste post. Databasen kommer derefter, som en færdig tjeneste du betaler for så du slipper for selv at passe den. Lagringen er lille, men stabil. Så lancerer I en eksportfunktion der lader kunder downloade store rapporter, og pludselig står datatrafikken tydeligt frem, en post der knap blev bemærket før. Ingen har gjort noget forkert. En ny funktion flyttede bare tyngdepunktet mellem posterne, og uden opfølgning opdager man det først på regningen.
Hvor spildet næsten altid gemmer sig
Cloudomkostninger stiger sjældent fordi nogen har truffet en dårlig beslutning, men fordi ingen har truffet nogen beslutning overhovedet. De mest almindelige lækager ser ens ud overalt:
- Overdimensionering. Kapacitet der blev bestilt til en spidsbelastning som aldrig kom, og som siden aldrig blev skaleret ned.
- Glemte miljøer. Testopsætninger, gamle diske og kopier som ingen har slukket. De bliver ved med at blive faktureret hver måned, i det stille.
- Alt kører døgnet rundt. Udviklings- og testmiljøer der kører om natten og i weekenden selvom ingen bruger dem.
- Overraskende trafik. En ny funktion der sender store mængder data ud uden at nogen har regnet på hvad det koster.
Det gode er at du kan rette op på det hele uden en ombygning. Det handler om tilsyn, ikke om arkitektur.
Spørgsmålene til den kvartalsvise gennemgang
Lav en gennemgang med leverandøren hvert kvartal, og tag disse spørgsmål med. De flytter samtalen fra en uforståelig totalsum til konkrete beslutninger.
- Hvad er vores tre største poster denne måned, og hvorfor?
- Hvilke ressourcer kører, men er i praksis ubrugte? Kan de lukkes eller skaleres ned?
- Kører alle miljøer døgnet rundt, eller kan test og udvikling lukkes uden for arbejdstid?
- Har vi en forudsigelig grundbelastning som det kunne betale sig at reservere i stedet for at betale per time?
- Hvad drev den seneste stigning, og var den ventet?
- Er der glemte diske, snapshots eller gamle kopier vi kan rydde op i?
En leverandør der går op i relationen, svarer lige ud på det her. Får du bare et skuldertræk og et “skyen er dyr”, er det i sig selv et svar der er værd at notere.
Skil driftsgennemgang fra arkitektur
En kvartalsvis gennemgang rydder op i og trimmer det der allerede findes. Den løser ikke en opsætning der er fejldimensioneret fra bunden. Det er et større arbejde der hører hjemme i arkitekturen, ikke i den månedlige oprydning. Blander man de to sammen, forventer man ofte at en gennemgang skal halvere en regning der i virkeligheden er høj af strukturelle grunde. Ved du ikke hvilket tilfælde der er dit, er det netop det spørgsmål en gennemgang skal besvare.
Hos Weapp arbejder vi med cloudarkitektur som en del af vores ydelser, og vi hjælper gerne med at gennemgå en regning der er løbet løbsk. Kontakt os, så kigger vi på den sammen.
Ofte stillede spørgsmål
Hvorfor er datatrafik en særskilt post på cloudregningen?
Data ind i skyen er næsten altid gratis, men data ud prissættes per gigabyte. Det kaldes egress og overrasker ofte fordi det ikke kan ses i koden. En ny funktion der eksporterer store filer eller streamer video, kan derfor fylde mere på regningen end i udviklingsarbejdet.
Hvad menes der med overdimensionering i skyen?
At du betaler for mere kapacitet end du bruger. En server der blev bestilt til en trafikspids som aldrig kom, og som siden aldrig blev skaleret ned, koster fuld pris døgnet rundt. Skyen fakturerer reserveret kapacitet, ikke faktisk forbrug, så uudnyttet kraft er rent tab indtil nogen aktivt skalerer den ned.
Hvor ofte bør vi gennemgå cloudomkostningerne?
Kvartalsvis er et rimeligt tempo for de fleste. Ofte nok til at fange glemte miljøer og løbsk trafik før de har nået at koste meget, men ikke så ofte at det bliver en byrde. Ved hurtig vækst eller store ændringer i produktet kan månedlig opfølgning betale sig.
Hvad er rimelige cloudomkostninger for et mindre produkt?
Et tidligt produkt med moderat trafik klarer sig ofte med nogle tusinde DKK om måneden, nogle gange mindre med serverless. Det vigtige er ikke et præcist tal, men at omkostningen vokser proportionalt med forbruget. En regning der løber løbsk uden at trafikken gør det, er et advarselstegn der er værd at grave i.
Kan vi sænke regningen uden at bygge produktet om?
Som regel, ja. At skalere overdimensionerede servere ned, lukke testmiljøer om natten, rydde op i glemte ressourcer og reservere kapacitet til forudsigelig belastning kræver ingen ny arkitektur. Den slags tiltag kan typisk fjerne en betydelig del af omkostningen uden at brugerne mærker noget som helst.