Aujourd’hui nous nous penchons sur les architectures microservices et monolithiques ! Quelles sont leurs caractéristiques principales, leurs cas d’usage, leurs forces et faiblesses ? Vous êtes au bon endroit pour vous poser ces questions !

Schéma d’occupation des ressources

Pour comprendre les différences entre les architectures microservices et monolithiques, rien ne vaut un bon schéma explicatif ! 

Monolithique

L’application monolithique, à gauche, est conçue avec un ensemble de modules métiers en son sein. Ceux-ci varient d’un métier à l’autre mais sont complémentaires et constituent, tous ensemble, une application.  

Cependant, l’une des particularités de l’architecture monolithique est que l’application utilisera toujours les ressources (mémoire, disque ou CPU) du métier le plus gourmand. Le métier A, par exemple, sur notre schéma. Y compris quand celui-ci est inactif, c’est le métier B ou C qui sont en train de s’exécuter. 

Microservices

à des points forts….

• Architecture calibrée au métier pour une utilisation optimale des ressources. Car chaque domaine métier a sa propre application. Par exemple, si 80 % de l’usage de l’application globale (les 3 métiers) est lié au métier B sur le schéma, celle-ci ne consomme que les ressources prises par ce métier, sans tenir compte des métiers A et C ! 
• La séparation de la gestion des métiers est totale.
• Optimisation supérieure donc économie de temps, donc économie d’argent ! 

… mais aussi des limites.

• Le schéma le montre bien : il y a 3 applications différentes dans l’architecture microservices, donc 3 fois plus de travail pour tout ce qui touche à la mise en place de l’app ! (3 déploiements, 3 phases de tests…).
• Il est quasi impossible de penser une architecture microservices sans automatisation, sinon la charge est trop importante ! D’autant plus que l’exemple de notre schéma est limité à 3 applications, mais pour certains grands groupes, on dépasse allègrement les 100 ! À cette échelle, et sans automatisation, les bienfaits de l’architecture microservices sont gommés par le temps de déploiement qui est trop important. 

Depuis la création d’AWS, on est passé d’une tarification au mois pour l’usage d’un serveur, à une tarification à la ressource utilisée ! 

La communication au sein des architectures monolithiques ou microservices ! 

Architecture Monolithique 

La communication au sein d’une architecture monolithique est facilitée par le fait que les différents métiers partagent la même application ! 

L’appel d’une fonction est on ne peut plus simple ! Cela fait partie des bases de la programmation, et s’effectue sans difficulté aucune.

Architecture Microservices

C’est plus complexe ! En effet, avec différents métiers au sein de différentes applications, dont les équipes peuvent être situées à plusieurs milliers de kilomètres d’écart, pas facile de gérer toute la communication de ce type d’application ! 

Il existe une solution pour contrer cette difficulté : le déploiement d’un bus. 

Ce bus permet d’assurer la communication entre les différents métiers avec un certain prix en termes de ressources également, car le bus est une application à part entière qui a besoin de mémoire et de puissance pour fonctionner… Autre effet de bord, cela complexifie l’application au global. 

Cependant, cela peut être un mal pour un bien ! En effet, cela oblige à bien prendre conscience de toutes les communications ayant cours au sein de l’application, et donc cela permet de souligner des points d’optimisation de ces communications. 

Les données en architecture microservices et en architecture monolithique 

Architecture Monolithique 

Simple et efficace ! Comme sur le schéma ci-dessus, la base de données est commune aux différents métiers qui peuvent ainsi communiquer facilement et rapidement avec elle !

Architecture Microservices

Il est théoriquement possible de créer, à la manière d’un bus, une base de données qui communiquera avec les différents métiers. Cependant ce n’est pas la manière la plus optimisée ! En effet, les microservices offrent la possibilité d’utiliser une base de données pour chaque métier !   

D’une part, cela pousse à optimiser la communication avec les données, à l’instar des communications plus haut. Et d’autre part, cela permet d’engager un début de réflexion sur la séparation des données. Cela va très certainement simplifier votre mise en conformité avec la gestion des données induite par le RGPD ! 

Grâce à une compartimentation/segmentation des données, la sécurité et l’utilisation des ressources est améliorée !

Et du côté dév’, alors ? 

Application plus petite = moins de code / Moins de code = moins de bugs. Logique non ? 

De plus, les applications sont différentes donc différents socles techniques peuvent cohabiter pour chaque application ! Ce qui est assez novateur et plutôt pratique pour le développeur. Celui-ci n’aura pas besoin de penser comment paramétrer chaque connexion. Grâce au bus de communication, ces socles techniques différents ne créent pas de difficultés accrues.

Cela permet de choisir la technologie la plus adaptée pour réaliser la tâche liée au métier, plutôt que de privilégier une technologie compatible avec le reste de l’écosystème, mais moins efficace dans la réalisation de sa tâche. 

Globalement, vous gagnerez du temps sur tout ce qui ne concerne pas l’architecture. Cepandant celle-ci vous demandera plus d’efforts pour être mise en place. 

Et la sécurité dans les architectures microservices ? 

Vaut-il mieux une application monolithique, d’un seul bloc, mais sans interconnexions pouvant laisser apparaître des faiblesses, ou au contraire un cloisonnement des métiers qui empêche une intrusion globale après un seul hack ? 

Nos experts privilégient globalement la deuxième solution, puisqu’une seule faille permet d’accéder à la totalité des données, quelles que soient les mesures mises en place au sein de l’application. 

L’avantage des microservices sur ce point est donc sa complexité ! En effet, une faille permettra d’accéder à un métier, mais ne permettra pas de cracker toute l’application comme sur les exemples monolithiques. Cette conteneurisation est donc un avantage pour la sécurité globale de votre écosystème. 

Le bus de données : point névralgique sensible d’une architecture microservices 

Il concentre toutes les communications de l’application ! Il faut absolument lui accorder une importance accrue, car si quelqu’un y accède, il peut voir la totalité des communications effectuées sur l’application. 

Microservices 101, c’est terminé ! D’autres parties sont à suivre, concernant notamment Kubernetes, alors stay tuned ✌️

Un retour, une suggestion ? N’hésitez pas 👇