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