J’ai précédemment évoqué les évolutions du SI qui nous ont fait passer des applicatifs monolithes aux architectures SOA. La notion de service a amené à l’idée ensuite des architectures en microservices, qui sont une tendance de fond dans la conception actuelle des architectures IT.
Les limites du monolithe
Pour comprendre l’idée des microservices, essayons de prendre un exemple opposé.
Imaginons qu’il faille développer une application de gestion de devis. L’application devra par exemple comporter les fonctionnalités suivantes:
- je dois pouvoir me connecter (vérifier mot de passe et autorisations)
- créer un devis
- enregistrer le devis
- générer un pdf de mon devis
- et l’envoyer par mail
L’application pourra ainsi être développée comme un seul et unique bloc… C’est la notion de monolithe.
En quoi est-ce problématique?
Imaginons qu’il y ait un problème ou une évolution et qu’il faille modifier le code et redéployer l’application. Ou à l’inverse que tout fonctionne bien, mais que devant le succès de mon application et son utilisation massive, il faut augmenter les capacités allouées à la génération des pdf (par exemple). Je dois alors modifier, déployer ou redimensionner toute mon application.
Cela va me prendre du temps (vérifier que je n’ai pas cassé autre chose au passage), arrêter l’ensemble de mon application et potentiellement m’obliger à redimensionner toute mon infrastructure. C’est donc risqué de modifier mon monolithe et ça limite l’évolutivité du SI.
C’est là que les microservices interviennent.
Etape 3 : des microservices pour découper le monolithe
Ils sont la transposition du concept de service (SOA) entre les applications, au niveau de l’application métier elle-même. Je m’explique…
Au lieu d’imaginer une application comme un ensemble de fonctions liées entre elles, chaque fonction est quasiment vue de façon autonome. La fonction est un service, complètement indépendant des autres. Les microservices communiquent entre eux via des protocoles standardisés.
A l’extrême, on peut presque considérer que chaque microservice est une application à part entière… Si je reprends l’exemple ci-dessus, les différentes lignes (connexion, création du devis, enregistrement…) sont autant de microservices différents. On va alors les concevoir et les faire vivre de façon complètement indépendante des autres.
Ainsi, je peux alors faire évoluer les microservices, les déployer, les dimensionner beaucoup plus facilement et avec une grande souplesse !
Vous trouverez par exemple chez Red Hat ou sur cette video (un peu décalée…) des informations complémentaires.
Les avantages des microservices
Je vois 4 avantages principaux aux microservices.
D’abord, puisqu’ils apportent de la souplesse, ils donnent au métier, plus de réactivité par rapport à leurs orientations. En cas de changement, fonctionnel je vais pouvoir faire évoluer chaque fonctionnalité de façon autonome. Je vais ainsi pouvoir « pousser en production » une mise à jour d’un microservice sans attendre les autres. Ainsi je vais pouvoir faire évoluer plus rapidement mes fonctionnalités.
Ensuite, on va pouvoir dimensionner l’infrastructure de façon plus souple. Si un des services consomme plus de « ressources machine » je vais pouvoir lui en allouer rien qu’à lui et pas à toute l’application. Au final, cela réduit les coûts d’infrastructure: à activité équivalente, je consomme moins avec les microservices !
Par ailleurs, l’architecture du code étant ainsi très modulaire, en cas de panne ou de bug, on va pouvoir détecter beaucoup plus facilement la source du problème. On identifie directement le microservice défaillant et c’est celui-là qui est corrigé.
Enfin, chacun des microservices étant indépendant il va être développé dans son propre langage sans se soucier des autres. En termes d’organisation du travail et de performance globale de l’application c’est un plus énorme. On va pouvoir positionner des équipes différentes sur un même projet, chacun travaillant dans son propre langage. On peut aussi choisir les technologies les plus adaptées en fonction de ce qui doit être réalisé. De même, si une nouvelle technologie fait son apparition, on pourra la tester et l’intégrer facilement.
Rapidité, Réduction des coûts, réactivité, évolutivité et performance… les microservices ont tout pour plaire, non? Voyons voir si on peut trouver encore mieux…
Découvrez l’interview de Jérémy Amourous, DSI de Colissimo, qui explique comment l’entreprise a su tirer partie de la mise en place d’une Architecture Réactive en temps réel.
(Merci à Wilmer pour ses inputs sur cet article!)
Les sujets qui m’intéressent le plus sont Data, Organisation et Temps Réel !
N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour partager nos actualités!
Andrea
