I. Applications Monolithiques.

Avant l'arrivée des microservices (MS), tout était monolithique. Une application monolithique est un système où toutes les fonctionnalités coexistent dans un seul bloc de code. Finalement, vous obtenez un exécutable unique, stocké dans un seul repository, et votre application est développée, déployée et maintenue comme un composant unique.

I.1 Avantages

• Facilité de développement : Votre code est situé dans un seul endroit, vous n’avez pas à vous soucier de chercher dans une multitude de repository. De plus, lorsqu’il s’agit de tester votre application, vous ne souciez que du fonctionnement d’un seul composant !

• Facilité de déploiement : Un seul pipeline CI/CD suffit pour assurer le déploiement de votre application.

• Débogage simplifié : Lorsque vous avez une application monolithique alors vous n'avez qu'un seul composant pour chercher le problème que vous rencontrez. Le vrai point fort c’est que vous pourriez tout simplement déboguer votre application dans votre environnement local.

• Performance : Ce n’est pas en suivant l’architecture monolithique que vous obtenez la meilleure performance, MAIS! Avec une monolithique vous ne vous souciez jamais de ce qu’on appelle un temps de latence. Le coût est négligeable lorsque les différentes parties de votre code s'appellent entre elles.

“ Si les applications Monolithiques sont aussi géniales, pourquoi s'embêter avec une architecture Microservices ? ”

Malgré leurs avantages, les monolithiques posent des défis qui incitent souvent les équipes à migrer vers les microservices :

I. 2 Inconvénients

• Une taille croissante : Bien que les développeurs commencent avec une intention noble et appliquent les meilleures pratiques et approches de codes afin d’assurer que leurs applications restent maintenables, les meilleures applications développées tendent à devenir des désastres une fois qu'ils atteignent un certain volume.

• Déploiement complexe : Si votre application est riche en fonctionnalités, il y aura alors beaucoup à tester avant chaque “release”. Comme votre application n'est qu'un grand composant, même les plus petits changements nécessitent que vous déployiez l'application entière à chaque fois.

• Scalabilité compliquée : Si une partie de votre application reçoit beaucoup de trafic, votre seul moyen de la faire évoluer est d’évoluer l’application entière ( y compris les parties qui ne nécessitent pas une mise à l’échelle).

II. Applications Microservices

Le magie de l’architecture microservices découpe votre volumineuse application monolithique en des composants individuels appelés les microservices. Chaque composant est autonome et se charge d'une seule logique métier (Dans la plupart des cas).

Prenons l'exemple simple de Netflix, qui tend à avoir un MS pour faire une recherche, un autre pour lire les vidéos, un autre qui se charge des recommandations etc ..

Chaque MS est son propre maître, chacun sa propre version et il est déployé séparément des autres.

II. 1 Avantages

• Meilleure maintenabilité : Imaginez une application comme un restaurant, chaque partie du restaurant est gérée indépendamment. La cuisine, le service, et la caisse fonctionnent séparément. Si la cuisine a un problème, la caisse et le service continuent de fonctionner. Si on veut ajouter un plat, on ne change que la cuisine sans impacter le reste.

• Plus de fiabilité : Votre application devient plus fiable car il y a moins de risques que votre système entier tombe en panne à cause d'un problème avec l’un des MS.

• Evolutivité optimisée : Contrairement aux applications monolithiques, si l’un des microservices reçoit beaucoup de trafic, il suffit juste de d’évoluer tout simplement le MS concerné (Augmentation de mémoire, CPU, etc ..). Et cela réduit le coût de maintenance de votre application.

• Déploiement continu : Enfin, si vous souhaitez faire plusieurs releases par jour, vous devez vous assurer que chaque modification puisse être facilement testée et automatisée. Si vous travaillez sur une application monolithique, c'est très difficile, car même les plus petites modifications peuvent impacter l'ensemble de votre application. Avec les microservices, en revanche, la modification se limite à un petit composant, qui peut être testé et déployé indépendamment.

"Les microservices, c’est un peu comme avoir plein de chats au lieu d’un seul gros chien : plus de liberté, mais aussi plus de boulot pour les nourrir et les empêcher de semer le chaos !"

II. 2 Inconvénients

• Développement local plus complexe : Si votre microservice dépend fortement d’autres services pour fonctionner, son exécution en local devient un vrai défi. Vous devrez soit simuler leurs endpoints, soit faire tourner l’ensemble des services dans des conteneurs Docker. C’est faisable, mais bien plus complexe que de lancer une seule application monolithique.

• Débogage plus délicat : Avec les microservices, traquer un bug devient un vrai casse-tête. Au lieu de chercher l’aiguille dans une seule botte de foin, il faut explorer plusieurs services pour comprendre d’où vient le problème. Une bonne observabilité est indispensable !

• Coût plus élevé : Les microservices peuvent effectivement réduire les coûts d’infrastructure, mais seulement si votre application doit évoluer à grande échelle. Pour une petite application, ils risquent au contraire d’alourdir la facture en imposant une infrastructure plus complexe que nécessaire.

• Complexité accrue : Les microservices ajoutent une couche de complexité à votre système et à votre infrastructure. La gestion des pipelines CI/CD, la communication entre services et la surveillance deviennent rapidement des défis à part entière. Ce qui semble simple avec quelques services peut vite se transformer en un véritable défi opérationnel à grande échelle.

3. Monolithe ou Microservices : Comment trancher ?

**Opter pour un monolithe si 😗*

• Vous démarrez un nouveau projet sans contraintes d’intégration.
• Vous êtes une startup et devez aller vite avant d’optimiser la scalabilité.
• Vous voulez limiter la complexité et les coûts au lancement.

**Opter pour les microservices si 😗*

• Votre application doit s’intégrer à un système déjà en place.
• Vous attendez une charge massive dès le départ.
• Vous avez besoin d’une scalabilité fine et optimisée.

Et pourquoi pas une approche hybride ?

Si vous envisagez les microservices à terme, commencez par un monolithe modulaire :

• Identifiez les composants pouvant être isolés.
• Détectez les points sensibles en termes de scalabilité.
• Scindez progressivement les parties critiques en microservices.

Conclusion

Il n’y a pas de réponse unique. Netflix, Uber et bien d’autres ont commencé en monolithe avant de basculer vers les microservices quand cela s’est avéré nécessaire. L’essentiel est d’adopter une architecture adaptée aux besoins actuels tout en gardant la flexibilité d’évoluer.

Plutôt que de suivre une tendance, construisez une architecture qui accompagne la croissance de votre projet sans ajouter de complexité inutile.