Platformot farag a Microsoft a GitHubból

Szűk körű sajtótájékoztatón részletezte a Microsoft San Franciscóban, hogy milyen tervei vannak a nemrég felvásárolt GitHubbal. A leglényegesebb: a szolgáltatásból platformot farag az új tulajdonos, amelyre fejlesztői eszközök és megoldások széles tárháza épülhet majd. Az átalakulás persze nem most indult, a GitHub 2014-ben rajtolt API-készlete már évek óta ebbe az irányba húzza a szolgáltatást, erre a Microsoft azonban rá szeretne erősíteni.

Rebuilding in progress

A GitHub egy jelentős átépítés közepén jár - a Microsoft-felvásárlástól függetlenül, tavaly megkezdett munka nagy része még hátravan. A nagyívű fejlesztés során a GitHub kódja és architektúrája is alapos ráncfelvarrást kap, az új elemek pedig már nem a Ruby on Rails keretrendszert használják, helyette inkább Go, Java és némi Haskell kerül a kódba. Az infrastruktúra oldalán a csapat igyekszik modern, composable, konténeres architektúrát építeni, amely jobban skálázódik a megnövekedett igényekkel.

Ez nem öncélú újraírogatás, a döntés mellett komoly üzleti érvek vannak: a GitHub fejlesztői platformmá válásához sokkal több belső képességet akar kifelé is elérhetővé tenni. "A monolitunkat kezdjük darabokra törni és az egyes elemeket szolgáltatássá absztrahálni. Ehhez pedig a Kubernetes platformot választottuk." - idézi a The Register Sam Lambertet, a platformigazgatót.

A Kubernetes bevezetése egyébként nem vezetett kevesebb elálláshoz, mondja Lambert, nem a megbízhatóságot javította, hanem az üzemeltetés és a belső fejlesztők hatékonyságát. A konténermenedzsert a GitHub nem "nyersen" fogyasztja, épített hozzá egy saját eszközt a Moda formájában, amely megkönnyíti az üzemeltetést. A tervek szerint ezt és néhány másik belső eszközt a csapat hamarosan nyílt forrásúvá teszi, így mások is felhasználhatják (és persze fejleszthetik is).

Egyelőre nem lesz Azure-beköltözés

Az elejtett információk között érdekes morzsa, hogy a GitHub nem igazán támaszkodik a nyilvános felhős infrastruktúrára. A rendszerben van helye publikus felhőnek, de igazából csak terhelési csúcsok idejére veti be a platform, egyébként saját adatközpontjait használja a szolgáltatás nyújtására. Ehhez is egy érdekes megoldást vet be a csapat, a nagyobb városoknál a hálózati szolgáltatók adatközpontjaiban üzemeltet hálózati belépési pontokat, amelyeket bérelt optikai hálózaton (dark fiber) köt össze saját, távolabbi adatközpontjaival, ahol a tulajdonképpeni számítási és tárolós kapacitás nyugszik - mondja Lambert. A megközelítés nagy előnye, hogy a városoktól távol kimondottan olcsón működtethetőek a saját adatközpontok, a GitHub szerint akár 70 százalékos a megtakarítás, miközben késleltetésben 1-2 ezredmásodpercet kell "megfizetni".

És miért utasítja el mereven a publikus felhőt a GitHub? Mert a tipikus számítási feladat nagyon nem passzol a felhős üzleti modellhez, amelyet a szolgáltatók a tipikus, átlagos feladatokhoz szabnak, a nagyon egyedi feladatokat így nem tudja jól kiszolgálni. A GitHub pedig egyedi: kódja nagyon I/O és tárolóigényes, amiért rengeteget kellene fizetni a publikus felhőben. A saját adatközpont pedig lehetővé teszi, hogy a cég egészen egyedi rackeket használjon, illetve mélyen belenyúljon a Linux kernel működésébe is a hatékonyabb működés érdekében. Emiatt egyelőre nem is tervezik a teljes beköltözést az új tulajdonos Azure felhőjébe sem.

Nagy pénz, nagy szívás: útravaló csúcstámadó IT-soknak Az informatikai vezetősködés sokak álma, de az árnyoldalaival kevesen vannak tisztában.

Az egyediségnek is van persze határa, mondja Lambert, a cég például nem használ egyelőre egyedi tervezésű szervereket, ahhoz, hogy ez kifizetődő legyen, néhány nagyságrenddel több szerverre lenne szükség. Így a testreszabás egyelőre kimerül abban, hogy a nagyvállalati beszállítóknak egyedi megrendeléseket ad le a csapat.

A publikus felhő felé sem teljes az elzárkózás. A már említett termelési csúcsok mellett bizonyos szolgáltatásokra nagyon jó a cloud. Lambert az AI-t emlegeti, amelyben a GitHub is sok fantáziát lát, az algoritmusok hatékony futtatásához azonban dedikált gyorsítókra, GPU-kra, TPU-kra van szükség. Ezeket egyelőre inkább nyilvános felhőből veszi igénybe a csapat, majd ha elkezd felskálázódni a használat, akkor lesz lehetőség visszaemelni ezt saját adatközpontba.

És mire jó a varázslatos AI egy olyan szolgáltatásban, mint a GitHub? Első körben a snippetek gyors kikeresésére alkalmas: például a hatalmas kódbázisból gyorsan meg tudja keresni, hogy mely kódrészlettel lehet kapcsolódni egy adatbázishoz. A másik nagy segítség a fejlesztői környezet bukkanóinak egyengetése lenne - Lambert szerint ma a fejlesztők idejük 50 százalékát a különböző nem-fejlesztési feladatokkal (saját környezetük telepítése-konfigurálása-karbantartása) töltik, ebből bőséggel lehetne faragni.