L’architecture d’un système informatique peut être organisé de plusieurs façons. En n-tiers, en architecture orientée service ou bien en architecture microservice. Ici nous allons nous intéresser à cette dernière : l’architecture microservice. Mais qu’est-ce que c’est ? Pourquoi les géants du web comme Amazon et Netflix ont choisi cette architecture là plutôt qu’une autre?
Microservice – Qu’est-ce que c’est ?
Un peu d’histoire pour commencer, afin de placer chronologiquement ces architectures. A l’âge de pierre il y avait l’architecture n-tier qui posait des problèmes de haute responsabilité de l’application lors d’une maintenance. Puis vient l’ère des architectures orientées services qui proposent une boite à outils pour développer un système robuste sans ces problèmes de responsabilités lors de maintenance. Et enfin l’architecture microservice qui est une extension de la précédente mais qui propose un cadre nettement plus formel.
L’architecture microservice est une architecture logicielle au même titre qu’une architecture en n-tier ou bien une architecture orientée service. Elle possède ses propres caractéristiques, ses avantages et ses inconvénients. Une architecture microservice est un ensemble de plusieurs “petits” services. Un service étant un processus indépendant et faiblement couplé avec les autres, ayant sa propre tâche, sa propre finalité.
Nous avons donc plusieurs “petits” services qui communiquent entre eux. Et pour définir “petit”, on parle du périmètre (scope) du service, le service a un rôle, une fonction telle que gérer les points de fidélités des clients, seulement le nom du client et son nombre de point, ou bien une base d’emoji pour une application de chat. Le service a donc un périmètre fonctionnel ciblé avec son propre scope et ses propres données.
Ces services interagissent entre eux sous trois formes : en requêtes, commandes et évènements. Si vous le voulez bien, définissons ces trois termes :
– en requête : le microservice demande une information
– en commande : le microservice ordonne, il donne un ordre
– en évènement : le microservice signale une information, ou en reçoit une.
Les microservices communiquent en utilisant le protocole de leurs choix, le plus souvent c’est le protocole HTTP qui est utilisé. Mais le protocole de communication est défini par chaque microservice. Chaque microservice propose une API ( interface de programmation) publique, c’est-à-dire un point d’entrée pour les services appelant.
Mon microservice est-il bon ?
En voilà une bonne question ! J’ai isolé les fonctionnalités et les données dans des services avec un périmètre bien défini, les services communiquent entre eux… Mais est-il viable ? Répondons à cette question en énumérant plus précisément les caractéristiques d’un bon microservice.
“Single Responsability Principe”
Chaque service de notre microservice a bien son périmètre défini. Il ne doit pas y avoir de service avec deux fonctionnalités, comme dit précédemment il doit être le plus “petit” possible. Et doit posséder ses propres données comme l’exemple du service points de fidélité qui ne possède que le nombre de points de fidélité d’une personne et non pas le nom, plus les points, le lieu d’achat, type d’achat…. Ces données-là sont dans d’autres services. Les intérêts de ces services n’ayant qu’une seule fonctionnalité sont qu’ils sont facilement localisables et remplaçables. Plus le service est petit et plus il sera remplaçable, sauf s’il est complexe algorithmiquement.
“Clustered” et “Single point of failure”
Clustered est le terme désignant la redondance des services si le premier n’est pas accessible, un second l’est, voyons-le comme une roue de secours localisée ailleurs. C’est une réplication d’instance du service pour garantir une haute disponibilité dans le cas d’une défaillance technique, comme l’arrêt d’une machine ou d’une panne réseau. Cela permet d’éviter le Single Point Of failure, le fait qu’un nœud ne répond plus et qui entraîne donc l’arrêt du système.
“Monitoring”
Vient le diagnostic, qui est facilement réalisable grâce à l’indépendance des services. L’état de santé de chaque service est, si possible, réalisable d’un coup d’œil. Ce que facilite grandement la tâche de maintenance. Comment voir si le service répond correctement ? L’envoi d’une simple requête permet de le vérifier.
Si ces trois principes majeurs sont respectés, alors notre service est bon et fonctionnel.
Pourquoi se diriger vers une architecture micro-service ? Quels sont les pré-requis ?
Le DSI souhaitant développer son système ou proposer un nouveau produit et l’entrepreneur à l’idée révolutionnaire attendent cette question… Pourquoi devrais-je adopter une architecture microservice pour mon projet au lieu d’une architecture en n-tier ?
Chaque architecture est adaptée au besoin du projet. Un peu plus haut nous avons parlé de Netflix et d’Amazon. Ils ont opté pour cette solution car leurs projets sont amenés à évoluer sans cesse. Cela se définit en début de projet, posez-vous cette question “mon projet est-il amené à évoluer ?”. Lorsqu’on parle d’évolution, on parle d’évolution majeur et régulière. Opposons Note et Notepad, pour Note on se dirigerait en architecture n-tier et pour notepad en microservice car le système est toujours en amélioration avec des mises à jour majeures.
Rapide rappel, si on parle d’une architecture en n-tiers, on parle d’une architecture où on empile les fonctionnalités d’une manière ordonnée ( verticale). Les fonctionnalités sont dans un même package, dans un seul et même système. Les systèmes d’architecture n-tiers sont très souvent réalisés avec la méthode de développement dite cycle en V. Pour ce qui est de l’architecture microservice, cette architecture est très adaptée aux méthodes de développement agiles. Pour ne froisser personne, on peut faire une architecture microservice en cycle en v, et une architecture en n-tiers en méthode agile. Il n’y a pas d’impératif.
Quels sont les prérequis pour une architecture microservice ? C’est à ce moment que l’entrepreneur et le DSI regarde chacun leur budget et le délai qu’ils disposent.
Pour ce type d’architecture, il faut posséder les ressources financière, humaines et temporelle. Ces trois données sont à prendre en compte. Plus le projet est grand, plus il faut mobiliser de personne, les services sont répartis à des petits groupes de personnes. Chaque groupe reste dans son périmètre, concentré sur son service, personne ne s’éparpille. La définition des specs est plus longue et rigoureuse, le développement est plus long et va demander plus de temps. Plus de personnes sont mobilisées, sur de plus longues durées et influent sur le coût du projet.
Un lien avec l’agilité vous avez dit ?
En effet, la méthode de développement agile est idéale pour la réalisation d’une architecture microservice. Il s’agit la d’un management horizontal. Les future Team sont mises en avant notamment avec les devops en ce qui concerne le déploiement. Les sprints favorisent les améliorations, il n’est pas rare de voir une nouvelle fonctionnalité apparaître après un sprint. Les équipes techniques et fonctionnelles sont en réelle synergie.
Le développement est divisé et attribué à différentes équipes. Chaque équipe se voit attribuer le développement d’un service pendant un sprint. Dans l’avenir la maintenance est toujours facilement réalisable et programmable. Une maintenance, une amélioration peut être fixées sur une période.
