Gli sviluppatori di Facebook, Google e del nostro team Webmail raggruppano il loro codice in un unico repository dove le dipendenze sono condivise (è il monorepo o mono-repository). AWS, Leboncoin.fr e gli altri team Infomaniak segmentano il loro codice in repository indipendenti con piccoli team autonomi (stiamo parlando del multirepo o “multiple repository”). Scegliere un metodo di gestione del codice è una decisione strategica per l’azienda, a prescindere dalle sue dimensioni. Come definire la propria strategia e con quali impatti? In questo articolo, condividiamo con te la nostra esperienza per fare la scelta migliore basandoci su un esempio concreto: l’evoluzione dei nostri servizi di hosting Web.

Dal monorepo al multirepo: l’evoluzione dell’hosting Web di Infomaniak

Hosting V1: l’offerta di hosting unica di Infomaniak

Alla fine degli anni ’90 viene lanciata la piattaforma Hosting V1. È la prima offerta storica di hosting di Infomaniak.

Questa prima piattaforma è basata su un’architettura monolite, il che significa che l’intera applicazione è sviluppata come un unico blocco software. Al momento della sua creazione, questa architettura è lo standard nel nostro settore nascente. È adatta alle esigenze del team di sviluppo e ai nostri volumi di traffico più bassi e offre al tempo stesso una buona velocità di sviluppo.

Hosting V2: l’hosting Web e WordPress attuale

Nel 2013 lanciamo la piattaforma Hosting V2, la nostra attuale offerta di hosting. Essa si basa anche su una API monolitica comune a tutti i prodotti Infomaniak.

In questo periodo, l’architettura dei microservizi inizia a diffondersi a ritmo crescente, ma decidiamo di non adottarla subito per questa nuova piattaforma. Ciò avrebbe comportato una notevole evoluzione delle pratiche:

  • ripensare a fondo il codice,
  • modificare i metodi di implementazione e osservabilità,
  • adattare numerosi processi e
  • formare le persone.

Uno stravolgimento prematuro, perché all’epoca gli strumenti per implementare un’architettura di questo tipo erano insufficienti. Aggiungevano più complessità di quante ne potessero eliminare per un team delle dimensioni di Infomaniak.

Nel 2024, con un organico 6 volte superiore a quello di allora, sono possibili nuove prospettive e si fanno sentire nuove esigenze.

Hosting V3: la prossima piattaforma di hosting di Infomaniak

La futura piattaforma di hosting è in pieno sviluppo e sarà basata su un’architettura multi microservizi.

È una fase di transizione ambiziosa e complessa che consentirà di rispondere alle sfide del futuro e creare nuovi servizi di hosting. Questa evoluzione sarà totale e riguarderà sia l’interfaccia che l’architettura cloud in background.

Vogliamo mantenere la nostra capacità di trasformare rapidamente le nostre idee in prodotti per i nostri clienti. Questa nuova architettura offre la velocità necessaria per accompagnare la crescita e anticipare le esigenze future.

Julien Viard, VP of Engineering presso Infomaniak

Attuazione della transizione da Monorepo a Multirepo

Un’architettura monorepo con Hosting V2…

Con la crescita di Infomaniak, la creazione di nuovi prodotti e l’ampliamento dei nostri team, l’architettura monolitica inizialmente scelta per Hosting V1 e Hosting V2 sta mostrando i propri limiti. Essa risponde sempre meno alla nostra struttura organizzativa e alle esigenze attuali. Ecco perché stiamo sviluppando la futura piattaforma di hosting (Hosting V3) con una nuova architettura di microservizi.

Tecnicamente, ecco come appare (in modo semplificato) l’architettura monorepo della piattaforma Hosting V2:

Questo schema rappresenta la relazione tra i diversi servizi delle nostre soluzioni di hosting.
Questo schema rappresenta in modo semplificato la relazione tra i servizi principali delle nostre soluzioni di hosting.

Su questo schema:

  • Innanzitutto, si osserva che il Manager Infomaniak è il monolite utilizzato sul lato front-end. Esso gestisce l’intero aspetto visivo della gestione dei prodotti Infomaniak. Il Manager è connesso a tutte le nostre API e consente ai nostri clienti di disporre di un’unica interfaccia per gestire tutti i loro servizi. Con l’architettura in uso, ogni aggiornamento di un servizio di hosting ha un impatto su tutti gli altri prodotti, il che richiede una politica di aggiornamento molto rigorosa per non mettere a repentaglio la stabilità dell’intero Manager per i clienti.
  • Infomaniak Legacy (ovvero il codice “originale” o “storico” che è diventato obsoleto o difficile da mantenere) contiene una gran parte del codice Legacy Hosting e del codice Legacy General Infomaniak: tutto questo codice è al momento all’interno dello stesso progetto. Come per la parte front-end, gli aggiornamenti del monolite Hosting back-end hanno un impatto sull’intero codice Legacy Infomaniak relativo all’insieme dei servizi, riducendo quindi la velocità dei nostri team prodotti.
  • Infomaniak Core è un microservizio che contiene varie funzionalità trasversali, come il recupero di un profilo utente.

