Două articole despre cum GitLab a decis să renunțe la găzduirea în cloud în favoarea serverelor personale și provocările prin care trec.
The cloud hosting for GitLab.com excluding GitLab CI is currently costing us about $200k per month. The capital needed for going to metal would be less than we pay for 1 quarter of hosting. The hosting facility costs look to be less than $10k per month. If you spread the capital costs over 2.5 years (10 quarters) it is 10x cheaper to host your own.
Am avut si eu o experienta similara cu o aplicatia web, consumatoare de resurse. Mutat de pe un VPS pe o masina fizica pentru aproximativ aceeasi suma de bani si cu performante imbunatatite 3x.
Din pacate nu am vazut nici un hosting care sa garanteze un nivel minim de performanta pe partea de disk I/O la fel cum fac pentru memorie sau cpu. Cloudul ramane o optiune buna pentru workload care variaza foarte mult pe perioade scurte de timp (se poate merge si pe un model hibrid).
Sunt eu singurul caruia intreaga odisee a celor de la GitLab i se pare “amateur hour”?
“The cloud” nu e intotdeauna o solutie, dar cand companii precum Dropbox sau Netflix se gandesc la dc-urile proprii foarte tarziu, pare cam ciudat ca GitLab face asta cat inca sunt mici si start-up-ish. Pot reduce cei 200k lunar si prin alte metode - o mai buna utilizare a resurselor existente, cumparat de pe spot market/instante rezervate, negocieri mai dure ptr. resurse de la AWS, mutat la provideri cu masini dedicate etc.
Ambele discutii pe Hacker News arata ca e o chestie complexa - trebuie sa te gandesti nu numai la capacitatea hw, cat si la chestii precum power consumption, power efficiency, combinatii corecte de componente pentru workload-ul dat etc. Chestii pe care ei nu le adresasera in totalitate. Si pentru care iti trebuiesc oameni cu experienta si cu un skillset aparte. Degeaba dau 20k lunar in loc de 200k, daca trebuie sa mai angajeze 10 ingineri in SF/NY pe post de SRE/infrastructure engineer etc.
Apoi e alegerea lui Ceph ca sistem de fisiere distribuit. Care e un sistem experimental cu un big red warning pe prima pagina ca nu ar trebui folosit pentru stocarea datelor importante. < joke > Bine ca nu il folosesc decat pentru codul sursa al oamenilor < /joke >.
GitLab cere de la bun început 2Gb RAM, indiferent de numărul utilizatorilor.
- 1GB RAM + 3GB of swap is the absolute minimum but we strongly advise against this amount of memory. See the unicorn worker section below for more advice.
S-ar putea să fie mai ieftin să arunce hardware decât să optimizeze:
Si noi avem servere fizice, in datacenter, cumparate refurbished ce-i drept.
Costurile sunt incomparabil mai mici, la puterea de calcul pe care o detinem, fata de ce am fi platit in cloud.
E adevarat ca avem loc de manevra (practic resurse pe care le-am platit si nu le folosim inca), dar la un calcul simplu, a meritat efortul initial (si pe parcurs ca mai schimbam din ele).
Singurul dezavantaj pe care il vad la traba asta cu bare metal e ca de la un punct incolo incep sa crape componente (hdd-uri din ce am vazut pana acum) si ai ceva mai multa de bataie de cap cu inlocuirea lor. Dar treaba asta nu cred ca devine agasanta pana nu ai cateva zeci, poate sute, de masini fizice.
Noi folosim si si. Intern avem serverele noastre. Avem clienti carora le-am recomandat sa ia servere bare metal (au consum previzibil de resurse si ceva overhead sa creasca) si clienti pe care ii tinem in AWS (beneficiaza de pe urma flexibilitatii cand au spike-uri mari).
noua ne-au cazut mai degraba controllere. suspectam si 2 HDD-uri, dar s-ar putea sa le fi stricat controllerul. Altfel, nici un ssd pana acum.
daca ai spike-uri de moment, e clar ca e prea scump sa provizionezi hardware sa tina spike-urile alea si sa il tii degeaba in rest. Conteaza mult tipul de proiect, predictibilitatea, ritmul de crestere. Destui factori.
Cred ca pana la un anumit nivel cloudul este mai ieftin, apoi devine mai rentabil un datacenter propriu.
In plus si SLA-ul s-ar putea sa conteze, timpul de interventie fiind mai mic in cazul unui hardware propriu.
**cu condiția să ai cel puțin două rânduri de piese de schimb în orice moment.
La un alt proiect la care am participat sa decis recent mutarea de pe hardware fizic pe cloudul de AWS tot pe motiv de costuri 
(big data, hadoop, servere multiple pentru batch processing).
Apropo de AWS eu am auzit horror stories si cu ei, servicii care au incetat sa functioneze corect si daca ai o problema de genul acesta nu prea ai cu cine sa vorbesti, sunt probleme care afecteaza tot sistemul lor si pana sa faca push la o modificare care sa rezolve problema esti pe cont propriu.