IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Architecture Discussion :

Microservices et client web dynamique


Sujet :

Architecture

  1. #1
    Membre éprouvé
    Avatar de Cafeinoman
    Homme Profil pro
    Couteau suisse d'une PME
    Inscrit en
    Octobre 2012
    Messages
    628
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Couteau suisse d'une PME

    Informations forums :
    Inscription : Octobre 2012
    Messages : 628
    Points : 1 256
    Points
    1 256
    Par défaut Microservices et client web dynamique
    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.
    «Dieu ne joue pas aux dés.» - Albert Einstein. Et pan! 30 ans de retard dans la théorie quantique!
    «Tout n'est pas politique, mais la politique s'intéresse à tout.» - Nicolas Machiavel. Et surtout à ceux qui ne s'y intéressent pas.

  2. #2
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    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

  3. #3
    Membre éprouvé
    Avatar de Cafeinoman
    Homme Profil pro
    Couteau suisse d'une PME
    Inscrit en
    Octobre 2012
    Messages
    628
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Couteau suisse d'une PME

    Informations forums :
    Inscription : Octobre 2012
    Messages : 628
    Points : 1 256
    Points
    1 256
    Par défaut
    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.
    «Dieu ne joue pas aux dés.» - Albert Einstein. Et pan! 30 ans de retard dans la théorie quantique!
    «Tout n'est pas politique, mais la politique s'intéresse à tout.» - Nicolas Machiavel. Et surtout à ceux qui ne s'y intéressent pas.

  4. #4
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    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" ?

  5. #5
    Membre éprouvé
    Avatar de Cafeinoman
    Homme Profil pro
    Couteau suisse d'une PME
    Inscrit en
    Octobre 2012
    Messages
    628
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Couteau suisse d'une PME

    Informations forums :
    Inscription : Octobre 2012
    Messages : 628
    Points : 1 256
    Points
    1 256
    Par défaut
    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...
    «Dieu ne joue pas aux dés.» - Albert Einstein. Et pan! 30 ans de retard dans la théorie quantique!
    «Tout n'est pas politique, mais la politique s'intéresse à tout.» - Nicolas Machiavel. Et surtout à ceux qui ne s'y intéressent pas.

  6. #6
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    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 ?

  7. #7
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 608
    Points
    19 608
    Par défaut
    Citation Envoyé par Cafeinoman Voir le message
    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.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  8. #8
    Membre éprouvé
    Avatar de Cafeinoman
    Homme Profil pro
    Couteau suisse d'une PME
    Inscrit en
    Octobre 2012
    Messages
    628
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Couteau suisse d'une PME

    Informations forums :
    Inscription : Octobre 2012
    Messages : 628
    Points : 1 256
    Points
    1 256
    Par défaut
    @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 ...
    «Dieu ne joue pas aux dés.» - Albert Einstein. Et pan! 30 ans de retard dans la théorie quantique!
    «Tout n'est pas politique, mais la politique s'intéresse à tout.» - Nicolas Machiavel. Et surtout à ceux qui ne s'y intéressent pas.

  9. #9
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    Citation Envoyé par Cafeinoman Voir le message
    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.

  10. #10
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 608
    Points
    19 608
    Par défaut
    Citation Envoyé par Cafeinoman Voir le message
    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.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  11. #11
    Membre éprouvé
    Avatar de Cafeinoman
    Homme Profil pro
    Couteau suisse d'une PME
    Inscrit en
    Octobre 2012
    Messages
    628
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Couteau suisse d'une PME

    Informations forums :
    Inscription : Octobre 2012
    Messages : 628
    Points : 1 256
    Points
    1 256
    Par défaut
    On est d'accord alors! Vue que mes services d'aggregations, ceux qui fournissent le js, sont independant des services qui font le "vrai" travail... Si je décide par exemple par exemple de refaire le look d'un service d'aggregation js, je n'ai pas à toucher à son backend. De même, si je décide de rajouter une route qui donne l'heure à la partie web service. C'est un peu comme si, pour un client lourd, tu fournissais un blueprint osgi qui découvre les webservices existant et qui télécharge et lance les bundles correspondant (ça pourrait être marrant à faire d'ailleur). Le service qui fournit les bundles reste un service tiers...
    «Dieu ne joue pas aux dés.» - Albert Einstein. Et pan! 30 ans de retard dans la théorie quantique!
    «Tout n'est pas politique, mais la politique s'intéresse à tout.» - Nicolas Machiavel. Et surtout à ceux qui ne s'y intéressent pas.

  12. #12
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 608
    Points
    19 608
    Par défaut
    On est d'accord alors!
    Pas vraiment !

    On va reprendre du début, tu proposais 2 solutions d'architectures :

    - "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,...)"

    Je te propose de benner la 2ème option qui me semble être une hérésie. Le backend n'a pas à connaitre la solution front. C'est au front de connaitre le back. Point final. Si tu veux faire de la génération dynamique d'ihm en fonction d'une découverte automatique de endpoints REST, pourquoi pas ! Mais ce n'est pas une problématique à se poser du point de vue de tes webservices. C'est une problématique front. Ton angle d'attaque pour résoudre ce problème c'est de dire : "je vais avoir des WS qui vont porter leur ihm". Non c'est pas bon. Tu choisis une techno front, et tu réfléchies à comment obtenir un front qui s'auto-génère les ihm en fonction des WS qu'il découvre, ça veut dire que tu as un livrable séparé, un repo séparé, un versionning séparé, etc ...

    Toute approche voulant mettre du front dans le back est forcément mauvaise puisque tu crées une adhérence bidirectionnelle énorme entre 2 systèmes dont un seul devrait une adhérence sur l'autre.

    Réfléchis en terme de livrable et de versionning. Tu veux corriger un problème CSS sur une ihm, tu vas relivrer ... Un webservice ? wtf ?!?
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  13. #13
    Membre éprouvé
    Avatar de Cafeinoman
    Homme Profil pro
    Couteau suisse d'une PME
    Inscrit en
    Octobre 2012
    Messages
    628
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Couteau suisse d'une PME

    Informations forums :
    Inscription : Octobre 2012
    Messages : 628
    Points : 1 256
    Points
    1 256
    Par défaut
    Tu ne devrais pas rester sur le premier message... ma réflexion a avancé depuis, j'ai trouvé une troisième solution, et je pensais l'avoir clarifié dans les messages suivant...

    Pour parler en terme de livrable, si j'ai un problème de css, je ne vais pas redeployer un webservice. Je vais redéployer un client. Je n'aurai même pas à redéployer les livrables qui fournissent les webcomponents puisque le css est entièrement gérer dans le front...

    En terme de livrable, et en ne gardant que ce qui correspond au js, j'ai :
    • une app "global", qui ne sait du backend que ce qu'elle en découvre.
    • Des services "fournisseurs de composants", qui ne connaissent qu'une chose, le nom d'un agrégateur.
    • Des agrégateurs, qui exposent un service par l'eventbus et qui savent quels services ils agrègent (ou du moins qui connaissent les noms des services à découvrir).
    • Des services qui font le "vrai" boulot, éventuellement en requérant d'autres services (genre le log, la bdd,...).


    Comme tu le vois, j'ai un workflow par service (sauf bien sûr si je fais une modif qui rompt la compatibilité d'une interface...). L'adhérence ne se fait que dans le backend, et je pourrai supprimer la partie js sans avoir à toucher au moindre livrable de service. Les deux premiers niveaux étant "dupliqué" par leur équivalent rest, tout redeviendrait un schéma microservices "classique".

    L'avantage, je trouve, c'est que l'adhérence de l'app au reste est minime : si je dois modifier le js pour l'une des features, je peux simplement le service de second niveau. Si je dois modifier le template de page (css, js, html...), je modifie le premier niveau. En revanche, si je rajoute dix services, que j'exposent par une interface qui agrège, je peux rajouter un service au deuxième niveau (ou pas) pour exposer le tout en js. Sans toucher à mon app, et donc sans redéploiements ou interférences avec le moindre workflow existant...

    Est-ce que ça reste selon toi une hérésie ? (n'oublions que ce sujet et là pour permettre d'améliorer une idée d'archi, je n'impose rien, ni n'essai de rentrer dans une case...)
    «Dieu ne joue pas aux dés.» - Albert Einstein. Et pan! 30 ans de retard dans la théorie quantique!
    «Tout n'est pas politique, mais la politique s'intéresse à tout.» - Nicolas Machiavel. Et surtout à ceux qui ne s'y intéressent pas.

  14. #14
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 608
    Points
    19 608
    Par défaut
    Citation Envoyé par Cafeinoman Voir le message
    Est-ce que ça reste selon toi une hérésie ? (n'oublions que ce sujet et là pour permettre d'améliorer une idée d'archi, je n'impose rien, ni n'essai de rentrer dans une case...)
    Je n'ai rien compris. Ton front est déployé via ... des webservices ???
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  15. #15
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    Citation Envoyé par Cafeinoman Voir le message
    Pour parler en terme de livrable, si j'ai un problème de css, je ne vais pas redeployer un webservice. Je vais redéployer un client.
    Un client... de quoi ? Dans un monde de microservices, tout est client et beaucoup de choses sont des serveurs.

    Citation Envoyé par Cafeinoman Voir le message
    Les deux premiers niveaux étant "dupliqué" par leur équivalent rest, tout redeviendrait un schéma microservices "classique".
    Qu'entends-tu par "dupliqué par leur équivalent REST" ? En quoi c'est un schéma microservices classique ?

    Citation Envoyé par Cafeinoman Voir le message
    En revanche, si je rajoute dix services, que j'exposent par une interface qui agrège, je peux rajouter un service au deuxième niveau (ou pas) pour exposer le tout en js. Sans toucher à mon app, et donc sans redéploiements ou interférences avec le moindre workflow existant...
    Je vois pas l'intérêt d'exposer un truc en JS si tu ne le consommes pas dans un UI derrière. Du coup, il faut quand même modifier l'UI (premier niveau d'après ce que j'ai compris), non ? Ou alors on est revenu à ta solution de départ, une UI qui auto-découvre ce qu'elle doit afficher ?

    Citation Envoyé par Cafeinoman Voir le message
    Est-ce que ça reste selon toi une hérésie ?
    Pas une hérésie mais on peut se demander si ce n'est pas inutilement compliqué.

    Une page web n'est-elle pas déjà ton premier niveau, à savoir une app "global", qui ne sait du backend que ce qu'elle en découvre ? Après tout, il suffit de cliquer sur "refresh" dans ton navigateur ou de mettre un auto refresh et tu l'as, ton UI qui découvre toute seule ce qu'il faut afficher...

  16. #16
    Membre éprouvé
    Avatar de Cafeinoman
    Homme Profil pro
    Couteau suisse d'une PME
    Inscrit en
    Octobre 2012
    Messages
    628
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Couteau suisse d'une PME

    Informations forums :
    Inscription : Octobre 2012
    Messages : 628
    Points : 1 256
    Points
    1 256
    Par défaut
    @Marco46

    Non... mon front est une app js. Tu peux la deployer avec node, un serveur statique, ce que tu veux. En l'occurence, elle est déployée dans un container docker, servie par un server http basé sur vertx (framework java), et sécurisé par keycloak. L'app en elle même est construite autour de Polymer, et donc des web components.

    @Luckyluke34

    Alors :

    Pour la duplication en rest, j'entends par la que les container docker qui serve de front (une app js, un service rest) sont exposé depuis l'extérieur sur la même ip. L'app sur le 80, le rest sur le 8080. Et que les agregateurs de services expose (généralement) un service rest consomé par le front.
    Par classique, j'entends le schéma qu'on voit le plus souvent dans les cours/tuto/autres trucs qui expliquent : des services exposer a l'exterieur par une gateway.
    Et pour ce qui est de la consommation du js, oui. L'app js qui est déployée consomme les web components de manière dynamique, c'est tout l'intérêt de ceux ci.

    Par contre, je ne comprend pas ta remarque sur le refresh... si je fais un refresh sans avoir modifier le code servis par le serveur, je ne vois pas comment elle peut avoir découvert quoi que ce soit?
    «Dieu ne joue pas aux dés.» - Albert Einstein. Et pan! 30 ans de retard dans la théorie quantique!
    «Tout n'est pas politique, mais la politique s'intéresse à tout.» - Nicolas Machiavel. Et surtout à ceux qui ne s'y intéressent pas.

  17. #17
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    Citation Envoyé par Cafeinoman Voir le message
    Par contre, je ne comprend pas ta remarque sur le refresh... si je fais un refresh sans avoir modifier le code servis par le serveur, je ne vois pas comment elle peut avoir découvert quoi que ce soit?
    Tout à fait, mais bon j'ai jamais dit le contraire hein

    Je reste persuadé que ta (deuxième) solution est trop compliquée, à moins que tu nous démontres quel besoin métier ou organisationnel cette complexité sert dans ton contexte métier. Parce que là, on parle quand même un peu dans le vide.

    Par ailleurs, on a probablement des représentations mentales très différentes de ce que sont les microservices. Pour moi (et, je crois deviner, Marco46 aussi), le concept de microservice n'exige rien de l'ordre de Docker, d'une gateway, d'apps JS ou même de REST ou HTTP (même si ça... reste, haha, le protocole de communication ultra répandu des microservices). Les microservices, c'est juste un type de service qui satisfont des caractéristiques :

    Componentization via Services
    Organized around Business Capabilities
    Products not Projects
    Smart endpoints and dumb pipes
    Decentralized Governance
    Decentralized Data Management
    Infrastructure Automation
    Design for failure
    Evolutionary Design

  18. #18
    Membre éprouvé
    Avatar de Cafeinoman
    Homme Profil pro
    Couteau suisse d'une PME
    Inscrit en
    Octobre 2012
    Messages
    628
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Couteau suisse d'une PME

    Informations forums :
    Inscription : Octobre 2012
    Messages : 628
    Points : 1 256
    Points
    1 256
    Par défaut
    En soit, c'est effectivement une complexité inutile dans le cadre de mon boulot... c'est uniquement dans le cadre d'un side-project comme on dit. La réflexion vient plutôt d'un constat : les microservices (et on entends bien la même chose par là) apportent par leurs caractéristiques une vrai fluidité à la fois dans le process de développement et dans le déploiement / maintien en prod.

    En revanche, dans l'application concrète de l'architecture, on a toujours un goulot d'étranglement : l'interface avec l'utilisateur final. On peut certe dire que ce n'est pas le problème des services de savoir comment elle est faite, mais dans la réalité il faut s'en préoccuper.

    Dans les fait, on voit deux patterns utilisés en production : la gateway rest et l'application js.
    Le premier n'est pas réellement un client pour moi, aucun utilisateur lambda ne l'utilisera. En revanche, il répond parfaitement aux critères que tu as cité, et peut donc être considéré comme un service en soit.
    Le second s'adapte parfaitement aux utilisateurs. En revanche, il ne répond pas du tout aux critères des microservices : c'est clairement une app monolithique qui utiliseun backend de microservices. On se retrouve donc à développer et maintenir et un monolithe et des microservices...

    L'idée est donc de réfléchir à un moyen de déployer un "client" javascript qui répondent aux critères (et donc dynamique) tout en restant user-friendly.

    Je vous ai exposé la solution que j'ai trouvé. Il semble d'ailleurs qu'il y est des choses plus simple en se basant sur le templating et la decouverte de services côté client.

    Ce que j'aimerai avoir maintenant surtout, c'est votre façon de faire à vous, en prod, concrètement... vous contentez d'exposer du rest? Faite vous un client js monolithique?
    «Dieu ne joue pas aux dés.» - Albert Einstein. Et pan! 30 ans de retard dans la théorie quantique!
    «Tout n'est pas politique, mais la politique s'intéresse à tout.» - Nicolas Machiavel. Et surtout à ceux qui ne s'y intéressent pas.

  19. #19
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    Ben, chez nous, on a juste des microservices qui exposent des API REST et sont appelés par des back-end d'applications monolithiques. Des fois, aussi, les microservices envoient des messages sur un bus pour faire savoir au monde que des trucs se sont passés.

    Donc ça ne rentre dans aucun de tes deux schémas, et je peux t'assurer qu'il y a multitude de situations comme ça en prod. A commencer par les SI à la mode SOA qui est un surensemble des micro-services.

    En revanche, il ne répond pas du tout aux critères des microservices : c'est clairement une app monolithique qui utiliseun backend de microservices.
    On n'a jamais dit qu'un système d'information devait être entièrement composé de microservices hein... Ce n'est pas le SI qui doit "répondre aux critères des microservices", c'est... les microservices

  20. #20
    Membre éprouvé
    Avatar de Cafeinoman
    Homme Profil pro
    Couteau suisse d'une PME
    Inscrit en
    Octobre 2012
    Messages
    628
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Couteau suisse d'une PME

    Informations forums :
    Inscription : Octobre 2012
    Messages : 628
    Points : 1 256
    Points
    1 256
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    Ben, chez nous, on a juste des microservices qui exposent des API REST et sont appelés par des back-end d'applications monolithiques. Des fois, aussi, les microservices envoient des messages sur un bus pour faire savoir au monde que des trucs se sont passés.
    Justement, ce qui m'embête un peu, c'est que je ne vois pas l'intérêt d'une architecture microsercices dans ce cas... certe, certains services sont sans doute mutualisés, mais c'est le genre de chose qu'on fait depuis longtemps. En soit, tu peu le faire avec une série de war sur des tomcats ou des wildfly, mais on est plus vraiment sur du décentralisé et automatisé...

    On n'a jamais dit qu'un système d'information devait être entièrement composé de microservices hein... Ce n'est pas le SI qui doit "répondre aux critères des microservices", c'est... les microservices
    On est bien d'accord ! C'est simplement que, à mon humble avis, plus il y a de monolithes dans le SI, et plus l'utilisation de microservices perd de son intérêt. Et là pour le coup, c'est du contexte de boulot : je suis tout seul à maintenir 4 monolithes et 1 site, en plus de l'admin réseau et de l'entretien du parc. Très sincèrement, je pense que du 100% microservice serait mieux maintenable et plus simple à faire évoluer...
    «Dieu ne joue pas aux dés.» - Albert Einstein. Et pan! 30 ans de retard dans la théorie quantique!
    «Tout n'est pas politique, mais la politique s'intéresse à tout.» - Nicolas Machiavel. Et surtout à ceux qui ne s'y intéressent pas.

Discussions similaires

  1. Un client WCF dynamique (2 web services) ?
    Par MaximeLeroy dans le forum Windows Presentation Foundation
    Réponses: 1
    Dernier message: 23/07/2013, 17h53
  2. creation de page web dynamique
    Par noussaENSI dans le forum Autres langages pour le Web
    Réponses: 2
    Dernier message: 15/12/2005, 14h20
  3. [client Web riche] Quelles technologies prendre?
    Par you98 dans le forum Struts 1
    Réponses: 2
    Dernier message: 14/12/2005, 21h48
  4. [Architecture/strategie] conception de site web dynamique
    Par epoz dans le forum Général Conception Web
    Réponses: 3
    Dernier message: 28/11/2005, 13h11
  5. Client Web Service
    Par caro. dans le forum Services Web
    Réponses: 3
    Dernier message: 08/04/2005, 17h14

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo