Les développeurs Facebook, Google et de notre équipe Webmail regroupent leur code dans un dépôt unique où les dépendances sont partagées (c’est le monorepo ou mono-repository). AWS, Leboncoin.fr et le reste des équipes Infomaniak segmentent leur code dans des dépôts indépendants avec de petites équipes autonomes (il s’agit du multirepo ou « multiple repositories »). Choisir une méthode de gestion du code est une décision stratégique pour l’entreprise, quelle que soit sa taille. Comment définir sa stratégie et avec quels impacts ? Dans cet article, nous vous partageons notre expérience pour faire le meilleur choix en nous appuyant sur un exemple concret : l’évolution de nos services d’hébergement Web.

Du monorepo au multirepo : l’évolution de l’hébergement Web d’Infomaniak

Hosting V1 : l’offre d’hébergement unique d’Infomaniak

Fin 1990, la plateforme Hosting V1 est lancée. C’est la première offre historique d’hébergement d’Infomaniak.

Cette première plateforme est basée sur une architecture monolithe, ce qui signifie que toute l’application est développée comme un seul et unique bloc logiciel. À sa création, cette architecture est la norme dans notre industrie naissante. Elle est adaptée aux besoins de l’équipe de développement et elle convient à nos plus faibles volumes de trafic tout en offrant une bonne vélocité de développement.

Hosting V2 : l’hébergement Web et WordPress actuel

En 2013, nous avons lancé la plateforme Hosting V2, notre offre d’hébergement actuelle. Elle se base aussi sur une API monolithique commune à l’ensemble des produits Infomaniak.

À cette période, l’architecture en microservices commençait à gagner en popularité, mais nous avons décidé de ne pas l’adopter tout de suite pour cette nouvelle plateforme. Cela aurait impliqué de faire évoluer massivement les pratiques :

  • repenser très en profondeur le code,
  • changer les méthodes de déploiement et d’observabilité,
  • adapter de nombreux processus et
  • former les gens.

Un bouleversement prématuré, car à l’époque, les outils pour mettre en œuvre une telle architecture étaient insuffisants. Ils ajoutaient plus de complexité qu’ils n’en supprimaient pour une équipe de la taille de celle d’Infomaniak.

En 2024, avec six fois plus de personnel qu’à l’époque, de nouvelles perspectives sont possibles et de nouveaux besoins se font sentir.

Hosting V3 : la prochaine plateforme d’hébergement d’Infomaniak

La future plateforme d’hébergement est en plein développement et sera basée sur une architecture multi microservices.

Il s’agit d’une phase de transition ambitieuse et complexe qui permettra de répondre aux enjeux de demain et créer de nouveaux services d’hébergement. Cette évolution sera totale et concernera aussi bien l’interface que l’architecture cloud en arrière-plan.

Nous voulons conserver notre capacité à transformer rapidement nos idées en produits pour nos clients. Cette nouvelle architecture offre la vélocité nécessaire pour accompagner la croissance et anticiper les besoins futurs.

Julien Viard, VP of Engineering chez Infomaniak

Mise en oeuvre de la transition Monorepo vers Multirepo

D’une architecture monorepo avec Hosting V2…

Avec la croissance d’Infomaniak, la création de nouveaux produits et l’agrandissement de nos équipes, l’architecture monolithique choisie initialement pour Hosting V1 et Hosting V2 montre aujourd’hui ses limites. Elle répond de moins en moins à notre structure organisationnelle et aux besoins actuels. C’est pourquoi nous développons la future plateforme d’hébergement (Hosting V3) avec une nouvelle architecture en microservices.

Techniquement, voici à quoi ressemble (de manière simplifiée) l’architecture monorepo de la plateforme Hosting V2 :

Ce schéma représente la relation entre les différents services de nos solutions d'hébergement.
Ce schéma représente de manière simplifiée la relation entre les services principaux de nos solutions d’hébergement.

Sur ce schéma :

  • On observe d’abord que le Manager Infomaniak est le monolithe utilisé coté front-end. Ce dernier gère tout l’aspect visuel de la gestion des produits Infomaniak. Le Manager est connecté à l’ensemble de nos API et permet à nos clients d’avoir une seule interface pour gérer tous leurs services. Avec l’architecture en place, chaque mise à jour d’un service d’hébergement impacte la totalité des autres produits, ce qui nécessite une politique de mise à jour très stricte pour ne pas menacer la stabilité de l’ensemble du Manager pour les clients.
  • Infomaniak Legacy (c’est-à-dire le code « originel » ou « historique » qui est devenu obsolète ou difficile à maintenir) contient une très grande partie du code Legacy Hosting et du code Legacy General Infomaniak : tout ce code est actuellement dans le même projet. Comme pour la partie front-end, les mises à jour du monolithe Hosting back-end impactent tout le code Legacy Infomaniak qui concerne l’ensemble des services, ce qui réduit la vélocité de nos équipes produits.
  • Infomaniak Core est un microservice qui contient plusieurs fonctionnalités transversales comme la récupération d’un profil utilisateur.

