jeudi 22 octobre 2020

Concevoir une architecture de microservices en 3 étapes

 

Concevoir une architecture de microservices n’est pas simple, même les praticiens expérimentés font face à d’importants défis dans un tel projet.  Lorsqu’on s’y prend mal, il y a des risques qu’on se retrouve avec un monolithe distribué. Plusieurs organisations qui pensaient faire de l’architecture des microservices se sont retrouvées avec ce type de monolithe qui apporte encore plus de problèmes qu'un monolithe classique.

Définir une architecture de microservices est plus un art qu'une science, mais il existe un certain nombre de stratégies qui peuvent aider.  Dans cet article, je revisite une démarche de conception d’une architecture de microservices en trois étapes. Dans la première étape, on identifie les opérations systèmes, dans la seconde on identifie les services, et dans la troisième, on détermine les API des services.

Comme pour tout effort de développement logiciel, le point de départ est constitué des exigences d’affaires documentées, des échanges avec les experts du domaine si on est chanceux de les avoir, et peut-être une application existante.

Le but d’une application est de traiter les demandes (requêtes) soumises par les clients, qui peuvent être des utilisateurs ou d’autres systèmes. La première étape de la définition de l’architecture d’une application consiste donc à transformer les exigences d’affaires en demandes ou requêtes pour le futur système. Nous identifions ces demandes à ce niveau, par la notion abstraite d’« opération système », plutôt que de parler des technologies IPC spécifiques comme le REST ou la messagerie. Une opération système est une abstraction d'une demande/requête que l'application doit traiter. Il s'agit d'une commande qui met à jour les données, ou d'une requête qui interroge les données. Le comportement de chacune est défini avec les termes d'un modèle de domaine abstrait, qui est également dérivé des exigences. Les opérations systèmes deviennent alors des scénarios d’architecture qui illustrent la manière dont les services collaborent.

La deuxième étape du processus consiste à procéder à l’identification des services. Il faut alors décomposer l’ensemble du domaine de l’application en plusieurs fragments qui deviendront des microservices. Il existe plusieurs approches avec le même résultat final : des services organisés autour des concepts d’affaires plutôt que de concepts techniques.

La troisième étape consiste à déterminer l'API de chaque service. Pour ce faire, on affecte chacune des opérations systèmes identifiées à la première étape à un des services obtenus à la seconde étape. Une opération peut être implémentée entièrement par un seul service, mais  plusieurs services peuvent aussi collaborer pour implémenter une opération. Dans le second cas, il faut déterminer la manière dont les services vont collaborer, ce qui nécessite généralement que de nouvelles opérations soient ajoutées à certains services. C’est aussi à cette étape qu’on décide quel mécanisme de communication sera utilisé pour implémenter l'API de chaque service, mécanisme synchrone comme REST ou messagerie asynchrone.

Présenter aussi simplement, ça paraît bien facile. Mais attention, ce n’est pas un processus qu’on peut suivre mécaniquement. Le processus se veut itératif et exige beaucoup de créativité.

Pour explorer plus en détail les étapes de ce processus, reportez-vous à ce cours sur la plateforme Udemy : Conception d’une architecture de microservices


Références:



Aucun commentaire:

Enregistrer un commentaire