Architectures Microservices et utilisation de Git

Récemment des présentations, conférences et articles de blogs sont apparus, parlant des avantages à utiliser un unique repository git pour gérer l’ensemble du code source d’un logiciel.

C’est un point de vue intéressant, et j’aimerais partager mon point de vue sur le sujet. Comme le titre le suggère, le contexte de réponse est celui d’une application suivant le pattern d’architecture microservices.

Qu’est ce qu’une architecture microservice ?

C’est une question importante à laquelle nous devons répondre dans un premier temps pour comprendre les enjeux de ce type de modèle de développement. L’image qui suit vient du blog de NginX ; bien qu’elle soit très artistique, elle montre plutôt bien les concepts de ce type d’architecture.

implement-microservices
Architecture Micro-Service (représentation)

Les caractéristiques essentielles d’un microservices sont les suivantes :

  • facilement remplaçable
  • conçu autour d’un périmètre fonctionnel clairement délimité (facturation, paiement, authentification, etc)
  • implémente la technologie la plus adaptée (en terme de langage, de middleware ou de moteur de stockage) et qui répond le mieux aux besoins et fonctionnalités que supporte le service
  • doit être élastique, scalable, composable, minimaliste et complet. Cela implique aussi d’être sans état (stateless), un faible couplage (loose coupling) et une forte cohésion (high cohesion).

Il s’agit en fait de suivre la bonne vieille philosophie UNIX:

Do one thing, but do it well

Une architecture micro-services implique aussi de porter une attention particulière aux tests unitaires et fonctionnels, de mettre en place des processus de livraison automatisé (continuous delivery). Généralement, Cela va de paire avec la notion d’intégration continue pour très vite remonter les bugs ou régression induites par les nouveaux développements et ne pas constater les problèmes en production.

Quel lien avec Git ?

On pourrait se dire que tout ça n’a rien à voir, mais je pense au contraire que les choix d’architectures d’un logiciel induisent les choix organisationnels d’une équipe de développement. On y reviendra.

Il faut déjà savoir que Git n’a pas été conçu pour prendre en charge des repository très volumineux. Les merge requests et commits pour ne citer que ces deux actions deviendront de plus en plus lentes au fil du temps. La consommation de disque aura tendance à exploser; et un gros repository aura d’autant plus de chance de se corrompre qu’il sera composé de nombreux fichiers, commits, branches et tags.

D’une manière générale, il est simple d’utiliser de multiples repository :

  • Les développeurs n’ont besoin de connaitre que les commandes classiques de l’outil, sans s’embourber dans l’utilisation des fonctionnalités avancées (submodule, split, etc). L’utilisation de Git est déjà relativement complexe et difficile à appréhender, il n’apparait pas judicieux d’ajouter une complexité d’utilisation qui n’est pas absolument nécessaire.
  • Il sera plus facile de remplacer un service par un autre si le besoin s’en fait sentir si il suffit de changer le chemin du repository associé dans le processus de développement.
  • En plus de cela vous ne pollurez pas chaque service avec les branches et tags de tous les autres services que vous développez.

L’expérience a montré que l’organisation et les méthodes de travail que l’on met en place dans une équipe aurons tendance à orienter sa façon de travailler, ce qui pourra faciliter le respect du modèle d’architecture applicative que l’on souhaite mettre en place. Dans notre cas cela aura pour effet :

  • de séparer les développement en sous-projets indépendants dont les fonctionnalités sont bien distinctes.
  • de faire réfléchir aux problématique de versioning et à la gestion du cycle de vie de chaque service
  • de réfléchir à l’utilisation d’un gestion de dépendance entre les micro-services
  • de fortement encourager les équipes à rédiger les tests unitaires et tests de code pour éviter les plantages et autres bugs malvenus.
  • d’identifier et associer clairment les bugs au service concerné
  • d’éviter cet effet de floutage des responsabilités de chaque micro-service sur la durée de vie de l’application. Surtout en phase de TMA.
  • de faire en sorte que chacun reste dans la boucle via les systèmes de notifications (groupe ou organisation) que fournissent GitHub, GitLab. Que ce soit des emails ou des intégrations à Slack, par exemple.

Le processus d’intégration continue et de déploiement continue sera facilité. Les intégrations avec les outils fournissant de telles fonctionnalités (Travis, OpenShift, …) sera assuré car la plupart ne supportent que le clone d’une branche ou d’un tag d’un repository. Il sera plus simple et plus rapide pour votre équipe DevOps d’implémenter le cycle CI/CD étape par étape et donc service par service.

Il est possible de gérer les politiques d’accès et de droits au niveau de l’organisation (GitHub) ou des groupes (GitLab), en utilisant les capacités d’authentification multiples que proposent ces outils (LDAP, Oauth, etc). Cela permet de bénéficier de tous les avantages d’un repository unique sans les contraintes souvent attribuées à l’utilisation de multiples repos. Et même de profiter d’une granularité accrue.

Au bout du compte, il est globalement recommandé de garder une approche aussi simple que possible (KISS), ce qui facilitera à tous la compréhension de la solution, des outils et des méthodes de travail. Ajouter de la complexité est souvent une mauvaise idée sur le long terme. Il est donc préférable de l’éviter tant qu’on a pas de contrainte imposant de faire autrement. Lors du développement d’une application basée sur des micro-services, l’organisation de vos référentiels de gestion de sources devrait refléter ce schéma souhaité.

Si cela ne semble pas être une bonne idée, peut-être faut-il se poser la question de savoir si le design de l’application respecte bien les principes de micro-services ? Ou bien si l’on est pas en train d’avoir une approche différente, telle qu’une architecture orienté “composant” par exemple ?


Sources :
http://danluu.com/monorepo/
http://blog.deveo.com/3-reasons-not-to-host-source-code-of-all-projects-under-one-repository/
https://www.quora.com/How-would-you-manage-multiple-projects-under-one-Git-repo
http://blog.plataformatec.com.br/2015/01/organizing-microservices-in-a-single-git-repository/
https://news.ycombinator.com/item?id=7020584
http://article.gmane.org/gmane.comp.version-control.git/189784
https://www.quora.com/Why-does-Facebook-have-so-much-of-their-source-code-in-1-giant-git-repo-did-they-not-think-that-this-approach-wont-scale

Laisser un commentaire