En résumé, cette architecture complexifie la mise à jour d’une partie des services sans impacter la totalité des projets, ce qui a un impact négatif sur la vélocité d’un écosystème qui contient beaucoup d’interdépendances. Les deux gros monolithes Manager Infomaniak et Infomaniak Legacy sont complexes à faire évoluer parce qu’ils ont un impact sur tous nos services alors qu’avec la refonte en cours (Hosting V3), nous aurons plusieurs microservices plus faciles à mettre à jour.

Une architecture monolithe est comme un immeuble : quand tu changes le chauffage, tu impactes la totalité de l’immeuble. Avec des microservices, c’est comme des maisons individuelles : si tu changes le chauffage d’une maison, cela n’a pas d’impact sur les maisons d’à côté.

Matthieu Mabillard, Team Lead Developer

…à une architecture multirepo avec Hosting V3

Hosting V3 est une refonte en profondeur de notre architecture.

Ce schéma résume de manière simplifiée le fonctionnement de la nouvelle plateforme d’hébergement en cours de développement :

 

Avec cette nouvelle architecture :

  • On observe premièrement que la partie front-end des services Hosting est à présent décorrélée du Manager Infomaniak pour faciliter leur évolution.
  • Hosting Legacy récupère et isole le code historique de l’ancien monolithe Infomaniak Legacy. Ce code est modernisé en un microservice pour le maintenir plus facilement, mais il n’est pas entièrement réécrit.
  • Le proxy est celui qui s’occupe de traduire l’authentification du client au Manager pour lui permettre des accès sécurisés personnalisés. C’est le point d’entrée de toutes les interactions.
  • API Hosting contient le nouveau code de la nouvelle plateforme d’hébergement Hosting V3. Son rôle est de dispatcher les informations vers Legacy General Infomaniak ou API Legacy Hosting s’il voit que les demandes correspondent à des fonctionnalités qui n’ont pas été redéveloppées.
  • La gestion des certificats SSL (SSL Certificates) est isolée dans un microservice pour faciliter son évolution et son intégration à l’ensemble des services.
  • Infomaniak Legacy contient toujours les dépendances du monolithe Infomaniak pour les fonctionnalités transversales.
  • Le microservice d’authentification des utilisateurs (OAuth2.0) ne change pas non plus.
  • On retrouve également le microservice Infomaniak Core qui réunit plusieurs fonctionnalités comme la récupération du profil d’un utilisateur.

Ce découpage en microservices permet de réduire les dépendances entre les microservices et de maîtriser la dette technique. Nous sommes totalement maîtres du déploiement et du cycle de vie de notre code, que ce soit le nouveau ou legacy. Cette approche nous permet de vivre avec un modèle hybride qui conjugue vélocité et évolutivité.

Cette architecture brille dans les environnements caractérisés par une exécution fortement distribuée. Elle offre une forte résilience, une grande redondance et une importante capacité d’adaptation aux variations de charge.

Matthieu Mabillard, Team Lead Developer

Passer du monorepo au multirepo : l’importance de bien préparer ses équipes

Dans le cadre de cette transition, nous mettons en place des mesures pour favoriser l’adoption de normes communes entre les équipes et renforcer les échanges entre les spécialistes avec :

  • Des guildes d’expertise hors hiérarchie qui permettent le partage de la connaissance entre les experts de manière transverse au niveau du plateau des développeurs. Ils discutent de sujets comme les API, DevOps, Laravel, Angular.
  • Des directives de qualité pour harmoniser les pratiques entre les équipes avec des critères standardisés. Ce point est lié avec nos normes ISO 9001, ISO 14001, ISO 50001.
  • La responsabilisation des Team Leads qui ont la direction opérationnelle de tous les microservices de leur équipe. Cela renforce l’autonomie et la responsabilité des équipes. La direction technique est donc déchargée et peut se consacrer entièrement à la stratégie, aux technologies, à la mise en place des bonnes pratiques, à la supervision et à l’accompagnement.
  • La mise en place d’outils d’auditing (SonarQube, Renovate, Gitlab CI) pour avoir une vigilance sur toutes les entrées qui sont générées et être en mesure de superviser l’état des dépôts dans leur ensemble.

Monorepo vs multirepo : un choix stratégique pour l’entreprise

La méthode de gestion du code a des implications majeures sur lesquelles il est difficile de revenir. Il faut donc bien réfléchir avant de prendre sa décision et définir sa stratégie.

Les avantages de l’approche Multirepo

