Mettre en place une Plateforme Microservices

Définition architecture microservices

Pour faire simple, une architecture microservices est une architecture logicielle où les services sous forme d’API sont totalement dissociés les uns aux autres. Pour cela, nous allons mettre en place une plateforme microservices.

Différents outils vont ainsi appeler les API de cette plateforme qui devient presque le centre de votre système d’information pour les exploiter : front-office, back-office… Ceux-ci ne font que mettre en forme les données traitées par cette plateforme microservices.

Seul un couplage faible doit être autorisé et cela uniquement dans des cas particuliers où ce couplage ne fait pas perdre l’indépendance de chaque service ; nous verrons cette particularité plus tard.

Cette image représente parfaitement une architecture microservices où chaque rond représente un service différent.

Architecture microservice et devops

Une architecture microservice prend tout son sens quand on fait du devops et d’autant plus dans cette époque où les différents canaux se multiplient (ordinateur, site mobile, app mobile, app tablette…). Grâce à ce type d’architecture, on pourra facilement gérer les déploiements et faire de la scalabilité sur des services d’hébergement en Cloud.

Faire ce type de plateforme est très Agile dans le concept car nous pourrons ajouter des serveurs automatiquement (ou à la demande) sur les services qui semblent demander plus de ressources que d’autres services. On pourra facilement créer un nouveau service en cas de besoin dans notre plateforme microservices.

Ce n’est pas simple au premier abord de bien comprendre les enjeux mais cet article a pour but de vous éclairer au mieux sur le sujet.

Créer ma plateforme microservices

Nous allons voir ensemble comment créer une plateforme microservices et je vais en profiter pour vous exposer les pièges qu’il faut impérativement éviter et connaitre pour ne pas bloquer sur certains points spécifiques.

La technologie à utiliser ?

Aucune technologie n’est obligatoire pour faire une architecture microservices ; je vous conseille d’utiliser un langage réputé rapide et de faire attention à l’éventuel framework que vous utiliserez pour vous aider.

Venant principalement du monde PHP, je sais que les soucis de performances de Symfony peuvent être un frein considérable pour faire une plateforme microservices efficace. Faites le bon choix car cela aura un impact certain. Votre choix doit également prendre en compte les technologies des équipes en place pour ne pas créer de la frustration et risquer une augmentation du turn-over.

Voici comment fonctionnent mes services de base

Le concept du microservices est très particulier et mes paragraphes précédents n’étaient peut-être pas très clair pour vous. Voici à présent du concret avec quelques schémas simples à comprendre.

Une plateforme microservices va totalement dissocier ses dépôts. Si vous utilisez un gestionnaire de version tel que Git, vous aurez donc un dépôt par service. Un service est un ensemble d’API qui auront des parties communes très fortes.

Par exemple, si je veux faire un site ecommerce je pourrais avoir comme service les services suivant :

• un service produit
• un service commande
• un service panier
• un service user

Pour ceux qui ne viennent pas du monde ecommerce, on considère une commande, la transformation d’un panier qui a été validé intégralement (ainsi que le paiement associé).

Comme je le disais, un service propose différentes API afin de proposer un maximum de flexibilité aux outils utilisant ce service. Par exemple dans notre cas nous pourrions avoir getProduct (get, post, update, delete), getCategory (get, post, update, delete) et getProductByCategory (get, post, update, delete). j’ai rassemblé la notion de categorie à la notion produit car les liens sont trop forts entre les produits et les catégories.

N’oubliez pas qu’un service ne communique pas avec un autre service par des API pour garder un maximum d’indépendance de chaque service.  Chaque service aura également sa propre base de données totalement indépendante de celles des autres services.

Comme vous le comprendrez, un panier a un lien avec l’utilisateur. Cependant ce lien est beaucoup moins fort que l’exemple précédent car seul l’identifiant de l’utilisateur est nécessaire sur le panier. Si certains s’y tentent, il ne faut jamais dupliquer une table sur deux bases de données car des désynchronisations finissent toujours par arriver. La base de données panier n’aura donc pas de table utilisateur et c’est l’outil qui utilise nos services qui devra chercher l’utilisateur correspondant grâce à l’identifiant retourné par le service panier.

Faire des API

Notre plateforme microservices est un ensemble d’API offertes aux différents outils qui vont exploiter vos données. L’utilisation d’API Restful sera parfait pour monter son architecture microservices.

Indépendant mais pas différent

Le premier soucis qu’on voit en faisant ce type d’architecture, c’est qu’on copie plusieurs fois le même code qui finit par se différencier avec le temps. Cela implique qu’il faut mettre à jour la base de tous les services en cas de besoin de changement (exemple lors de la découverte d’une faille de sécurité généralisée).

Comme le propose certains Framework, je vous conseille de bien prévoir la séparation du core applicatif et du contenu de vos services. Cela permettra de mettre à jour chacun de vos services très rapidement sans toucher au contenu de vos API.

Il est important de faire le refactoring de tous les services à chaque changement sur le core applicatif afin de ne pas vous retrouver avec des core applicatifs différents. Ne pas le faire n’aura pas d’impact le jour même mais en aura sur le long terme : équipes démotivées d’avoir X systèmes à maintenir pour ne citer qu’un problème parmi plusieurs…

Le devops amène beaucoup de notion de tests automatisés (proche du XP) qui sont essentiels à une plateforme microservices. Ces tests permettront de faire votre refactoring beaucoup plus facilement quand vous en aurez besoin ce qui finit toujours par arriver un jour.

Et si je veux croiser mes données de façon complexe ?

Si vous avez bien compris le début de l’article, vous pourriez à présent vous poser une question simple qui est souvent le premier problème rencontré lorsque nous désirons mettre en place une architecture microservices : comment puis-je faire un moteur de recherche complet et intelligent ? Comment puis-je faire des boards complexes en calculs (avec des liens entre les données de tous les services ) ? Comment utiliser un CRM externe ?

Solution MOM et des outils Saas

Pour ceux qui ne connaissent pas ce terme, un logiciel Saas est un logiciel en tant que service avec qui on communique par l’intermédiaire de web service et en général en Restful ces dernières années.

Une solution « message-oriented middleware » (MOM) est un logiciel qui permet d’échanger des messages entre différentes applications. La solution la plus connue et la plus populaire à ce jour est RabbitMQ.

Nous allons nous autoriser dans notre architecture microservices de l’utiliser pour communiquer entre services mais uniquement dans le cadre d’un couplage faible (nous allons voir en-dessous du schéma ce concept de couplage faible).

Nous allons par exemple imaginer un nouveau service particulier que nous appellerons le service mapping. Celui-là permettra de communiquer directement avec toutes les solutions externes. Voici un schéma pour se faire une idée :

En effet, on est déjà sur des architectures qui se complexifient mais pour faire simple nous communiquons d’un service à un autre grâce à RabbitMQ en envoyant des données sous format Json afin de pouvoir les retraiter facilement par le service qui va lire le message.

Nous sommes là dans un concept de faible couplage car le service mapping ne recevra plus de message du service panier si celui a un bug mais il fonctionnera toujours sans le moindre soucis (pareil pour le service commande qui continuera à fonctionner sans soucis). Nos services restent dans ce cas totalement indépendants.

Cette méthode ne doit être utilisée que dans le but de transiter de l’information mais jamais pour obtenir une information indispensable au fonctionnement du service ; de plus, n’utilisez pas cette méthode pour dupliquer des données entre plusieurs services car cela vous causera de gros soucis à l’avenir. Il est impératif de garder l’indépendance de chaque service à 100%.

Conclusion Plateforme Microservices

Si ce tutoriel est très théorique, j’ai eu la chance de pouvoir mettre une plateforme microservices en place qui a évolué sur 6 mois. Malgré les changements de stratégie de l’entreprise, la plateforme a pu s’adapter à ces changements car ce type de plateforme est vraiment adapté à des organisations Agile.

J’espère que le concept de plateforme microservices est un peu plus clair pour vous et que cet article vous permettra de mieux cerner les enjeux d’une telle plateforme. Si c’est l’architecture à la mode en ce moment, elle n’est pas si simple à mettre en place et encore moins quand on n’a pas compris dès le départ les avantages mais également les problématiques de ce type d’architecture.

Si vous avez des questions sur le sujet ou que certains points ne sont pas très clairs, n’hésitez pas à laisser un commentaire afin que je puisse vous aider à y voir plus clair.