Voir le flux RSS

ego

[Actualité] Approche services et applications…incompatible ?

Noter ce billet
par
ego
, 10/01/2015 à 15h06 (1391 Affichages)
Depuis toujours, euh enfin depuis que l’on fait des logiciels, on parle d’applications informatiques. Nos activités de conception et de développement mais aussi bien souvent nos organisations sont guidées par ce concept d’application. Il y a quelques années déjà est apparu le concept de SOA (Service Oriented Architecture) et toutes ses batteries de sous-concepts, middlewares et technologies d’échanges. Depuis peu la notion de micro-services est apparue avec ceci de particulier par rapport au SOA que l’on y aborde la notion de « taille » du service et d’unité de déploiement en production.
Pour simplifier, le SOA dit qu’il faut résonner par « services » offerts au sein d’un système d’information mais sans aborder la notion d’application, sans la remettre en cause en tout cas. Donc si vous avez une application, grosse ou petite, mais qu’elle offre clairement des « services » à son écosystème, et bien tout va bien, vous faites du SOA.
Avec l’approche micro-service, non seulement on met en avant les principes du SOA mais en plus on essaye de travailler sur la taille de ces services et sur la taille de l’unité de déploiement qui va contenir ces services. L’idée étant qu’en faisant des unités de déploiement les plus petites possible, les déploiements fréquents seront plus faciles. Vous serez plus « Agile » parce que « lancer des petits cailloux » c’est plus facile que « lancer un gros rocher ».

Bon, tout ça c’est bien gentil mais comme bien souvent en informatique, on lance des théories, au demeurant intéressantes pour faire avancer les idées, mais on sombre vite dans la technophilie. Car si vous avez suivi les débats sur le Web au sujet de ces approches SOA et micro-services, les discussions se raccrochent vite à des frameworks techniques et problématique de protocoles de communications et autres formats d’échange.
Or, le problème essentiel qui n’est toujours pas résolu, et qui probablement n’a pas de réponse absolue, peut être résumé comme suit :
  • Quelle est la bonne la taille des services ?
  • Quelle est la bonne taille d’un regroupement de services pour s’assurer d’une performance acceptable ?


Vous le savez sûrement, si on fait des services de taille très petite, on aura beaucoup de communication inter-services pour réaliser une tâche métier plus conséquente. Et qui dit pleins d’appels entre services dit problématique de performance. Si vos services sont dans des unités de déploiement distinctes, comme cela peut être préconisé par l’approche micro-services, vous aller vous retrouver en plus avec des communications inter-services non pas uniquement « en mémoire » mais via des interfaces « réseaux », via des protocoles sur HTTP par exemple et avec des problématiques de marshalling/unmarshalling en cascade.
Donc que l’on réfléchisse de manière théorique comme le propose SOA ou que l’on intègre en plus la notion de petites unités de déploiement en production comme l’ajoute l’approche micro-service, on voit bien que l’on ne peut pas rester sur une simple approche « service » et qu’il faut sérieusement penser au regroupement de ces services dans des unités de déploiement…pas trop petites non plus.

Eh bien vous savez quoi ? Cette unité de déploiement « pas trop petite » qui offre des services c’est notre bonne vieille application !
Donc retour à la case départ, une application offre des services, ça c’est acquis. Une application ne doit être ni trop grosse ni trop petite car sinon on a, soit des problèmes d’évolutivité, soit des problèmes de performance et de gestion de cohérence.

Et donc, quelle est la bonne taille d’une application ? Qu’est-ce qui pourrait nous aider à déterminer une taille « qui va bien » ?.

........le DDD bien sûr !!!

Envoyer le billet « Approche services et applications…incompatible ? » dans le blog Viadeo Envoyer le billet « Approche services et applications…incompatible ? » dans le blog Twitter Envoyer le billet « Approche services et applications…incompatible ? » dans le blog Google Envoyer le billet « Approche services et applications…incompatible ? » dans le blog Facebook Envoyer le billet « Approche services et applications…incompatible ? » dans le blog Digg Envoyer le billet « Approche services et applications…incompatible ? » dans le blog Delicious Envoyer le billet « Approche services et applications…incompatible ? » dans le blog MySpace Envoyer le billet « Approche services et applications…incompatible ? » dans le blog Yahoo

Catégories
Sans catégorie

