GitLab si sposta da Azure a GoogleCloud

2

Appena dato l’annuncio dell’acquisizione da parte di Microsoft di GitHub, la paura, o anche solo l’antipatia, verso il nuovo padrone hanno creato una migrazione di massa: abbiamo assistito ad una vero e proprio esodo dei progetti ospitati. E molti hanno scelto il principale concorrente: GitLab.

Pochi, però forse, sanno che GitLab a sua volta si appoggia all’infrastruttura cloud di Microsoft, Azure: se l’obbiettivo era scappare dal nuovo padrone, in realtà ci si stava consegnando volontariamente, sebbene indirettamente.

Ecco perché l’annuncio del 25 Giugno fatto da GitLab potrebbe avere un risalto particolare: dal 28 Luglio (o giù di lì) lo stesso sarà migrato su piattaforma Google Cloud abbandonando Azure.
Il tempismo potrebbe essere sospetto, quasi ad arte, ma per poter migrare un portale ampio come GitLab serve tempo e preparazione: più di 200 TB di dati dei repository e 2 TB di database, il tutto a caldo, ovvero lasciando il sito principale attivo ed aperto all’uso durante tutto il processo.
Per permettere clonazione e sincronizzazione di sito primario (Azure) e secondario (Google) viene usato Geo, una tecnologia sviluppata da GitLab proprio per questi scopi e per cui questa migrazione rappresenta un test sul campo particolarmente gravoso ma interessante.

La motivazione principale può essere riassiunta in Kubernetes: in GitLab pensano che questa tecnologia sia l’unico modo per garantire il servizio ed aumentare la scalabilità dello stesso. E chi meglio di chi ha inventato Kubernetes per usarlo?
In parallelo GitLab cambierà anche la tecnologia di storage utilizzato, passando dal “solito” filesystem (NFS, considerato un single-point-of-failure) ad un sistema ad oggetti (il più famoso è S3 di Amazon, ma non è l’unico). Anche questo passaggio non è banale, e la sicurezza di non tralasciare nulla richiederà una certa cura.

Per chi volesse seguire da vicino i lavori è disponibile una pagina con tutti i dettagli del processo (ovviamente un repository Git su GitLab), da cui abbiamo conferma che il lavoro è stato avviato ben prima dell’acquisizione di GitHub (almeno 4 mesi fa). A voler essere cattivi, potremmo far notare che questo non implica non sia stato accelerato, però.

Ho coltivato la mia passione per l’informatica fin da bambino, coi primi programmi BASIC. In età adulta mi sono avvicinato a Linux ed alla programmazione C, per poi interessarmi di reti. Infine, il mio hobby è diventato anche il mio lavoro.
Per me il modo migliore di imparare è fare, e per questo devo utilizzare le tecnologie che ritengo interessanti; a questo scopo, il mondo opensource offre gli strumenti perfetti.

2 risposte a “GitLab si sposta da Azure a GoogleCloud”

  1. Avatar Kim ALLAMANDOLA

    Io penso che tanto GitHub (vecchia proprietà) quanto Microsoft, quanto Oracle, quanto GitLab quanto la Rossi&Bianchi snc siano AZIENDE PRIVATE il cui scopo è far soldi ed il cui mezzo per farli è il servizio che offrono. Nel FOSS al contrario l’obiettivo è far qualcosa di materiale/tecnico, non monetario, e lo strumento è la scrittura e condivisione di codice libero.

    Pertanto per me chi ha migrato da GitHub a GitLab motivando lo spostamento come reazione al cambio di proprietà è qualcuno che sarà pur tecnicamente una cima e molto noto ma che praticamente ha fette di prosciutto assai spesse sugli occhi.

  2. Avatar Kim ALLAMANDOLA

    Penso siano semplicemente ingenui. Adulti mantenuti bambini “cresciuti” dal sistema educativo e dalla società in cui sono nati&cresciuti. Non è un caso che nel mondo anglosassone, anglofono in particolare e nel mondo dell’Asia “progredita” si faccia di tutto, come in ogni dittatura, per educare fuori dal controllo delle famiglie con scuole “standard”…

    Molti sono talmente abituati ad avere Google sottomano che trovi hardcodato il ping a google.com per determinare se hai una connessione ad internet attiva… Molti sono talmente abituati ad avere Disqus o la propria (web)mail funzionante da restare sconvolti se una sera si trovano un 404 o altro errore davanti… Un tempo ci si pensava eccome e si pensava a come render tutto più robusto ed autonomo, ora si fa il contrario si torna a centralizzare come coi vecchi mainframe. Non molti anni fa si cercava di cachare il più possibile i siti web, adesso è normale comporre il proprio sito con tonnellate di servizi/codice di altri siti, addirittura se copi (e tieni aggiornato eh!) chessò mathjax in locale ti senti dire che stai *sprecando risorse*.

    Alcuni anni fa solo per citare un episodio ero ad una conferenza sul DevOps ed uno dei presentatori, sviluppatore&admin di una società non proprio piccola presentò il loro workflow: scaricavano immagini docker bell’e pronte da qualsiasi sito le offrisse, manco guardando se fossero aggiornate, manco cercando il dockerfile e poi buildarlo al volo. Quando nelle domande finale gli ho chiesto se non lo trova folle mi ha risposto che tanto non importa, *bisogna* fidarsi del prossimo, andare di corsa, c’è altro nella vita, … A me invece han sempre insegnato che (la necessità di) fiducia è una debolezza; che bisogna creare sistemi in cui si sia costretti a giocare onestamente non essendoci opzioni diverse…

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *