Microservices en Open-Source : Perspective d'Équipe

Dans le monde du développement logiciel, les Microservices sont devenus populaires. Ce sont de petits services indépendants qui peuvent être développés et déployés seuls. Ça veut dire qu'ils peuvent grandir et s'adapter sans impacter tout le système. Beaucoup d'experts pensent qu'une équipe devrait gérer chaque microservice. Ça veut dire qu'un développeur bosse avec une équipe et est responsable d'un microservice. Cette méthode est surtout encouragée dans les gros Projets avec plein de Développeurs.

Dans le logiciel open-source, où tout le monde peut contribuer, la situation peut être différente. Les développeurs rejoignent souvent des projets et bossent sur différentes parties sans affectations d'équipe strictes. Cet article s'intéresse à savoir si l'idée de "un microservice par développeur" est respectée dans les projets open-source.

#L'idée derrière les microservices

Les microservices sont structurés pour séparer différentes fonctions d'un logiciel en plus petites parties. Chaque partie, ou microservice, a un job spécifique. Ça rend la gestion et le développement du logiciel plus simples parce que les Équipes n'ont pas à s'inquiéter de comment les changements d'une partie affectent les autres. En plus, les microservices peuvent être mis à jour et améliorés indépendamment.

Beaucoup d'experts disent que les microservices aident à gérer les grandes équipes. En décomposant le logiciel en plus petites parties, les besoins de communication diminuent. Ça veut dire que des équipes plus grandes peuvent bosser sur différentes parties en même temps sans se marcher sur les pieds.

À cause de ça, on suggère que chaque microservice devrait être détenu par une seule équipe. Si plusieurs équipes bossent sur le même microservice, ça peut créer de la confusion et des inefficacités. Pour suivre cette idée, on s'attend à ce que les développeurs contribuent à un seul microservice à la fois.

#L'étude

Pour voir si l'idée "un microservice par développeur" est vraie dans les projets open-source, une étude a été menée. Cette étude s'est concentrée sur 38 projets open-source utilisant des microservices. Les chercheurs ont examiné les Contributions des développeurs et combien de microservices chaque développeur a travaillé.

Le principal objectif était de voir à quelle fréquence les développeurs travaillaient sur plus d'un microservice et si cela correspondait à la suggestion que chaque développeur devrait se concentrer sur un seul microservice.

#Questions de recherche

L'étude cherchait à répondre à deux questions principales :

1. Dans quelle mesure la pratique "un microservice par développeur" est-elle suivie dans les projets open-source ?
2. Les différents rôles des développeurs respectent-ils cette pratique différemment ?

#Projets sélectionnés

Les chercheurs ont choisi leurs projets dans une liste de 145 projets basés sur des microservices validés. Ils ont veillé à ce que chaque projet ait au moins deux microservices et que ces microservices aient montré une activité récente. De cette manière, les projets sélectionnés représentaient un travail actif et en cours.

Au total, 38 projets ont été analysés, comprenant 379 microservices distincts.

#Collecte de données

Pour collecter des informations sur les contributions des développeurs, les chercheurs ont examiné l'historique des commits de chaque projet. Chaque enregistrement de commit inclut la date et l'heure, le nom de l'auteur, et les détails sur les fichiers modifiés. En associant ces changements aux microservices auxquels ils appartenaient, les chercheurs pouvaient suivre quel développeur a travaillé sur quel microservice.

#Analyse des données

Avec les données collectées, les chercheurs ont analysé combien de microservices chaque développeur a contribué. Ils ont examiné deux aspects :

1. Combien de microservices avaient des développeurs partagés travaillant dessus ?
2. Combien de développeurs ont travaillé sur plus d'un microservice ?

Une partie essentielle de l'analyse comprenait l'identification d'un développeur qui a travaillé sur un microservice puis est passé à un autre sans revenir. Cette distinction a aidé à évaluer si la pratique "un microservice par développeur" était réellement respectée ou non.

#Résultats

#Respect de la pratique

L'étude a révélé que seulement deux des 38 projets suivaient constamment l'idée de "un microservice par développeur". La plupart des projets avaient des développeurs qui travaillaient sur plusieurs microservices en même temps. Cela montre un écart par rapport à la pratique suggérée, indiquant que de nombreux développeurs n'étaient pas limités à un seul microservice à la fois.

#Rôles des développeurs et contributions

L'étude a aussi examiné comment les différents rôles au sein des équipes de développement respectaient la pratique. On s'attendait à ce que certains rôles, comme ceux en DevOps, soient impliqués avec plusieurs microservices alors que les développeurs principaux se concentreraient principalement sur des services uniques.

Cependant, il a été découvert que de nombreux contributeurs, peu importe leurs rôles, travaillaient souvent sur divers microservices. Certains projets montraient un schéma où un seul développeur était responsable de plusieurs microservices, tandis que dans d'autres, plusieurs développeurs travaillaient sur tous les microservices disponibles. Cela variait significativement d'un projet à l'autre mais mettait en avant une tendance claire que l'approche "un microservice par développeur" n'était pas la norme.

