Gitlab ville droppe skyen - men eget datacenter blev for risikabelt

3. marts 2017 kl. 12:12
Gitlab ville droppe skyen - men eget datacenter blev for risikabelt
Illustration: Sergey Nivens/Bigstockphoto.com.
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.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

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.

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.

Artiklen fortsætter efter annoncen

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.

Ingen kommentarer endnu.  Start debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger