Discussion :

[Cafeinoman]

Bonjour à tous.

J'étudie depuis quelques temps déjà l'architecture microservices, qui est ma fois fort intéressant. Cependant, j'y vois un soucis que je n'arrive pas à régler : le client.

Avec des services REST, pas de soucis, l'utilisation d'une gateway qui fait du dispatch fonctionne très bien. En revanche, dès que l'on veux ajouter un client web se pose un problème : comment gérer dynamiquement les services.

Pour l'instant, j'ai vue deux options, qui toute deux ont de gros inconvénients :

D'abord faire un client qui "connait" les services. Dans ce cas, on a une beau gros client qui enlève certaines parties lorsqu'il découvre qu'un service n'est pas accessible. Le soucis c'est que si on intègre un nouveau service, il faut (partiellement) réécrire le client, et le redéployer. Cela enlève, selon moi, une grande partie de l'intérêt de ce type d'architecture.

Deuxième options, chaque service expose son propre client et la gateway dispatch. Mais le problème est qu'il devient, sauf erreur de ma part, d'unifier certains aspect du client (template html, bibliothèques JS,...)

Peut-être que j'ai manqué quelque chose, j'aimerais donc avoir l'avis de la communauté et, si possible, des retours d'expérience ...

Merci d'avance.

[Luckyluke34]

Hello,

C'est assez confus, je comprends pas trop où se situe ton problème :

• A un niveau organisationnel : comment faire la transition vers l'utilisation d'un nouveau service sans rupture de dispo de l'application ?

• Au niveau modules de code : comment doit-on découper et rendre disponibles ses packages clients en fonction des micro-services proposés ?

• Au niveau paramétrage et runtime : où stocker les URI des services et assurer le failover d'un service non disponible à un moment donné ?

Sachant que tu relies ça à la notion de gateway mais j'ai du mal à voir le rapport. Pour moi, une gateway est un dispositif purement technique qui n'est pas du tout un prérequis pour faire des microservices.

Si c'est plutôt la 3ème option, peut-être qu'un outil comme ZooKeeper te conviendrait ?

Sinon, un podcast intéressant (plutôt orienté .NET mais assez générique) sur le sujet : http://dotnetrocks.com/?show=1249

[Cafeinoman]

Merci de ta reponse Luckyluke34.

Le problème est plutôt au niveau des modules de codes. Pour faire simple, j'ai un module client. Ce module sert un client javascript, connais les uri des services ainsi que leur états. Le module client, ainsi que les services, sont dans des containers docker et le load-balancing est effectué dans l'app. Donc pas de problème pour la continuité de service ou la découverte et le stockage des uri.

En revanche, je veux que lorsqu'un nouveau service entre en jeu, le module client lorsqu'il le découvre puisse modifier la partie javascript pour ajouter l'interface du nouveau service. Ce qui implique de nouvelles pages de formulaires, mais aussi une modification de la barre de navigation par exemple. Ce qui est impossible pour un client javascript compilé.

Reste donc deux options :

• servir un module par service, mais la navigation (par exemple) disparaît. Dans ce cas pas de soucis, le module client devient juste une forme de gateway pour les module client de chaque service.
• faire en sorte que le module client connaisse tout les services possible, et les intègre donc dans son ui, en les cachant si le service n'est pas dispo. Mais on perd alors la possibilité de déployer rapidement un nouveau service sans avoir a recompiler et redeployer le module client (même si la rupture de dispo au redéploiement est courte, je l'accorde)

J'ai peut-être trouvé la solution au problème avec le framework polymer. Chaque service sert alors ses propres web component, et le client les intègre. Ca semble répondre au problème, ce que je confirmerai après quelques test.

Je sais que ce n'ai pas une architecture microservices "classique" (même si je sers également du rest sur un autre port). J'espère avoir été plus clair en tout cas.

[Luckyluke34]

je veux que lorsqu'un nouveau service entre en jeu

Nouveau, genre totalement nouveau ? Comme un microservice dont le module client ne connaissait pas du tout le fonctionnel à l'instant T-1 ? Ou nouveau comme un widget qui rentre dans un moule de trucs tous à peu près pareils que le client peut gérer dynamiquement ? Ou, nouveau genre "j'étais down quelques temps, maintenant je reviens à la vie, je suis nouveau" ?

[Cafeinoman]

