ego
[Actualité] Approche services et applications…incompatible ?
par , 10/01/2015 à 14h06 (2039 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 !!!
Consulter le profil
Marquer ce blog comme lu
