Depuis plusieurs années, Gadz.org s'oriente vers une architecture découpée en services, voir en micro-services. Voyons ensemble ce que cela signifie et les raisons de ce choix.

...

L'architecture orienté service vise à résoudre un problème récurent dans les environnement informatique : l'augmentation boulimique des fonctionnalités des applications. Les applications grossissant, leur complexité augmente finalement pour devenir finalement devenir d'énormes monstres que plus personne n'ose modifier de peur de "casser" quelque chose. Rajoutez à cela des resources humaines avec un fort turnover vous serait assurer d'avoir perdu toute votre agilité.

Pour répondre à ce problème, les applications sont découpées en applications plus petites ayant chacun un périmètre fonctionnel bien défini.EXEMPLE NECESSAIRE

 Mais ces applications ne sont que rarement autonomes et ont besoin de communiquer avec les autres applications, le plus souvent au moyen d'API [wikipedia]. Dans les systèmes Gadz.org  par exemple, lors de l'inscription d'un nouvel utilisateur dans le site de la Soce, il est également nécessaire de l'inscrire dans le système d’authentification universel.

...

Deuxièmement, les "services" restent des applications à part entière, necessitant nécessitant chacune de multiple compétences (gestion de base de données, envoie de mail...) et une bonne connaissance de la base de code pour en assurer l'évolutivité. Même si le phénomène est amoindir, les équipes projets restent de tailles conséquente, ce qui est un problème pour des organisations telles que la notre, reposant sur des bénévoles. De plus, la complexité des applications pose généralement une barrière à l'entrée pour les nouveaux bénévoles, souvent débutants.

Architecture en micro-services

Pourquoi ne pas faire des applications encore plus petites ?

C'est ce que proposent les architecture en micro-services. Pour éviter les problèmes des gros projets, il suffit de n’avoir que des petits projets.
Image Added 
Architecture en micro-services : plein de petites applications qui dialoguent entre elles

Ceci présente de nombreux avantages :

• L'application étant de taille limité, les "cas particuliers" sont peu nombreux et facilement identifiables
• Les équipes projets sont réduites et plus spécialisées
• L'architecture force les interfaces à être formalisées, une obligation de documenter les entrées-sortie de son application
  
• Les technologie utilisées sont indépendantes et permettent de sélectionner celle qui répond le mieux aux besoins spécifiques
• Il est plus facile de démarrer un nouveau projet en s'appuyant sur les services existants
• L'amélioration des performances est simplifiée : il est plus facile d'identifier le service le plus lent et de l'améliorer

Evidemment, les micros-services ne sont pas une solution miracle et il viennent avec leur lot de complications :

• L'industrialisation (la mise en production) est plus complexe : "beaucoup de petites applications" signifie "beaucoup de déploiements", ce qui peut être pénible à réaliser si le processus de déploiement est lourd à utiliser
• Les interfaces doivent être documentées : c'est également un inconvénient car un service non documenté deviendra rapidement inutilisable
• Le système devient distribué : la vision globale est plus compliquée à atteindre et nécessite beaucoup de communication entre les équipes

 Chez Gadz.org ça donne quoi ?