Dans le contexte de la future plateforme d’hébergement, l’approche Multirepo permet d’utiliser les dernières technologies sans devoir attendre que d’autres projets de l’entreprise soient à jour. La gestion des droits est aussi plus précise : l’accès à la code base est finement contrôlé, y compris en lecture. On sait exactement « qui touche à quoi », ce qui facilite le transfert de responsabilité d’un micro service d’une équipe à une autre et même la restructuration du pôle DEV.

L’architecture multirepo permet aux équipes de se spécialiser davantage en répartissant clairement les responsabilités et en associant à chaque projet des technologies spécifiques.

Matthieu Mabillard, Team Lead Developer

On obtient une plus grande autonomie des équipes : le découpage des responsabilités améliore l’efficacité des équipes qui peuvent se concentrer sur leur propre microservice car leur dépôt est indépendant des autres. C’est un gain de liberté sur plusieurs points :

  • cycle de vie,
  • recrutement spécifique,
  • choix technologiques.

Il est aussi plus facile d’expérimenter de nouveaux projets : le multirepo accélère le développement de proofs of concept (POC) qui peuvent se faire indépendamment des autres branches. Cela permet de valider rapidement la faisabilité d’une idée. La vélocité est propre à chaque projet : chaque service de l’équipe Hosting peut accélérer ou optimiser son cycle de développement, avoir ses propres critères d’acceptation, tout cela sans être freiné par l’impact qu’il pourrait avoir sur les autres.

Le multirepo facilite les contributions open source : la code base est réduite et la segmentation des services permet de publier certaines parties du code et pas d’autres, par exemple pour des raisons de sécurité ou de protection du savoir-faire (secret) industriel.

Cette approche accélère les cycles de développement : la mise en production est plus courte que dans nos projets monorepo. Dans le Hosting V3, chaque composant est découplé alors que le build du Webmail en monorepo est plus long.

Ce choix peut aussi avoir un impact important sur le recrutement :

Avoir des stacks technologiques séduisantes avec une courbe d’apprentissage raisonnable est un facteur déterminant pour attirer les talents. Personne n’est attiré vers une entreprise qui incrémente de la dette technique avec des technologies qui ne sont enseignées nulle part.

Julien Viard, VP of Engineering chez Infomaniak

Les limites d’une approche Multirepo

Le multirepo demande plus de rigueur pour synchroniser l’évolution d’un microservice vis-à-vis des autres :

  • Il faut systématiquement mettre à jour les dépendances de son projet pour qu’il bénéficie de la montée en qualité du code des sous-programmes ou des corrections de failles, etc. en consommant la bonne librairie, le bon bout de code, etc. Il faut par exemple veiller à ce que deux API conservent un socle commun si elles fonctionnent de façon similaire en consommant le même microservice d’authentification.
  • La mise en place des tests d’intégration est plus complexe et demande d’avoir des scénarios dans lesquels plusieurs microservices peuvent communiquer entre eux. Par exemple, un client fait une seule action pour créer un site Internet, mais cela déclenche 3 actions côté Hosting : API SSL, image de preview, API Hosting.
  • Comme le code est segmenté, il est plus difficile d’avoir une traçabilité et un feedback permanent sur l’ensemble du code.
  • La granularité rend la détection des problèmes plus difficile, car il faut vérifier chaque microservice un par un. Il est en revanche plus facile d’agir car la correction à apporter est souvent mieux délimitée.
  • Enfin, le maintient de la synergie entre les technologies, les librairies et les pratiques de développement demandent davantage de compétences.

Monorepo vs multirepo : quel est le bon choix pour vos équipes de développeurs ?

Ce choix demande une réflexion à l’interne sur plusieurs axes :

  • Quel est le profil de votre entreprise ? Pour une start up avec un time to market court, il n’est pas facile d’adopter une architecture de microservices longue à mettre en place. Il faut souvent lancer un produit le plus vite possible et donc choisir stratégiquement la solution qui amène la plus grande vélocité de développement.
  • Quelle est la vélocité dont vous avez besoin ?
  • Quelles sont vos capacités techniques actuelles ? Si l’entreprise compte beaucoup de spécialistes avec un niveau technique élevé, elle fera un choix différent de celle dont l’équipe est davantage généraliste et polyvalente avec une compétence plus globale des technologies.

Voici d’autres questions qui peuvent vous aider à faire le bon choix :

    • Quelle est l’évolution souhaitée de votre code et de vos équipes de développement à moyen terme ?
    • Quelles sont les forces internes de votre organisation ?
    • Quels sont vos besoins et vos ressources en recrutement ?
    • Faut-il une équipe dédiée ?

En tenant compte de l’alignement des compétences, des capacités budgétaires et de la phase dans laquelle se trouve votre entreprise, vous devriez à présent y voir plus clair pour choisir la meilleure architecture possible pour vos développements. N’hésitez pas à en discuter avec nous sur X ou Linkedin en mentionnant cet article.

Vous aimerez aussi…