L'idée d'écrire cet article m'est venue mercredi dernier lorsque je parcourais mon fil Twitter. J'ai fini ma journée de travail comme d'habitude et j'ai ouvert le petit oiseau bleu sur mon smartphone. C'est alors que je tombe sur un tweet de Rayed Benbrahim, Développeur NodeJS - Fondateur de https://practicalprogramming.fr. Dans son tweet, il explique qu'il a eu une conversation avec un développeur qui cherchais un framework JS qui faciliterait la conception de Microservices. Il dit ensuite qu'il trouve étonnant qu'on veuille commencer un projet par une architecture microservices ensuite, partage quelques ressources qui expliquent à quel moment on peut s'aventurer vers ce type d'architecture. Ce jour là il a partagé un point de vue auquel j'adhère entièrement et je vais vous expliquer pourquoi, en prenant le cas de ce site, Peef.

C'est quoi l'architecture logicielle ?

L'architecture logicielle est un ensemble de structures nécessaires pour mettre en place un système. Il comprend des logiciels et les relations qui sont établies entre ces logiciels et les propriétés du système. Par exemple, si je prend en compte un système d'authentification utilisateurs, les logiciels ici seront le langages, les librairies ou frameworks utilisés et le serveur web. Ces logiciels mis entre eux doivent permettre aux utilisateurs de se connecter de manière efficace, rapide et sans interruption, quelque soit la quantité de requête qui passe via le serveur web.

L'architecture logicielle est une abstraction parce qu'il s'agit d'un ensemble d'éléments qui forment une structure. C'est pourquoi un logiciel est divisé en modules et chaque module peut avoir besoin d'autres modules pour mieux fonctionner.

L'architecture logicielle constitue une structure et comme pour toute structure, chaque personne en possède une vue différente. Prenons le cas du corps humain: un neurologue va se limiter au niveau des tissus nerveux, un orthopediste lui, va se limiter au niveau des os et des muscles. Ceci parce que chaque spécialiste a un point de vue différent du corps humain en fonction de sa spécialité. Ainsi nous aurons différents points de vue en architecture logicielle à savoir:

1. Un point de vue architecture métier qui fait intervenir les éléments purement métiers tels que la gestion des stocks, la comptabilité, etc...
2. Un point de vue architecture logique qui tourne autour de la logique d'implémentation des systèmes métiers
3. Un point de vue architecture technique qui se concentre sur les outils utilisés (frameworks, serveurs, etc...)

C'est pourquoi en partant du point de vue logique, on distingue l'architecture monolithe et l'architecture microservices.

Comprendre l'architecture Microservices

L'architecture microservices a été mise sur pied dans le but de moderniser les systèmes d'information et s'est accentuée avec l'arrivée du cloud computing. En effet, les applications d'entreprises sont de plus en plus gourmandes en ressources et font intervenir de plus en plus de services et de métiers différents. Les géants du web également ont vu leurs trafics augmenter et leurs systèmes devenaient de plus en plus convoités, nécessitant ainsi de hautes performances.

C'est ainsi que les microservices entrent en jeu avec pour objectifs de découper le système en services, de permettre l'interconnexion des différents services et aussi de leur faire interagir entre eux en temps réel. Par exemple dans le e-commerce, un service << gestion de commandes >> doit récupérer en tant réel les informations du client dans le service << clients >> et celle des produits dans le service << catalogue >>.

Les éléments constitutifs du microservices

L'architecture d'un système en microservices comprend:

1. Un serveur ou conteneur dans lequel sera déployé le service
2. Une base de donnée
3. Le service lui même (le métier)
4. Une interface visuelle pour manipuler les éléments du service
5. Une API à partir de laquelle la communication sera établie avec les autres services
6. Le récepteur final (PC, Tablettes, Mobiles, etc...)

Pour celà, on voit qu'un microservice est avant tout défini par les objets métiers qu'il gère. Dans le cadre de Peef où sont gérés les communautés, les articles, les discussions et bientôt le mentorat et une marketplace, je devrais avoir les services suivants:

• Service Posts (pour la gestion des articles et discussions)
• Service Community (pour gérer les communautés)
• Service Mentorship (pour permettre à tout un chacun de suivre un programme de mentorat)
• Service Marketplace (pour permettre aux utilisateurs de vendre et acheter des produits et services)
• etc...

Les malentendus autour du microservices

