Gitlab ville droppe skyen - men eget datacenter blev for risikabelt

Det var for dyrt at få løst behovet for bedre IOPS ved at skalere i skyen, men det var også for risikabelt at prøve at bygge sin egen infrastruktur. Caching bliver løsningen.

Skyen er en nem måde at få startet en tjeneste op og skalere den til at være global. Men kun op til et vist punkt. Det måtte Gitlab erkende, som derfor begyndte at lægge planer for at bygge sit eget datacenter.

Gitlab tilbyder hosting af kode til softwareudvikling samt en række værktøjer til at holde styr på kode-repositories ved hjælp af versionsstyringssoftwaren Git.

Som mange andre nyere it-virksomheder er Gitlab født på skyen, men i november var begrænsningerne ved skyen blevet så omfattende, at Gitlab gik i gang med at planlægge, hvordan selskabet kunne opbygge sin egen hardwareinfrastruktur.

Læs også: Sådan kommer du i gang med at lære Git

Problemet ved skyen er det samme, som gør skyen billig, nemlig at mange kunder kan deles om de samme ressourcer. Det er rigtig fint til virksomheder, hvor behovet er meget sporadisk, fordi man ikke har fysiske servere stående, som kører i tomgang.

I skyen kan andre kunder udnytte denne tomgang, og alle kunderne kan deles om driftsomkostningerne.

Skyen blev dyr

Men Gitlab havde nået en størrelse, hvor der konstant var et forholdsvis stort behov for at tilgå storage-systemerne, og vel at mærke tilgå systemerne hele tiden med stor belastning.

Dermed løb Gitlab ind i, at selskabets tjeneste blev nedprioriteret, når andre kunder havde storage-behov. Cloud-udbyderne forbeholder sig som regel retten til at kunne sætte en storforbrugende kunde bagerst i køen i perioder, så alle kunderne får mulighed for at dele ressourcerne.

Det kan man komme uden om ved at købe sig til flere ressourcer, men så begynder cloud computing at blive dyrt.

»På en lille skala er skyen billigere og effektiv. Men hvis du skal skalere op, så er det ikke så let. Det bliver ofte solgt som, at man bare kan tilføje flere maskiner, fordi skyen er 'uendelig'. Men vi fandt ud af, at der er punkt, hvor det bliver mindre effektivt og meget dyrt,« skrev driftsansvarlig Pablo Carranza fra Gitlab i november.

Gitlabs problem var, at det først og fremmest var ekstra IOPS, der var behov for, og det blev dyrt at skalere dem i skyen.

Samtidig har containere og micro services gjort det muligt at udnytte fysisk hardware i endnu højere grad, end det har været med virtuelle maskiner. Og Gitlab havde kig på Ceph og CephFS til et distribueret storagesystem.

Skrev ønskeliste på servere

Planen var at indkøbe den fysiske hardware, som ville understøtte behovene bedst, og placere de fyldte racks hos en co-location-udbyder, som kunne levere køling, strøm og internetforbindelser.

Men Gitlab også kortene på bordet og fik en masse input fra Gitlabs kunder og andre, som havde gjort forskellige erfaringer med henholdsvis at have egen hardwareinfrastruktur og løse problemerne i skyen.

Den diskussion er nu endt med, at Gitlab har droppet tankerne om egen hardware og i stedet arbejder på at løse problemerne på applikationslaget i skyen, specifikt ved at indføre et nyt caching-system, da de største IOPS-belastninger er læseoperationer.

Flere af kommentarerne til Gitlabs forslag om egen infrastruktur gav Gitlab ret i, at det var dyrt at forsøge at skalere ud over en vis størrelse i skyen. Men de pointerede også, at der kunne være problemer ved co-location, hvor der kunne opstå fysiske begrænsninger med plads til udvidelse.

Samtidig ville det også kræve, at man selv har kompetencerne til at løse eksempelvis problemer med netværket, påpegede én af brugerne i kommentarerne til Gitlabs forslag. Til gengæld får man muligheden for at løse mange problemer blot ved at tilføje mere eller kraftigere hardware.

I sidste ende endte Gitlab med at blive i skyen, blandt andet fordi flere af brugerne havde haft svært ved at bruge Ceph i praksis. Løsningen blev at udvikle en cache, som var særligt beregnet til brug med Git, hvorved Gitlab blev mindre afhængige af at skulle klare alle Git-kald som NFS-operationer.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (0)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Log ind eller Opret konto for at kommentere