Skyen er ikke alltid svaret

Det finnes en refleks i bransjen vår: Når noe skal skaleres, flytter vi det til skyen. Som regel er det et fornuftig valg, men ikke alltid – og det fikk jeg selv erfare da vi skulle gjøre lanseringene våre raskere, og ikke minst billigere.

Hver gang vi lanserer en ny funksjon eller retter en feil for en kunde, går koden gjennom en automatisk «produksjonslinje» før den blir synlig for brukerne. Den settes sammen, testes og publiseres til Microsoft Azure, skyplattformen der kundenes løsninger kjører. Jobben gjøres av en såkalt byggeserver, en datamaskin som ikke har noen annen oppgave enn akkurat dette.

Som de fleste andre leide vi denne kapasiteten i skyen hos GitHub, og betalte for hvert minutt maskinen jobbet. Ordningen fungerte godt nok, men én ting vi erfarte raskt: Jo mer vi leverte, desto dyrere ble det. I praksis straffet vi oss selv for å være produktive, og det er en dårlig mekanisme for et selskap som ønsker å levere ofte og raskt.

Billig, men for tregt

I stedet for å spørre hvordan vi kunne bruke mindre, begynte jeg å spørre om denne jobben i det hele tatt måtte ligge i skyen. Det første forsøket var beskjedent: Jeg tok utgangspunkt i en gammel server jeg hadde fått av broren min, og oppgraderte den med brukte deler fra Finn. Den var allerede i bruk til å bygge andre løsninger, så det skulle fungere greit her.

Det gikk ikke knirkefritt. Serveren gikk tom for minne og ga feilmeldinger jeg i starten ikke skjønte noe av, så jeg måtte gå gjennom tester, byggeprosess og oppsett fra bunnen av. Til slutt fikk jeg det til å fungere, men da brukte serveren 104 minutter på en jobb som skyen gjorde på 39. Denne store jobben påvirket da også alle andre løsninger som kjørte på serveren. Jeg hadde altså løst ett problem, men samtidig skapt nye. Det ble en nyttig påminnelse om at en rimelig løsning som er treg, egentlig ikke er noen løsning.

Fart var det vi trengte

Neste steg var å se på ferdige serverpakker fra leverandører, med garanti, support og service på stedet. Det var gode produkter, men de løste langt mer enn det problemet vi faktisk hadde. Det vi trengte, var fart. Derfor bygde jeg en maskin selv, skreddersydd for akkurat denne jobben.

I dag tar den samme jobben 14 minutter. Det er nesten tre ganger raskere enn skyløsningen og over sju ganger raskere enn det første forsøket. Like viktig er det at kostnaden ikke lenger øker i takt med aktiviteten, slik at vi kan lansere så ofte vi vil.

Det handler ikke om servere

Poenget mitt er ikke at alle bør bygge sine egne servere, for det bør de fleste ikke. Poenget er at også standardløsningen fortjener et kritisk blikk, på lik linje med alt annet vi gjør.

Det samme gjelder i kundeprosjektene våre. Når en nettbutikk går tregt, en integrasjon ikke spiller som den skal, eller et system blir dyrere enn det burde, ligger svaret sjelden i å gjøre som alle andre. Det ligger i å forstå hva problemet faktisk er, og deretter løse akkurat det.