In sintesi, questa architettura complica l’aggiornamento di una parte dei servizi senza incidere sulla totalità dei progetti, il che ha un impatto negativo sulla velocità di un ecosistema che vede al suo interno molte interdipendenze. I due grandi monoliti Manager Infomaniak e Infomaniak Legacy sono di difficile evoluzione poiché hanno un impatto su tutti i nostri servizi, mentre con la revisione in corso (Hosting V3) avremo diversi microservizi più facili da aggiornare.

Un’architettura monolite è come un edificio: se cambi il riscaldamento, influisci sull’intera struttura. I microservizi sono come le case unifamiliari: se cambi il riscaldamento di una casa, non produci alcun effetto su quelle accanto.

Matthieu Mabillard, Team Lead Developer

…a un’architettura multirepo con Hosting V3

Hosting V3 è una rielaborazione profonda della nostra architettura.

Questo schema riassume in modo semplificato il funzionamento della nuova piattaforma di hosting in fase di sviluppo:

Con questa nuova architettura:

  • Si osserva in primo luogo che la parte front-end dei servizi di hosting è adesso dissociata dal Manager Infomaniak per facilitarne lo sviluppo.
  • Hosting Legacy recupera e isola il codice storico del vecchio monolite Infomaniak Legacy. Questo codice è stato modernizzato in un microservizio per consentirne una più facile gestione, ma non completamente riscritto.
  • Il proxy è quello che si occupa di tradurre l’autenticazione del cliente al Manager per consentirgli accessi sicuri e personalizzati. È il punto di ingresso di tutte le interazioni.
  • API Hosting contiene il nuovo codice della nuova piattaforma di hosting V3. La sua funzione è inviare le informazioni a Legacy General Infomaniak o API Legacy Hosting qualora rilevi che le richieste corrispondono a funzionalità non sottoposte a ulteriore sviluppo.
  • La gestione dei certificati SSL (SSL Certificates) è isolata all’interno di un microservizio per facilitarne lo sviluppo e l’integrazione in tutti i servizi.
  • Infomaniak Legacy contiene sempre le dipendenze del monolite Infomaniak per le funzionalità trasversali.
  • Il microservizio di autenticazione degli utenti (OAuth2.0) rimarrà invariato.
  • Troviamo anche il microservizio Infomaniak Core che riunisce più funzionalità come il recupero del profilo di un utente.

Questa suddivisione in microservizi consente di ridurre le dipendenze tra i microservizi e di tenere sotto controllo il debito tecnico. Abbiamo il controllo totale dell’implementazione e del ciclo di vita del nostro codice, sia esso quello nuovo o il legacy. Questo approccio ci consente di vivere con un modello ibrido che coniuga velocità e scalabilità.

Questa architettura brilla in ambienti caratterizzati da un’esecuzione altamente distribuita. Offre elevata resilienza, grande ridondanza e grande capacità di adattamento alle variazioni di carico.

Matthieu Mabillard, Team Lead Developer

Passare dal monorepo al multirepo: l’importanza di preparare adeguatamente i propri team

Nell’ambito di questa transizione, stiamo mettendo in atto misure per favorire l’adozione di standard comuni tra i team e rafforzare gli scambi tra gli specialisti con:

  • Associazioni di competenze esterne alla gerarchia che consentono la condivisione delle conoscenze tra gli esperti in modo trasversale a livello di piattaforma degli sviluppatori. Discutono argomenti come API, DevOps, Laravel, Angular.
  • Direttive di qualità per armonizzare le pratiche tra i team con criteri standardizzati. Questo punto è collegato alle nostre norme ISO 9001, ISO 14001, ISO 50001.
  • La responsabilità dei Team Lead che hanno la direzione operativa di tutti i microservizi del loro team. Ciò rafforza l’autonomia e la responsabilità dei team. La direzione tecnica è pertanto esonerata e può dedicarsi interamente alla strategia, alle tecnologie, all’attuazione delle buone pratiche, alla supervisione e all’affiancamento.
  • La realizzazione di strumenti di auditing (SonarQube, Renovate, Gitlab CI) per avere una vigilanza su tutte le entrate che vengono generate ed essere in grado di monitorare lo stato dei repository nel loro insieme.

Monorepo vs multirepo: una scelta strategica per l’azienda

Il metodo di gestione del codice ha importanti implicazioni di difficile valutazione. È quindi necessario riflettere attentamente, prima di prendere una decisione e definire una strategia.

I vantaggi dell’approccio Multirepo