Genre presque totalement nouveau. Le seul pré-requis est de pourvoir coller à la decouverte de services. Dans les fait, j'ai une "charpente" pour chaque module, et un module sait s'il a des dépendances et si elle sont up.
Un exemple simple : le module client gère du crm et de la facturation (un ensemble d'une dizaine de services), et je lui fourgue des services qui vont gérer le plan d'un salon (emplacement de stand, invitations publiques,...). Le module client doit intégrer le routage des nouveaux services (ca c'est simple), et l'ui spécifique des nouveau services dans son javascript. D'où l'idee de polymer...

[Luckyluke34]

Honnêtement, j'ai jamais vu faire ça, ça a l'air assez fou-fou et je ne pense pas que ça soit l'utilisation la plus répandue de Polymer. Ce qui ne veut pas dire que ce n'est pas possible.

Par contre j'ai du mal à voir pourquoi le point central de ta question est les microservices alors qu'ils jouent un rôle assez peu important, en fait tu veux juste de la découverte/installation dynamique de modules ?

[Marco46]

faire en sorte que le module client connaisse tout les services possible, et les intègre donc dans son ui, en les cachant si le service n'est pas dispo. Mais on perd alors la possibilité de déployer rapidement un nouveau service sans avoir a recompiler et redeployer le module client (même si la rupture de dispo au redéploiement est courte, je l'accorde)

J'ai peut-être trouvé la solution au problème avec le framework polymer. Chaque service sert alors ses propres web component, et le client les intègre. Ca semble répondre au problème, ce que je confirmerai après quelques test.

Je sais que ce n'ai pas une architecture microservices "classique" (même si je sers également du rest sur un autre port). J'espère avoir été plus clair en tout cas.

Tu fais une confusion entre déployer un nouveau service sans impacter les autres, ça c'est ce que permet l'archi micro-service, et déployer une fonctionnalité métier supplémentaire (back + front) sans avoir à redéployer l'intégralité du back et l'intégralité du front.

Ce que tu veux faire c'est de la génération automatique d'ihm qui irait de pair avec l'ajout d'un nouveau service. A ma connaissance ça n'existe pas.

TLDR :
- l'archi microservice permet de ne déployer que le service concerné par un changement, cela n'a rien à voir avec le déploiement d'un front.
- tu confonds ajout de service avec ajout de feature.

[Cafeinoman]

@Marco46 :

Je ne pense pas faire de confusion, mais je dois mal m'expliquer. J'ai actuellement un archi avec pleins de petit services, exposé soit par l'eventbus soit en rest. Chacun sait qui est où, comment contacter ceux il a besoin,etc. Bref, il y a du service discovery. Pour avoir un point d'entrée a tout cela, j'ai mis en place un gateway, en rest. Celle-ci c'est quels services elle doit utiliser en se servant de certaines propriété du service discovery. En gros, si un service rest est marqué comme "user exposable", la gateway rajoute une route a son nom et dispatch les requêtes correspondantes. Mon service de log par exemple n'est pas exposé. En fait, les services exposé sont des sortes d'agrégateur qui exposent, eux, l'interface d'une feature.

Quand j'ajoute un service "exposable", jde n'ai pas besoin de dire a ma gateway que j'ai l'ai fait, elle le detecte et ajoute les route nécessaires. En revanche, si j'ai un client javascript pour cette gateway, lui ne le sait pas, et ne peu donc pas exploiter ces nouvelles routes. Cela me pose un problème : je peux déployer plein de nouveau services, mais s'ils ajoutes des features, mes utilisateurs ne le sauront que s'il travail directement avec l'api rest. Ce qui n'est pas le cas. Ou alors, je dois sortir une nouvelle version du client js...

Polymer semble apporter une réponse. Primo, je modifie la gateway pour quel livre du rest sur un port, et du client js sur l'autre. Quand elle detecte un nouveau endpoint exposable (un service particulier je le rappel), elle regarde dans les métadonnées s'il est ausi exposé en js. Si c'est le cas, il récupère les adresses des composants servis, et signale au client js par websocket interposés qu'il a de nouveau composants a importer, en lui donnant un emplacement relatif aux autres composant déjà dans le DOM. Le js importe les composants, modifie le DOM (ou pour être exact dom local du composant principal), et rafraîchissement les nouvelles features exposées sont visibles par l'utilisateur.

Cette architecture client ne semble pas rencontrer de gros problème, on verra si je me casse les dents en l'implémentant...

Peut-être que cela ne correspond pas à la définition des microservices stricto sensu (et dans ce cas je veux bien un éclaircissement), mais en tout cas ça répond à mes besoins.

@Lukyluke34

C'est vrai que ce n'est pas directement les services qui me posent problème, mais plutôt de répondre a la question suivante : comment réaliser un client aussi fluide que l'est un environnement microservice, tout en restant user-friendly? Je suis d'accord que c'est une idée un peu barrée et pas courante, mais j'ai pas trouvé d'outils courant qui réponde correctement au problème ...

[Luckyluke34]

Peut-être que cela ne correspond pas à la définition des microservices stricto sensu (et dans ce cas je veux bien un éclaircissement), mais en tout cas ça répond à mes besoins

Effectivement, pour moi ça va même à l'encontre d'un principe de base des micro-services qui est la séparation des responsabilités et le couplage faible. J'ai l'impression qu'à l'inverse, avec ce système, tu décris et déploies systématiquement une fonctionnalité métier conjointement avec une UI, en allant jusqu'à définir dans le microservice l'endroit où va être reflétée la fonctionnalité dans ton interface.

Les microservices et les architectures orientées services en général ont été développés dans des organisations (Amazon par exemple) où des équipes de développeurs sont fournisseurs d'autres équipes de développeurs. Un des gros avantages est leur déployabilité indépendante et que le code peut donc être écrit par des équipes différentes, éventuellement dans des langages différents, sur des plateformes différentes. Si tu lies les fonctionnalités métier à une façon particulière de les présenter à l'utilisateur au sein d'un même microservice, tu te coupes de cette possibilité de faire développer UI et back end par des équipes séparées indépendantes au niveau des technos et du code source.

Ceci dit, vérification faite, il y a bien des gens qui font des microservices qui incluent la logique front-end et font marcher ça avec Polymer : https://technologyconversations.com/...-microservices
Mais ce n'est pas de l'automatic discovery sur toute la chaine. L'UI est constituée de cases vides (des web components) qui vont se remplir en appelant le microservice. En cas de nouvelle fonctionnalité, il faut quand même modifier l'application pour aménager une nouvelle case au bon endroit, ça ne se fait pas automatiquement. Et heureusement, peut-être, parce qu'on n'a pas forcément toujours envie que dès le déploiement d'un microservice, l'UI soit changée.

[Marco46]

Ou alors, je dois sortir une nouvelle version du client js...

Ben oui. En microservice, chaque service est un livrable avec son propre n° de version, son propre workflow de déploiement. La question du client qui consomme ces endpoints est un problème complètement différent. Tes webservices n'ont pas à savoir quel client les consomme sinon tu crées une adhérence entre front et back.

Dans ton cas ça semble être un client js mais ça pourrait être un client android, un client lourd, un autre webservice, ... whatever.