BT
x Votre opinion compte ! Merci de bien vouloir répondre au sondage InfoQ concernant vos habitudes de lecture !

L'utilisation compte plus que la Taille

par Jan Stenberg , traduit par Nicolas Frankel le 30 mai 2014 |

L'utilisation de la taille pour la définition des microservices est une métrique inadaptée et inutile pour déterminer si un service possède les bonnes responsabilités, dit Jeppe Cramon dans une série de billets de blog qui clarifient sa vision sur les microservices et les problématiques de couplage qu'il trouve dans la communication synchrone bidirectionnelle.

Jeppe, un contractant danois et expert en intégration de systèmes de grande taille et SOA, argumente que si l'on combine des microservices de petite taille avec de la communication synchrone, alors nous sommes de retour dans les années 90 avec Corba, J2EE et les objets distribués, seulement cette fois avec des technologies comme HTTP à la place de RMI ou IIOP. Les microservices utilisent HTTP, JSON et REST mais ne font pas disparaître les désavantages liés à la communication distante, comme indiqués dans les 8 erreurs de l'informatique distribuée.

Pour créer une alternative à cette communication synchrone, Jeppe se base entre autres sur Pat Helland et son ouvrage La Vie au-delà des Transactions Distribuées : l'Opinion d'un Apostat où l'auteur développe ses arguments contre les transactions distribuées. La solution de Jeppe est en 3 points :

  1. L'allocation de données aux services
  2. L'identification des données
  3. La communication entre les services

Jeppe solutionne les deux premiers points par l'utilisation des concepts de la Conception Pilotée par le Domaine avec les données collectées dans les entités et les aggrégats où chaque aggrégat est identifiable de manière unique p.e. en utilisant un UUID et alloué à un service. Ces aggrégats doivent être consistants après la transaction, une règle empirique étant : 1 cas d'utilisation = 1 transaction = 1 aggrégat.

La communication entre les services est résolue par la communication asynchrone, et plus spécifiquement par une vraie communication unidirectionnelle avec la transmission du message par l'émetteur à travers un canal de transport p.e. une queue de messages. L'émetteur n'attend pas que le message soit reçu ; au lieu de cela, le canal de transport assume la responsabilité pour la réception et la délivrance des messages au destinataire.

L'ambition de Jeppe est de continuer avec un billet de blog qui chercherait des moyens de diviser les services en services plus petits et la manière dont ils pourraient communiquer en utilisant une communication unidirectionnelle asynchrone.

L'Architecture Microservice a émergé durant les dernières années comme un concept pour décrire une manière pour concevoir des applications logicielles comme une suite de services déployables de façon autonome et indépendante qui coopèrent pour offrir des fonctionnalités métier. Une conférence est prévue fin novembre à Londres.

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter

Contenu Éducatif

Rien ne serait possible sans le soutien et la confiance de nos Sponsors Fondateurs:

AppDynamics   CloudBees   Microsoft   Zenika
Feedback Général
Bugs
Publicité
Éditorial
InfoQ.com et tous les contenus sont copyright © 2006-2014 C4Media Inc. InfoQ.com est hébergé chez Contegix, le meilleur ISP avec lequel nous ayons travaillé.
Politique de confidentialité
BT