Hvorfor det er på tide å flagge hjem fra "the cloud"
Eller: Hvordan jeg lærte å slutte å bekymre meg og elske min egen serverhall igjen
Kjære medprogrammerere og arkitektkolleger,
La meg begynne med en bekjennelse: Jeg har vært sky-evangelisten som prekte fra scenen på konferanser om hvordan "cloud-first" var fremtiden. Jeg har solgt inn AWS, Azure og Google Cloud som løsningen på alle våre problemer. Men etter ti år i skyene har jeg kommet til en konklusjon som kanskje får noen til å rynke på nesa: Det er på tide å flagge hjem.
Historien om regningen som fikk meg til å våkne
Det begynte som en vanlig mandag morgen. Kaffen var fersk, dagslyset strømmet inn gjennom kontorvinduet, og jeg følte meg som den tekniske guruen jeg trodde jeg var. Så åpnet jeg månedsfakturaen fra AWS.
38 000 kroner. For én måned. For en applikasjon som tjente inn 15 000 kroner.
Jeg stirret på skjermen og tenkte at det måtte være en feil. Men nei – der var den, linje for linje: EC2-instanser som hadde skalert seg selv til himmels, RDS-databaser som kostet mer enn min første bil, og S3-lagringsgebyr som så ut som telefonnummeret til tante Astrid.
Det var øyeblikket da cloud-romantikken døde.
Den bitre sannheten om "elastisk" skalering
Vet dere hva som er elastisk? Gummistrikk. Og akkurat som en gummistrikk kan den snappe tilbake og treffe deg rett i ansiktet når du minst venter det.
Auto-scaling høres fantastisk ut på papiret. "Serverne tilpasser seg automatisk til trafikken!" sa vi. "Ingen mer kapasitetsplanlegging!" jublerte vi. Det vi glemte å nevne var: "Regningen tilpasser seg også automatisk – oppover."
Jeg husker spesielt én black friday da traffiken økte med 300%. Serverne skalerte opp som planlagt. Perfekt! Men de skalerte ned... tja, det tok litt tid. En uke, for å være presis. En uke med 20 servere når vi trengte tre. Det kostet mer enn hele årets markedsføringsbudsjett.
Mysteriet med de skjulte kostnadene
Cloud-leverandørene er som isfjell – det du ser på overflaten er bare en brøkdel av det som venter under. Data transfer ut? Det koster. API-kall? Det koster. Å se på serverne skjevt? Det koster sannsynligvis også det.
Jeg brukte en hel måned på å forstå forskjellen mellom "outbound data transfer" og "inter-region data transfer" og "same-zone data transfer". Det føltes som å lære latin, bare mindre nyttig og mer dyrt.
Og ikke få meg i gang på "reserved instances". "Forplikter dere til å bruke denne servertypen i tre år, så får dere 30% rabatt!" Høres ut som en god deal, inntil du innser at teknologien endrer seg hvert halvår, og den servertypen du bandt deg til blir utdatert før kontrakten er ferdig.
Den menneskelige faktoren
Her kommer kanskje den viktigste innsikten: Folk jobber annerledes når de ikke ser konsekvensene av valgene sine direkte.
Når utviklerne bare høyreklikker "create new instance" uten å tenke på kostnaden, når de bruker den største databasen som default fordi "det er bare lettere", når de setter opp staging-miljøer som kjører 24/7 selv om de bare brukes to timer i uka – da er det vanskelig å ha kontroll.
Med egne servere er det annerledes. Når team-et vet at den nye serveren må bestilles, godkjennes og fysisk installeres, blir de plutselig mye mer kreative med ressursbruken.
Kontrollen vi ga fra oss
Det er noe befriende med å ha fysisk kontroll over serverene dine. Du kan gå ned i serverhallen, se på dem, høre summen av viftene, føle varmen fra CPU-ene. Det høres romantisk ut, men det er mer enn nostalgi – det er kontroll.
Med cloud mister du kontrollen over hvor dataene dine lagres, når serverne oppdateres, og ikke minst: hva som skjer når leverandøren bestemmer seg for å endre prismodellen sin. (Spoiler alert: Det skjer oftere enn du tror, og det er sjelden til din fordel.)
Regnestykket som endret alt
La meg dele det regnestykket som fikk meg til å snu. Vår primære applikasjon kostet oss 480 000 kroner i året på AWS. Den kjørte på:
- 6 EC2-instanser (produksjon og staging)
- 2 RDS-databaser
- Diverse S3, CloudFront og andre tjenester
Jeg gjorde et raskt overslag på å kjøre det samme on-premise:
- 4 servere à 80 000 kroner = 320 000 kroner (engangsutgift)
- Internett og strøm: 60 000 kroner/år
- Lisenser og vedlikehold: 80 000 kroner/år
Første år: 460 000 kroner. Påfølgende år: 140 000 kroner.
Besparelsen etter tre år? Over 1 million kroner. Og det er uten å regne inn alle de ekstrakostnadene vi hadde fått på veien med cloud.
Det er ikke alt som skal hjem
La meg være klar på én ting: Jeg sier ikke at alt skal flyttes hjem. Cloud har sin plass. For prototyper, for tjenester med virkelig uforutsigbar trafikk, for startups som ikke har kapital til infrastruktur – der gir cloud absolutt mening.
Men for etablerte bedrifter med forutsigbare arbeidsbelastninger? Der hvor du kan planlegge kapasitet mer enn en måned frem i tid? Da er det verdt å vurdere den andre veien.
Veien hjem
Migreringen tilbake var ikke uten utfordringer. Vi måtte bygge opp kompetanse på drift igjen, investere i monitoring og backup-løsninger, og ikke minst – overbevise ledelsen om at vi ikke hadde blitt teknologiske ludditter.
Men etter seks måneder med egen hosting har jeg ikke sett en eneste overraskende regning. Jeg sover bedre om natten. Og når noen spør meg om cloud-strategi, svarer jeg: "Det kommer an på."
Konklusjonen
Cloud computing er ikke dårlig. Men det er ikke magisk heller. Det er et verktøy, og som alle verktøy må det brukes riktig og til riktige oppgaver.
Hvis du – som meg – har opplevd at cloud-regningene har tatt overhånd, hvis du føler at du har mistet kontrollen over infrastrukturen din, eller hvis du bare lurer på om det finnes en bedre måte å gjøre ting på, så kan det være verdt å vurdere den gamle skolen igjen.
Hjemme-serverne mine står der nede i serverhallen og summer fornøyd. De koster det de koster, ikke mer, ikke mindre. Og for første gang på mange år vet jeg nøyaktig hva jeg betaler for.
Kanskje det er på tide å flagge hjem, du også?
Med varme hilsener fra bunnen av serverhallen,
En arkitekt som kom hjem
P.S.: Hvis du vurderer å flytte tilbake, start småt. Ta ett system av gangen, mål kostnadene nøye, og husk at den største besparingen ofte ligger i å forstå hva du faktisk trenger – ikke i hvor du kjører det.