tag:blogger.com,1999:blog-21628438.post2013976245319993042..comments2024-03-27T08:21:58.680+01:00Comments on new Blog( perso );: Small is beautifulNicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-21628438.post-52868263924341452362014-05-05T15:27:04.358+02:002014-05-05T15:27:04.358+02:00Merci pour ton commentaire détaillé et constructif...Merci pour ton commentaire détaillé et constructif.<br /><br />http est la façon simple de faire, mais du Thrift/ProtoBuf permet de faire plus efficace si nécessaire. <br /><br />La duplication des données doit être vue comme un avantage : le tout est de définir le référent. Pouvoir enrichir/retravailler le modèle métier selon son point de vue local plutôt que de définir un modèle qui convienne à tous est nettement plus facile.<br /><br />Sur l'aspect versioning, on peut soit exposer plusieurs version de l'API (c'est sans doute ce que tu suggère) soit avoir N versions du service qui tournent, N-1 en lecture seule, ou encore un proxy N => N+1<br /><br />sur les aspects transverse, attention à ne pas confondre les éléments applicatifs (logging, configuration, securité) et les limites du langage (stringutils). Le dernier nécessite en effet des librairies et frameworks qui sont fait pour ça. Micro-service ne veut pas dire application de quelques Ko. <br /><br />Et pour ces solutions transverses il existe en général des solutions toutes faites. Pour la gestion du logging par exemple, que tu considère "potentiellement lourd", utilise le syslog et les outils qui vont avec et/ou couple ça avec un service comme PaperTrail et basta. L'invraisemblable complexité du logging en Java vient de l'incapacité à comprendre la problématique du Logging, pour se focaliser sur l'API développeur (problème assez typique en java)<br /><br />La gestion des échecs de communication est un vrai soucis, et clairement il faut du monitoring. Par contre c'est plus facile d'identifier quel brique par en c.. et de cerner le problème, qu'une grosse appli qui fait un OOME.<br /><br />Quand à ta conclusion, je plussois dans ton sens. Les micro-services apportent une réponse qui ne correspond pas à tous les besoins, par contre ils contribuent à poser la question "mais pourquoi on fait comme ça au fait" qui manque souvent.<br /><br />Quand à l'entremêlement des domaines, jusqu'ici ce que j'ai vu sur de grosses application c'est qu'on a couplé des données parce que cela a été modélisé comme ça, mais ce n'est en aucun cas une nécessité.<br /><br />Encore merci pour ton retourNicolas De Loofhttps://www.blogger.com/profile/01689687514370945173noreply@blogger.comtag:blogger.com,1999:blog-21628438.post-4847811892776414502014-05-05T14:45:26.718+02:002014-05-05T14:45:26.718+02:00Salut !
D'accord dans l'ensemble, cependan...Salut !<br />D'accord dans l'ensemble, cependant il faut considérer les bémols suivants :<br />- si un module est responsable d'une notion métier utilisée par un autre module, il peut y avoir un couplage fort entre 2 modules qui annule les bénéfices de la modularité (quand bien même elle serait micro)<br />- une notion partagée par plusieurs modules qui évolue va nécessiter une évolution synchrone de ces modules qui, communiquant à travers un idiome différent du langage de base (http plutôt que java), ne pourra bénéficier des outils de refactoring<br />- passer par du http, même minimaliste, peut engendrer -lorsque la pile des appels http grossit- une réduction non négligeable des performances. Cet aspect peut emmener à son tour l'émergence de librairies de cache côté client avec toute la galère que ça entraîne.<br />- l'émergence de mécanismes pub-sub dûs aux cas ci-dessus. pub-sub over http n'est pas forcément adapté au besoin (encore une fois, ça dépend des cas, de la perf requise, ...)<br />- la duplication des données lorsque qu'un micro-service doit gérer du versionning des objets récupérés par des micro-services tiers (du fait d'une architecture event-driven par exemple).<br /><br />En conséquence, quand bien même j'adore cette approche, je pense qu'il faut identifier les cas qui s'y prêtent vraiment :<br />- authentification : oui : service central, one-shot, couplage faible, versionning d'API possible<br />- repository : oui et non : service central, mais pas du tout one-shot, couplage fort, mais API versionning possible<br />- stingutils / utils en général : je pense plutôt non (une lib est parfaite dans ce rôle)<br />- gestion des "constantes applicatives" : multilangue/encodage, stratégie de gestion de date/time/timezone, de logging, d'historisation : non pas du tout (une lib ou nano-framework maison est là aussi plus adaptée à mon goût). Pour toutes les problématiques transverses, je peine à imaginer comment elles pourraient s'intégrer dans cette logique.<br />- gestion du logging tout court : oui, même si c'est potentiellement lourd, c'est asynchrone à 100%<br /><br />Ensuite vient la dernière question : chaque micro-service doit-il accéder à ses comparses via son propre micro-client http ? via une librairie dédiée à l'accès à ce micro-service ? via des appels "en dur" pour peu que le framework http permette une exploitation relativement immédiate des valeurs de retour ?<br /><br />Attention également aux services où on "dump" ses données (comme du logging) : on peut rapidement se retrouver à avoir à gérer l'éventualité d'un micro-service défaillant... auquel cas c'est à l'appelant de s'assurer qu'il ne perd pas ses données... ce qui aboutit en général à la mise en place d'une file... qui se convertit en général à l'utilisation d'un bus central de communication inter-modules.<br /><br />En conclusion de la réflexion d'un coin de table que ton billet m'a inspirée, je dirais que c'est définitivement une approche à considérer, bien qu'en définitive, on en revienne au fameux "adapter l'architecture au besoin", ce qui fait -peut-être- qu'en 2014 on en soit toujours à se demander "mais quelle architecture est vraiment la meilleure ?", car elles sont toutes meilleures... mais dans leurs domaines respectifs, et ces domaines s'entremêlent souvent dans à peu près toutes les applications.<br /><br />Merci pour la "minute de rétrospective" ;)Socratehttps://www.blogger.com/profile/17869261910807784979noreply@blogger.com