Nel contesto della futura piattaforma di hosting, l’approccio Multirepo consente di utilizzare le tecnologie più recenti senza dover attendere l’aggiornamento di altri progetti dell’azienda. Anche la gestione dei diritti è più precisa: l’accesso al codice di base è controllato accuratamente, anche in lettura. Si sa con esattezza “cosa tocchi a chi”, il che facilita il trasferimento di responsabilità di un microservizio da un team all’altro e anche la ristrutturazione del polo DEV.

L’architettura multirepo consente ai team di specializzarsi ulteriormente, suddividendo chiaramente le responsabilità e associando tecnologie specifiche ad ogni progetto.

Matthieu Mabillard, Team Lead Developer

Si ottiene una maggiore autonomia dei team: la suddivisione delle responsabilità migliora l’efficienza dei team che possono concentrarsi sul proprio microservizio perché il loro repository è indipendente dagli altri. È un guadagno di libertà sotto vari punti di vista:

  • ciclo di vita,
  • reclutamento specifico,
  • scelte tecnologiche.

È anche più facile sperimentare nuovi progetti: il multirepo accelera lo sviluppo di proofs of concept (POC), che possono essere realizzati indipendentemente dagli altri settori. Questo consente di convalidare rapidamente la fattibilità di un’idea. Ogni progetto ha una sua velocità: ogni servizio del team Hosting può accelerare o ottimizzare il proprio ciclo di sviluppo, avere i propri criteri di accettazione, il tutto senza essere frenato dall’impatto che potrebbe avere sugli altri.

Il multirepo facilita i contributi open source: il codice base viene ridotto e la segmentazione dei servizi consente di pubblicare alcune parti del codice e non altre, ad esempio per motivi di sicurezza o di tutela del know-how (segreto) industriale.

Questo approccio accelera i cicli di sviluppo: la produzione è più breve rispetto ai nostri progetti monorepo. Nell’Hosting V3, ogni componente viene disaccoppiato mentre la build della Webmail in monorepo è più lunga.

Questa scelta può avere un impatto importante anche sul reclutamento:

Avere stack tecnologici attraenti con una curva di apprendimento ragionevole è un fattore determinante per attrarre talenti. Nessuno è attratto da un’azienda che incrementa il debito tecnico con tecnologie che non vengono insegnate da nessuna parte.

Julien Viard, VP of Engineering presso Infomaniak

I limiti di un approccio Multirepo

Il multirepo richiede più rigore per sincronizzare l’evoluzione di un microservizio rispetto agli altri:

  • Occorre aggiornare sistematicamente le dipendenze del proprio progetto in modo che possa beneficiare di aumenti di qualità del codice dei sottoprogrammi o di correzioni dei difetti, ecc. utilizzando la libreria giusta, la parte di codice giusta, ecc. Occorre ad esempio assicurarsi che due API mantengano una base comune se funzionano in modo simile utilizzando lo stesso microservizio di autenticazione.
  • L’implementazione dei test di integrazione è più complessa e richiede scenari in cui diversi microservizi possano comunicare tra loro. Ad esempio, un cliente esegue una sola operazione per creare un sito Internet dando però luogo a 3 azioni sul lato Hosting: API SSL, immagine di anteprima, API Hosting.
  • Dato che il codice è segmentato, è più difficile avere una tracciabilità e un feedback permanente sull’intero codice.
  • La granularità rende il rilevamento dei problemi più difficile, perché i microservizi devono essere controllati uno ad uno. È invece più facile agire, poiché spesso la correzione da apportare è meglio delimitata.
  • Infine, il mantenimento della sinergia tra tecnologie, librerie e pratiche di sviluppo richiede maggiori competenze.

Monorepo vs multirepo: qual è la scelta giusta per i tuoi team di sviluppatori?

Questa scelta richiede una riflessione interna su diversi punti:

  • Qual è il profilo della tua azienda? Per una start-up con un time to market breve, non è facile adottare un’architettura di microservizi che richiede molto tempo per essere implementata. Spesso è necessario lanciare un prodotto il più rapidamente possibile e quindi scegliere strategicamente la soluzione che porta alla massima velocità di sviluppo.
  • Di quale velocità hai bisogno?
  • Quali sono le tue attuali capacità tecniche? Se l’azienda ha molti specialisti di elevato livello tecnico, farà una scelta diversa da quella il cui team è più generico e polivalente con una competenza più globale nelle tecnologie.

Qui ci sono altre domande che possono aiutarti a fare la scelta giusta:

    • Qual è l’evoluzione del tuo codice e dei tuoi team di sviluppo auspicata a medio termine?
    • Quali sono le forze interne della tua organizzazione?
    • Quali sono le tue esigenze e le tue risorse in termini di reclutamento?
    • Serve un team dedicato?

Tenendo conto dell’allineamento delle competenze, delle capacità di budget e della fase in cui si trova la tua azienda, adesso dovresti avere una visione più chiara per scegliere la migliore architettura possibile per i tuoi sviluppi. Non esitare a discuterne con noi su X o Linkedin menzionando questo articolo.

Ti piacerà anche…