Skyfakturaen forklart og redusert
Skyfakturaen består i praksis av fire typer poster: regnekraft (servere som kjører koden din), lagring (databaser og filer), datatrafikk ut av skyen og ferdige tjenester. Den vokser sjelden på grunn av én dårlig beslutning, men på grunn av glemte miljøer og overdimensjonering. En gjennomgang hvert kvartal med de riktige spørsmålene holder den i sjakk.
En voksende skyfaktura uten en tydelig årsak er en av de vanligste kildene til ubehag for dem som betaler for driften. Hundrevis av linjer med kryptiske tjenestenavn, en sluttsum som kryper oppover, og ingen som helt kan forklare hvorfor. Men bak linjene finnes bare en håndfull poster. Når du forstår dem, kan du både budsjettere for driften og stille spørsmål ved den.
De fire postene du faktisk betaler for
Nesten alt på fakturaen kan sorteres i fire kategorier.
- Regnekraft. Servere, containere og funksjoner som kjører koden din. Nesten alltid den største posten. Prisen styres av hvor mye kapasitet du reserverer og hvor mange timer den er i gang, ikke av hvor mye den faktisk brukes.
- Lagring. Databaser, filer og sikkerhetskopier. Billig per gigabyte, men vokser jevnt fordi data sjelden slettes. Data som leses ofte, koster mer enn arkivdata som ligger urørt.
- Datatrafikk. Trafikk inn i skyen er som regel gratis, trafikk ut prissettes per gigabyte. Det er den posten som oftest forvirrer, særlig for produkter som leverer filer, video eller store API-svar.
- Ferdige tjenester. Administrerte databaser, køer, e-postutsendelser, AI-kall, overvåking. Praktiske byggeklosser du slipper å drifte selv, men hver av dem har sin egen prislapp, og det summerer seg.
Det meste av det som virker uforståelig på fakturaen, er egentlig bare én av disse fire, uttrykt med leverandørens produktnavn.
Et konkret eksempel
Si at du drifter en webapplikasjon: et par containere bak en lastbalanserer, en administrert database, fillagring og overvåking. Regnekraften er den tyngste posten. Databasen kommer deretter, som en ferdig tjeneste du betaler for å slippe å drifte. Lagringen er liten, men stabil. Så lanserer dere en eksportfunksjon som lar kunder laste ned store rapporter, og plutselig blir datatrafikken godt synlig, en post som knapt ble lagt merke til før. Ingen har gjort noe galt. En ny funksjon flyttet bare tyngdepunktet mellom postene, og uten oppfølging merkes det først på fakturaen.
Hvor sløsingen nesten alltid skjuler seg
Skykostnader øker sjelden fordi noen har tatt en dårlig beslutning, men fordi ingen har tatt noen beslutning i det hele tatt. De vanligste lekkasjene ser like ut overalt:
- Overdimensjonering. Kapasitet som ble bestilt for en topp som aldri kom, og som deretter aldri ble nedskalert.
- Glemte miljøer. Testoppsett, gamle disker og kopier som ingen har slått av. De fortsetter å bli fakturert hver måned, i det stille.
- Alt i gang døgnet rundt. Utviklings- og testmiljøer som kjører netter og helger selv om ingen bruker dem.
- Overraskende trafikk. En ny funksjon som sender mye data ut, uten at noen har regnet på hva det koster.
Det fine er at ingenting av dette krever en ombygging for å rettes opp. Det handler om oppfølging, ikke om arkitektur.
Spørsmålene du bør stille ved kvartalsgjennomgangen
Gjør en gjennomgang med leverandøren hvert kvartal, og ta med disse spørsmålene. De flytter samtalen fra en uforståelig totalsum til konkrete beslutninger.
- Hva er de tre største postene våre denne måneden, og hvorfor?
- Hvilke ressurser er i gang, men i praksis ubrukte? Kan de stenges eller nedskaleres?
- Kjører alle miljøer døgnet rundt, eller kan test og utvikling stenges utenfor arbeidstid?
- Har vi en forutsigbar grunnlast som det ville lønne seg å reservere i stedet for å betale per time?
- Hva førte til den siste økningen, og var den ventet?
- Finnes det glemte disker, øyeblikksbilder (snapshots) eller gamle kopier vi kan rydde bort?
En leverandør som bryr seg om relasjonen, svarer rett ut på dette. Får du bare et skuldertrekk og et «skyen er dyr», er det i seg selv et svar som er verdt å merke seg.
Skill mellom driftsgjennomgang og arkitektur
En kvartalsgjennomgang rydder og trimmer det som allerede finnes. Den løser ikke et oppsett som er feildimensjonert fra grunnen av. Det er et større arbeid som hører hjemme i arkitekturen, ikke i den månedlige oppryddingen. Blander man sammen de to, forventer man ofte at en gjennomgang skal halvere en faktura som egentlig er høy av strukturelle grunner. Vet du ikke hvilket tilfelle som er ditt, er det nettopp det spørsmålet en gjennomgang skal besvare.
Vi i Weapp jobber med skyarkitektur som en del av tjenestene våre og hjelper gjerne til med å tolke en faktura som har steget kraftig. Ta kontakt, så ser vi på den sammen.
Ofte stilte spørsmål
Hvorfor er datatrafikk en egen post på skyfakturaen?
Data inn i skyen er nesten alltid gratis, men data ut prissettes per gigabyte. Det kalles egress og overrasker ofte fordi det ikke er synlig i koden. En ny funksjon som eksporterer store filer eller strømmer video, kan derfor slå mer ut på fakturaen enn i utviklingsarbeidet.
Hva menes med overdimensjonering i skyen?
At du betaler for mer kapasitet enn du bruker. En server som ble bestilt for en trafikktopp som aldri kom, og som deretter aldri ble nedskalert, koster full pris døgnet rundt. Skyen fakturerer reservert kapasitet, ikke faktisk bruk, så ubrukt kapasitet er rent tap til noen aktivt skalerer den ned.
Hvor ofte bør vi gå gjennom skykostnadene?
Hvert kvartal er et fornuftig intervall for de fleste. Det er ofte nok til å fange opp glemte miljøer og løpsk trafikk før de har rukket å koste mye, men ikke så ofte at det blir en byrde. Ved rask vekst eller store endringer i produktet kan månedlig oppfølging lønne seg.
Hva er en normal skykostnad for et mindre produkt?
Et tidlig produkt med moderat trafikk klarer seg ofte med noen tusenlapper i måneden, noen ganger mindre med serverless. Det viktige er ikke et eksakt tall, men at kostnaden vokser i takt med bruken. En faktura som løper løpsk uten at trafikken gjør det, er et varselsignal som er verdt å grave i.
Kan vi redusere fakturaen uten å bygge om produktet?
Som regel, ja. Å nedskalere overdimensjonerte servere, stenge testmiljøer om natten, rydde opp i glemte ressurser og reservere kapasitet for forutsigbar last krever ingen ny arkitektur. Slike tiltak kan ofte fjerne en betydelig del av kostnaden uten at brukerne merker noe som helst.