#Types de projets

Les projets ont été classés selon leurs modèles de contributeurs :

1. One-Dev-ALL-MS Projects : Ces projets avaient un développeur couvrant tous les microservices tandis que d'autres contribuaient à seulement certains. Cela se produisait dans 16 des 38 projets.

2. Multi-Dev-ALL-MS Projects : Dans ces projets, plusieurs développeurs contribuaient à tous les microservices. Cela a été observé dans 10 des 38 projets.

3. Multi-Dev-SOME-MS Projects : Aucun des contributeurs ne couvrait tous les services, ni ne suivait la règle "un microservice par développeur". Cette catégorie incluait 12 des 38 projets.

4. One-MS-per-developer Projects : Les projets où chaque développeur ne travaillait que sur un seul microservice étaient rares.

#Comprendre le comportement des développeurs

Différentes techniques ont été utilisées pour évaluer le comportement et les contributions des développeurs à travers ces projets. Les chercheurs visaient à comprendre quels rôles contribuaient plus ou moins aux microservices. Ils ont utilisé une méthode appelée Analyse Factorielle Exploratoire pour regrouper les contributeurs selon leurs activités de codage.

#Rôles des développeurs

L'analyse a révélé que différents types de contributeurs montraient des comportements variés. Par exemple, les contributeurs individuels qui géraient tous les microservices contribuaient de manière significative plus que ceux qui partageaient la charge de travail. Ces projets à un seul développeur avaient une plus forte concentration sur la documentation et les responsabilités frontend.

D'un autre côté, les projets avec plusieurs contributeurs partageaient la charge de travail de telle manière que cela réduisait les contributions globales de chaque développeur. En général, les projets avec beaucoup de développeurs avaient souvent de nombreuses contributions qui se chevauchaient entre les microservices, indiquant que les rôles n'étaient pas clairement définis.

#Raisons des résultats

Les résultats peuvent être attribués à plusieurs facteurs :

• Dynamique Open-Source : Les développeurs dans des projets open-source contribuent souvent de manière volontaire, sans rôles fixes ni obligations. Ils peuvent se concentrer sur des problèmes ou des fonctionnalités spécifiques plutôt que de s'en tenir strictement à un seul microservice. Cette flexibilité permet d’atteindre un plus large éventail des besoins du projet.

• Manque de structure d'équipe claire : Dans de nombreux projets open-source, il n'y a pas de structures d'équipe rigides comme dans les environnements d'entreprise. Cela peut mener les développeurs à assumer diverses tâches en fonction de leurs intérêts ou compétences plutôt que d'un microservice défini.

• Scalabilité contre organisation : Beaucoup de projets adoptent une architecture de microservices principalement pour des raisons d'échelle. Maintenir des frontières strictes comme suggéré peut ne pas bien correspondre à l'environnement piloté par des bénévoles du logiciel open-source.

#Implications pour la pratique

Les chercheurs ont conclu que la stratégie "un microservice par développeur" n'est pas couramment observée dans les projets open-source. La flexibilité qui vient des contributions volontaires permet aux développeurs de travailler sur plusieurs services, mais cela peut réduire l'efficacité que le modèle de microservice promet.

On note aussi que ce schéma pourrait être perçu comme un inconvénient pour un scaling efficace, suggérant que certains projets pourraient bénéficier d'une approche plus organisée, surtout à mesure qu'ils grandissent.

#Travaux futurs

L'étude sert de base pour des investigations plus poussées sur les collaborations des développeurs dans les projets open-source. De futures recherches pourraient se concentrer sur la compréhension de la formation spontanée des équipes selon les besoins du projet. Analyser la communication et les interactions en lien avec les contributions de code pourrait révéler davantage d'informations sur comment les développeurs se regroupent naturellement autour des tâches.

Une autre piste pour la recherche est d'explorer les implications de la dynamique des rôles et comment elles évoluent dans le cadre des besoins changeants du projet. Cela pourrait conduire à une meilleure compréhension de la manière d'organiser efficacement les efforts de développement open-source.

#Conclusion

En résumé, l'assumption que chaque développeur devrait seulement travailler sur un microservice dans des projets open-source n'est souvent pas respectée. Beaucoup de développeurs contribuent à plusieurs microservices, reflétant la nature flexible et pilotée par des bénévoles du développement de logiciels open-source. Cette étude met en lumière le besoin de recherches supplémentaires sur comment ces dynamiques se déroulent et comment elles peuvent être gérées pour améliorer les résultats des projets. Les résultats soulignent les différences dans le comportement des contributeurs et les implications que cela a pour l'architecture microservice dans le contexte du logiciel open-source.