La performance d’un système est au niveau de celle de nos processus.

Les repository de codes sont des fondations dans l’organisation de nos processus, organisation et collaboration du développement logiciel.

Un choix de mono ou de multi-repository est donc structurant et impactant, d’où son débat dans la communauté.

Nous avons pu partager sur ce thème lors de la table-ronde “Comment un choix de mono ou multi-repository peut améliorer votre qualité ?”

Cet article a pour but de prendre du recul sur les évolutions qui ont conduit à faire émerger du mono et du multi-repository.

Parlons donc de monolith, microservices et de perspectives autour de ce sujet tant débattu.

Le mono-repo était historiquement la seule option possible

Les systèmes dit legacy font pour partie d’entre eux déjà partie des musées.

L’époque où tout le monde avait forcément connu ces systèmes, leurs écrans verts, commence à doucement disparaître.

On aurait même tendance à vouloir à cacher posséder un tel système pour pouvoir attirer les récents talents.

En bref, ces systèmes legacy ont pour majeure partie leur racine du Mainframe et autres AS400.

Construits et opérés sur une plateforme unique et centralisée, leurs composants sont architecturés sur un socle commun.

Additionnellement, l’écosystème était loin de fournir des outils tels que Git, Jenkins et de pouvoir adopter le CI/CD.

Le contexte, maturité de l’écosystème et manque d’interopérabilité étaient des facteurs réunis pour collaborer exclusivement sur modèle de mono-repository.

Le monolith en mono-repo avait son ensemble de défis

Rappelons nous que les challenges était de passer des batchs sur des fenêtres de temps impartis pour contrainte de ressources.

On avait d’ailleurs du mal à délivrer des évolutions en parallèle, se confrontant au facteur limitant de son organisation. 

L’intégration de nouveau membre dans l’équipe était également difficile par le volume d’information à intégrer et la complexité du système. 

On aurait déjà pu parler de Cognitive Load.

Il était globalement difficile de contenir l’entropie d’un tel système, la complexité devait être gérée, elle se retrouvait forcément dans ce monolith.

Ces divers problématiques et besoins des entreprises ont poussé à créer des systèmes plus distribués.

L’écosystème a évolué vers les architectures distribuées capacitant le multi-repo

De nouvelles plateformes et moyens de communication sont donc apparus.

On note par exemple l’apparition d’appels de procédures distantes tel que Corba, qui ont ensuite évolués vers les protocoles plus standards de webservices.

Gardons en tête que leur but était de répondre aux enjeux d’ accélération par la parallélisation de services entre différentes équipes.

Dans un second temps, le SOA est apparu avec la promesse de réutilisation de services pour accélérer et capitaliser sur les investissements.

C’est dans cet écosystème que les architectures en multi-repos sont apparues, supportant une distribution de la complexité du système global.

On était donc sauvé?

Pas tant que ça.

Les systèmes distribués et le multi-repo sont venus avec leurs problèmes

Cette fameuse réutilisation implémentée par des couplages forts de services en synchrone a créé des architectures souvent nommées de spaghetti-code.

Même si souvent associée aux microservices, je suis convaincu que l’on peut mal concevoir n’importe quel type d’architecture.

Les architectures spaghetti ne sont pas que pour les microservices, on pouvait déjà très mal concevoir des batchs sous Mainframe.

Antoine Craske

Les mono-repos étaient donc devenus complètement obsolètes?

Ils survivent dans un bon nombre d’organisations qui ont d’ailleurs encore aujourd’hui du Mainframe sur des processus cœurs d’entreprises.

La distribution des applications a en fait rendu le sujet des repository un sujet global du système de développement logiciel.

Les problèmes fréquemment rencontrés sont liés à des choix purement technologiques pour décider d’un modèle.

On décide d’avoir un repository par équipe et technologie, quoi de plus logique?

La perte de vue du système dans sa globalité et de ses objectifs est ce qui manque dans la pondération du modèle à retenir.

Ensuite sont arrivés les microservices.