Commentaires

  1. Avatar de kolodz
    • |
    • permalink
    Bonjour,

    Je me permet de faire quelques commentaires par rapport à ce que tu dis.

    Vous serez plus « Agile » parce que « lancer des petits cailloux » c’est plus facile que « lancer un gros rocher ».
    Il y a aussi une phrase que j'aime beaucoup :
    • Ce que vous trouvez dur, fait le souvent.

    On dit cela en général, pour les merges pour git, mais aussi pour les mises en productions.
    L'idée étant que la répétition de la tâche, la rends moins lourde.

    Si vos services sont dans des unités de déploiement distinctes, comme cela peut être préconisé par l’approche micro-services, vous aller vous retrouver en plus avec des communications inter-services non pas uniquement « en mémoire » mais via des interfaces « réseaux », via des protocoles sur HTTP par exemple et avec des problématiques de marshalling/unmarshalling en cascade.
    Pour le coup, il existe des outils qui gère cette partie comme ActiveMQ pour les JMS (Java Message Service). L'un des avantage principaux que j'y vois. C'est qu'un service non démarré aura l'ensemble des message qui lui sont destiné stocké par ActiveMQ et une fois le service "en service" celui-ci va dépiler les messages.
    Ce qui est relativement pratique pour avoir une continuité pour les autres applications.

    Eh bien vous savez quoi ? Cette unité de déploiement « pas trop petite » qui offre des services c’est notre bonne vieille application !
    Cela est plus dû à une volonté des personnes à tout regroupé dans une application "qui fait tout".
    A noter que cela n'est pas totalement idiot dans bien des cas. En général, cela permet de formaliser le métier pour l'ensemble des acteurs, qu'ils en ai la même approche. Ce qui est souvent le plus important.

    ........le DDD bien sûr !!!
    Le DDD n'est pas magique. Il est évident que le découpage des services va dépendre du métier. Cependant, savoir-faire un découpage à partir d'un métier reste encore un travail d'expert du métier. C'est savoir ce qui est lié et ce qui ne l'est pas. J'ai déjà vu des personnes ne connaissant pas le métier, faire une réunion "DDD" avec les experts métier et décider de l'architecture juste après. Ca fait avancé le projet, mais pas sûr qu'en quelques réunions ces personnes ai réellement saisit toutes les interactions entre chacune de ces parties. Ce qui peu amener à des usines à gaz, qui ne serai pas arriver en gérant un problème à la fois. Ce qu'on réalisait bien plus souvent avec "notre bonne vieille application".

    Cordialement,
    Patrick Kolodziejczyk.

    source :
    http://en.wikipedia.org/wiki/Java_Message_Service
    http://activemq.apache.org/jms.html
  2. Avatar de ego
    • |
    • permalink
    Merci pour ton retour.
    Bien sûr que l'on a des truc comme les esb ou autre mais he voulais mettre l'accent sur le "temps" que la communication da mettre. En mémoire ça reste toujours plus rapide.
  3. Avatar de Saverok
    • |
    • permalink
    Citation Envoyé par ego
    Merci pour ton retour.
    Bien sûr que l'on a des truc comme les esb ou autre mais he voulais mettre l'accent sur le "temps" que la communication da mettre. En mémoire ça reste toujours plus rapide.
    L'avantage d'un activeMQ c'est qu'il est très léger et on peut donc avoir 1 activeMQ en local par service.
    Alors qu'un ESB est souvent plus lourd et est placé sur une machine dédié ce qui fait qu'on ajoute une couche de protocole réseau qui alourdi les communications entre service.
  4. Avatar de bruneltouopi
    • |
    • permalink
    L'approche SOA ou par micro service franchement dépend du contexte de l'application.
    En plus il y'a des problématiques et des types de solutions qui imposerait de travailler avec l'un ou l'autre.
    Donc chacun a des avantages et inconvénients.Le tout est de savoir si on répond à 90% au besoin du client,si le coût de maintenance ou de refractoring n'a pas un très gros impact,si bien on contrôle mieux les procédures de déploiements.
  5. Avatar de ego
    • |
    • permalink
    Citation Envoyé par bruneltouopi
    L'approche SOA ou par micro service franchement dépend du contexte de l'application.
    En plus il y'a des problématiques et des types de solutions qui imposerait de travailler avec l'un ou l'autre.
    Donc chacun a des avantages et inconvénients.Le tout est de savoir si on répond à 90% au besoin du client,si le coût de maintenance ou de refractoring n'a pas un très gros impact,si bien on contrôle mieux les procédures de déploiements.
    Comme je l'ai dit, le réel problème reste à ce jour la performance et la cohésion. Des choix de ce type d'approche se font quand même de manière globale dans un SI.
    A trop découper on découpe mal et la gestion des petits "bouts" devient un cauchemar, engendre des problèmes de performance et de gestion de cohérence. Car on en vient à dupliquer l'information dans les différents "bouts" (composants).

    Il faut donc trouver un moyen pour faire des composants ni trop petits ni trop gros.