...
- 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 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 [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.
Nous espérons que cette nouvelle architecture réduira cette barrière à l'entrée en permettant aux débutant d'appréhender nos systèmes petits à petit et en leur donnant la possibilité d'ajouter de nouvelle fonctionnalités dès leur arrivée, en utilisant les technologies avec lesquelles ils sont à l'aise.
Si ce sujet vous intéresse, laissez des commentaires sur Confluence et venez nous rejoindre sur Slack !
Sources