Les risques du Microservices et multi-repo par défaut

Les microservices se sont imposés comme une mode, devenu de le de-facto standard à suivre pour être à la page.

Étant par nature encore plus distribués et grain plus fin que nos fameux services SOA, le multi-repository a suivi la tendance.

On peut néanmoins se demander si le multi-repository est le seul modèle valide pour les microservices?

Je ne pense pas, à vrai dire plusieurs niveaux d’équilibre sont possibles.

On peut choisir d’affecter un repository à chaque microservice, proche d’une fonction, au  grain le plus fin.

Ce type de choix peut être attrayant à premier abord, il faut néanmoins garder en tête que certains éléments nécessaires à plusieurs composants seront difficilement maintenables.

Le domaine, l’architecture et la perspective organisationnelle doivent être alignés

On peut donc préférer avoir un repository par grande application, actuant normalement dans son domaine fonctionnel, possiblement issue d’une démarche de DDD.

Ce type de regroupement nous amènera à plus de cohérence au sein d’une application, qui sera d’ailleurs souvent maintenue par la même équipe.

Intéressant car à parler de technique nous avions facilement perdu de vue l’aspect organisationnel et humain du développement logiciel. 

Comme pour les tendances, les acteurs peuvent même finir par perdre de vue l’objectif initialement poursuivi.

C’est à priori ce qui se passe beaucoup avec les microservices, oú pour reprendre l’expression on peut facilement “sauter dans le train en marche”.

Nous voyons que tant le mono que multi-repository sont possibles même pour des architectures microservices, garder du recul sur ses enjeux reste donc clef.

On pourrait presque se retrouver perdu dans tant de choix.

Un retour à l’équilibre s’opère actuellement dans l’écosystème

Depuis quelques années on rencontre régulièrement des succès en mono-repository et sans microservices.

Revenu de nos extrêmes, il est effectivement plus facile de prendre du recul.

On pose plus clairement le problème.

Notre choix de mono ou multi-repository doit être aligné sur les objectifs du système, et évoluer pour en accompagner son développement.

Antoine Craske

Concrètement, une start-up démarrant son produit avec peu de maturité sur son domaine, avec une petite équipe sera plutôt sujette à une architecture mono-repository.

De manière moins évidente, une entreprise fournissant un produit comme une plateforme SaaS peut tirer des bénéfices d’un mono-repo pour favoriser la visibilité, collaboration et intégration bout-en-bout de son produit.

Au contraire, une entreprise en pleine croissance et des équipes de développements grandissantes aura tout intérêt à distribuer son système, organisation, repository.

Une organisation avec un minimum d’existence aura accumulé des technologies souvent différentes, et pourra par contexte décider d’un mono ou multi-repo en fonction de sa trajectoire de modernisation.

Le contexte est donc clé dans le choix de repository, qui doit pouvoir évoluer en accord avec l’organisation.

Une IA automatisant notre choix nous faciliterait bien la vie.

L’automatisation, l’IA et autres bots vont-ils pouvoir nous aider ?

C’est peut être ce qui arrivera, en attendant des évolutions sont néanmoins visibles.

On voit par exemple émerger des outils traitant automatiquement de la mise à jour de dépendances communes à différents projets, comme dependabot.

La réalité est que les systèmes distribués vont continuer à être nécessaire et à se complexifier dans leur intégration, exemple avec le mobile et l’IoT.

L’apparition de ces solutions est donc similaire à celle des pipelines de CI/CD : un réel besoin sur une problématique structurelle à adresser.

Pour que l’IA entre jeu, gardons en tête que la Data Science en production commence à se démocratiser et que dans tous les cas, nécessite beaucoup de données pour apprendre.

Néanmoins, pour certaines répétitions existantes un bon algorithme statistique peut déjà largement faire l’affaire.

Nous aurons au moins plus de temps pour choisir notre mono ou multi-repository, et si nous avons réellement besoin de microservices.

En attendant, Google est l’une des organisations avec le plus large mono-repo.