...
| Sommaire |
|---|
L'architecture en services c'est quoi ?
...
Mais ces applications ne sont que rarement autonomes et ont besoin de communiquer avec les autres applications, le plus souvent au moyen d'API 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.
Architecture en services : plusieurs applications qui dialoguent entre elles
Cette architecture présente un gros avantage : le découpage des équipes projets. Il nous est ainsi possible de sous-traité le développement du site de la Soce tout en l'intégrant au sein d'un environnement applicatif plus large. Elle nous permet également de trouver des briques "toute faites" dans le commerce ou open-source.
Mais l'architecture en services ne résout pas tout ! La complexité n'a pas été supprimée elle a été déplacée. Le parc applicatif évoluant, les liens entre les applications s'intensifient au point de créer des couplages fort entre le fonctionnement des applications et de brouiller les pistes entre les responsabilité de chacune.
...
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.
Architecture en micro-services : plein de petites applications qui dialoguent entre elles
Ceci présente de nombreux avantages :
...
- 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 ?
L'architecture Gadz.org
Nous avons opté pour une architecture en "bus de message" plutôt que d’utiliser des API API [les architectures microservices]. Vous pourrez en apprendre plus sur les détails techniques sur la page de l'Architecture Orientée Service (SOA). A l'heure de l'écriture de cet article, elle est encore en cours de construction et de formalisation mais les progrès sont rapide.
Et maintenant ?
L'histoire de Gadz.org a montré qu'il est difficile de maintenir de grosse applications dans un contexte où la resource bénévole est incertaine. Bien souvent, lorsque les initiateur d'un projet s'en vont, la connaissance part avec eux. De plus, il est compliqué de "passer la main" car la complexité des applications décourage rapidement les nouveaux venus.
...
Si ce sujet vous intéresse, laissez des commentaires sur Confluence et venez nous rejoindre sur Slack !