BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités L'utilisation compte plus que la Taille

L'utilisation compte plus que la Taille

Favoris

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.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT