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.
Une tribune signée Infomaniak, qui édite notamment la suite éthique kSuite. La version intégrale de cet article est accessible sur le blog de l’entreprise suisse.
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
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.
Nouveaux serveurs Linux, nouvelles options pour kSuite : Infomaniak muscle ses solutions souveraines
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. 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.
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.
…à 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 tout d’abord 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é.
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.
Une tribune Infomaniak. Consultez la version intégrale de cet article sur le blog de l’entreprise suisse.