• En effet, le terme micro dans microservices laisse penser qu'il s'agit des lignes de codes qui sont présentées par une API REST, pourtant il s'agit d'applications complètes, chacunes hébergées sur son serveur ou conteneur.
• L'autre problème réside souvent au niveau des données: on pense que mettre sur pied des services revient à connecter tous ces services sur une même base de données pourtant chaque service devrait avoir sa propre BD.

Étant donné que chaque service est une application bien précise, penses-tu pouvoir développer tout seul ce petit projet que tu viens de commencer ? La réponse est NON!

Il faut comprendre que monter un projet en microservices lorsqu'on est seul est suicidaire parce qu'il faut non seulement avoir des ressources humaines et financières pour implémenter les différents services mais aussi il faudrait que l'application ait atteint un niveau qui nécessite d'augmenter ses performances.

Il faudrait plutôt privilégier un architecture scallable (qu'on peut faire évoluer) au fil du temps, et c'est là qu'intervient l'architecture monolithe: OUI, JE PENSE QUE L'ARCHITECTURE MONOLITHE EST FACILEMENT SCALLABLE.

Qu'entend-on par architecture monolithe (ou monolithique) ?

Une architecture monolithe est celle là qui comporte une base de code unique répartie en modules. Chaque module a un rôle précis et ce dernier communique avec d'autres modules. Des exemples concrets de ce type d'architecture sont le CMS Wordpress et ses plugins, l'ERP Odoo et ses modules (Comptabilité, Stock, Ventes, Achats, etc...).

Les éléments constitutifs du monolithe

Sachant qu'une architecture monolithe est une architecture dans laquelle les éléments de l'application sont centralisés côté serveur, nous avons ici :

1. Un serveur
2. Une base de données
3. Différents modules couplés aux vues qui partagent la même base de données. On parle souvent d'architecture MVC.

C'est comme celà qu'est contituée Peef mais avec une vue plus globale, SCALLABLE.

En effet, étant donné que je ne pouvais pas m'aventurer dans le microservices à cause des raison citées plus haut, j'ai préféré avoir une architecture modulaire qui peut évoluer dans le temps. Comme le site est développé avec le framework Flask, j'ai alors décidé de le rendre modulaire en utilisant la classe Flask.Blueprint() où chaque module est constitué d'un Blueprint qui possède son propre endpoint. Celà me permettra de connecter Peef à d'autres API en REST avec l'utilisation de Flask-RestX (déjà intégré) et aussi pouvoir communiquer avec d'autres applications. Plus tard si la plateforme évolue comme espéré, il sera simple d'avoir d'autres services et les joindre à l'existant.

Ceci dit, il faut comprendre que le monolithe ne t'empêche pas d'avoir des API dans ton application (REST, GraphQL, etc...) et ne t'empêche pas aussi d'avoir un frontend hébergé ailleurs (Vercel, GitHub Page, Surge, etc...)

Les inconvénients de l'architecture monolithe

L'architecture monolithe a des inconvénients lorsque l'application devient de plus en plus complexe:

1. évolutions des fonctionnalités difficiles à déployer parce que le code devient costaud et les modules s'entremêlent
2. une erreur dans un compartiment de l'application paralyse tout le système
3. toutes les données sont centralisées dans une seule base de données.

En conclusion

L'architecture logicielle est un domaine très vaste dont le but principal est d'assurer le bon fonctionnement des systèmes d'informations. Elle peut être interprétée et utilisée selon plusieurs point de vue. Dans ce cas, le point de vue logique permet de mettre en exergue les architectures monolithes et microservices. Ainsi, pour une startup qui vient de commencer et dont les contraintes en terme de performance de l'application ne sont pas encore avérés, il est mieux pour elle de commencer par une architecture monolithique tout en ayant à l'esprit que l'application peut évoluer vers le microservices. C'est la raison pour laquelle il faut intégrer les API dans son application dès le départ. Il faut cependant noter que faire une application avec plusieurs modules métiers en intégrant une logique d'API ne fait pas d'elle une application avec architecture microservices.

Sources

1. SOA - microservices API management - Le guide de l'architecture des SI agiles - Xavier Fournier-Morel, Pascal Grojean, Guillaume Plouin, Cyril Rognon - 4e édition - DUNOD
2. Software Architecture in Practice - Len Bass, Paul Clements, Rick Kazman, Third Edition, Addison-Wesley