urbanisation-si.com

Obeo Information System Designer (ISD) offre aux architectes logiciel la possibilité de maîtriser leur architecture micro-services (composants, services, interfaces, flux, infrastructure, interdépendances...). Cet outil, interopérable avec SmartEA du même éditeur, permettra de s'assurer que les spécifications techniques sont correctement comprises et que les développements sont conformes à l'architecture d'entreprise. 

Le diagramme SOA (Service Oriented Architecture) montre une chorégraphie de composants,
par exemple les micro-services (DossierSinistre, Assure et Contrat), les services fournis (Provided interface en vert) et ceux qui les utilisent (Required interface en violet). Les liens orientés du consommateur vers le fournisseur illustrent les appels des services entre les micro-services.

A lire > Orchestration des micro-services avec BPMN

Que dit la bible TOGAF de l’Open Group
à propos de l’architecture micro-services ?

Extrait du TOGAF® Series Guide Microservices Architecture (MSA) montrant les interfaces où les entrées et les sorties du micro-service sont échangées avec d'autres couches architecturales qui doivent être identifiées. La gouvernance et la conduite du changement sont héritées de l'Architecture d'Entreprise globale.

Le guide TOGAF Series sur l’architecture des micro-services (MSA) publié par The Open Group fournit une définition complète de la MSA et présente la portée de l’architecture d’entreprise comme englobant toutes les activités et capacités commerciales de l’entreprise, les informations et la technologie qui composent l’ensemble de l’infrastructure et de la gouvernance de l’entreprise.

L’architecture des micro-services (MSA) est un style d’architecture dans lequel les systèmes ou applications logicielles sont composés d’un ou plusieurs services indépendants et autonomes. Ce n’est pas un produit, un cadre ou une plateforme. C’est une stratégie pour construire de grands systèmes distribués. Les micro-services sont faiblement couplés et déployés indépendamment les uns des autres.

A lire >

• Notre dossier complet : Architecture Micro-Services et Micro-Services études de cas
   
• Une définition pédagogique et les avantages des micro-services : L’Architecture Micro-Services expliquée à ma fille
   
• Leurs inconvénients : Inconvénients de l'Architecture Micro-Services
   
• La démonstration qu’une architecture micro-services est beaucoup plus simple qu’une architecture monolithique : Estimation de la complexité d’une Architecture Micro-Services

Résumé des épisodes précédents

Ça y est, l’analyse de votre application est bien avancée dans ISD, il est temps pour les architectes logiciel de passer à la modélisation de l’architecture micro-services (MSA).

ISD est un environnement open source, low code et NoUML pour l’analyse, la conception et la génération de code d’applications s’interfaçant avec l’outil d’Architecture d’Entreprise SmartEA du même éditeur. Jusqu’ici, nous avons vu des équivalents des cartographies métier, fonctionnelle, applicative avec la cinématique et les représentations des écrans.

Avec ISD, les acteurs, qu’ils soient business analyst, product owner, concepteur, développeur, testeur... embarquent dans un train et se laissent conduire. Chacun apporte sa pierre à l’édifice : le product owner conçoit les user stories, le testeur crée les exigences et les cas de tests à partir des cas d'utilisation, le concepteur modélise les interactions utilisateur et le business analyst les cas d'utilisation, le modèle conceptuel de données et les transitions d’état des entités métier.

Pour l'aspect dynamique du système, la démarche permet de modéliser les rôles des acteurs, puis les cas d'utilisation. Leur granularité étant toujours problématique, l'utilisateur sera aidé en ayant la possibilité de les décomposer suivant 2 niveaux de détails :

1. les scénarios (Tasks Graph),
    
2. les étapes (Actions Plan) d’un scénario.
    

Pour ceux qui le désirent, il est possible d'ajouter des diagrammes de séquence et d'états.

L'aspect statique se compose de diagrammes semblables à UML, mais expurgés des éléments rarement utilisés :

1. les domaines métier (Namespaces), équivalent du diagramme de package UML avec la complexité des relations en moins,
    
2. les entités métier et leurs relations (Domain Classes), correspondant à un diagramme de classes UML pragmatique.

Comme le montre notre étude de cas avec les matrices de traçabilité des exigences avec les use case, les tâches, les cinématiques et les maquettes des écrans, les liens sont bien tissés entre les besoins utilisateurs et les spécifications de l’application. Lors de changements, le contrôle de cohérence entre tous ces éléments et les études d’impact en seront grandement facilitées, principe cher aux méthodes agiles.

En couplant ISD avec l’outil SmartEA, vous obtiendrez des cartographies allant jusqu’à une granularité très fine et augmenterez le degré d’agilité de votre architecture d’entreprise.

A lire >

1. Alimenter le référentiel d’Architecture d’Entreprise pour la couche Application de TOGAF avec l’outil Information System Designer (ISD) d’Obeo - Modélisation de l’analyse des besoins S.1 Ep.1
    
2. Méthode Graal, le NoUML d’Obeo, parfaite fusion entre un UML phagocyté et un BPMN édulcoré. S.1 Ep.2
    
3. Comment assurer la traçabilité des exigences avec les user stories, les use cases, les processus métier, la cinématique et les maquettes d'écrans ? Une solution dans notre test Obeo ISD S.1 Ep.3

Comment réaliser la modélisation
d'une architecture micro-services

Orientée NoOMG

ISD permet, par l’intermédiaire de son SOA Designer, de modéliser la communication entre les composants d’une application. Cet outil cartographie leurs liens réalisés par des interfaces de services fournies ou requises. Tout y est : la définition des opérations que vos services peuvent effectuer avec leurs entrées/sorties et la gestion des exceptions.

Les protocoles standards SOAP (qui n'est plus un acronyme depuis la version 1.2) et REST (REpresentational State Transfer) sont supportés. La documentation technique ne fait pas état de GraphQL (Graph Query Language). Dommage, car ce langage offre de nombreux avantages par rapport à REST.

L’importation de services REST existants en format OpenAPI (Swagger) est supportée, ce qui rend possible la rétromodélisation. L’export au même format permet de générer la documentation.

Enfin, les données échangées DTO (Data Transfer Object) peuvent être modélisées en NoUML, à partir des entités persistantes (Entities). Dommage qu'ils ne peuvent l'être à partir des classes du domaine (classes métier) définies dans le modèle utilisant la méthode Graal, vue dans nos précédents articles.

Ici, pas de norme ésotérique ou rarement utilisée comme SoaML de l’OMG (Object Management Group), que du pragmatique, on pourrait dire du NoOMG.

Créer un SOA Model

File > New > Other > IS Designer > SOA Model

Après avoir vu Graal Model, Interaction Model, State Machine Model,
Requirement Model, Cinematic Model, examinons le SOA Model.

Les vues DTO Namespaces Hierarchy et SOA Diagram sont ouvertes afin de commencer la modélisation.

Commencer par les DTO (Data Transfert Object)

DTO, JSON, XML/XSD, REST, SOAP

Le pattern DTO d’architecture distribuée consiste à ne considérer que les données échangées et utiles pour le consommateur du service. L’architecte applicatif doit les sélectionner parmi les attributs des classes persistantes (Entities). En effet, transmettre des données non pertinentes pour l’utilisateur encombrerait la bande passante réseau pour rien et présenterait un risque potentiel de sécurité.

Une structure commune entre le fournisseur et le consommateur du service devra être choisie comme JSON (JavaScript Object Notation) pour les micro-services ou XML/XSD (eXtended Markup Language/Xml Schema Definition) pour les Web Services.

Un socle technologique implémentant un protocole commun de transport entre les 2 protagonistes devra être mis en œuvre comme REST (REpresentational State Transfer) pour les micro-services ou SOAP (qui n’est plus un acronyme dans sa nouvelle version) pour les Web Services.

Pour les opérations des interfaces du SOA Diagram, on aura besoin des structures des données échangées. Vous devez donc modéliser vos DTO.

Créer des namespaces pour organiser vos DTO

• Sélectionnez le SOA Model > cliquez sur la vue DTO Namespaces Hierarchy > créer un nouveau namespace de base à partir de la palette et éventuellement des sous-namespaces 

Création du namespace représentant le système de prévoyance contenant 3 sous-systèmes :
prestation, personne et contrat.

Modéliser vos données échangées en entrée/sortie en créant un diagramme DTO

Un diagramme DTO est un diagramme de classes UML simplifié où les classes seraient stéréotypées DTO. Certaines subtilités sont supprimées, comme les agrégations, les implémentations d’interface, les dépendances et évidemment les méthodes. Les DTO ne contiennent que des données, les opérations seront décrites dans les services des composants.

• Sélectionnez le namespace > double-cliquez pour ouvrir un diagramme ou clic droit > New > New DTO Diagram

Vu d'avion, ce diagramme a tout d'un diagramme de classe UML. À y regarder de plus près, pas d'affectation de méthodes dans les classes, pas de relation d'agrégation, de réalisation, de dépendance, pas d'interface, pas de classe abstraite, pas de classe paramétrée... :
on dirait bien du NoUML.

Certains choix peuvent dérouter quelque peu les experts UML, comme le fait qu’une relation de composition soit identifiée par un losange blanc du côté du composite, alors qu’en UML il est noir. Le losange blanc signifie un agrégat dans une relation d’agrégation UML.

Toujours quelques regrets sur l’ergonomie. Par exemple, pour les valeurs d’une énumération, on aurait aimé une saisie globale, plutôt que de ressortir chaque fois, de sélectionner le +, puis de saisir la nouvelle valeur.

La palette vous propose une fonctionnalité alléchante, qui est de créer des DTO à partir d'entités “DTO from Entity”. A noter qu’à l’inverse, il est possible de créer des entités à partir des DTO.

Dans ISD, les Entities correspondent aux classes persistantes gérées par un ORM (Object Relational Mapping) offrant la dualité objet/relationnel SQL. Notre prochain article sur ISD abordera la génération de code et plus particulièrement les Entities, les MLD (Modèle Logique de Données), les MPD (Modèle Physique de Données), la génération et l’exécution de script SQL.

S’il est possible de créer des DTO à partir des entités persistantes (Entities), il est par contre impossible de le faire à partir des classes participantes (Domain Classes), identifiées lors de l’étape d’analyse de la méthode Graal. L’outil SOA Designer semble complètement ignorer les éléments identifiés dans le module Graal. Dommage, car on pourrait aussi concevoir les DTO à partir des classes du domaine métier et pas seulement des classes persistantes.

Un autre inconvénient est que la traçabilité des classes du domaine n’est pas assurée vers les classes persistantes. Pourquoi ce choix ? Ce ne peut être une limitation technique, car par exemple, le SOA Designer accède bien au modèle d’exigences (Requirement Model) pour la traçabilité avec les composants, services et opérations.

Doit-on en conclure qu’il n’y a pas véritablement de référentiel transverse à tous les modules ? 

Cartographier les services (SOA Diagram)

L’objectif est de représenter les composants, leurs liens de communication par l’intermédiaire des interfaces fournies et requises, composées d’opérations avec leurs données en entrée/sorties et leurs traitements exceptionnels (fault).
 
On commence par une vue globale : il s’agit d’un diagramme de composants UML simplifié, où Obeo a gardé les concepts d’interfaces fournies et requises, ainsi que leurs liens, en modifiant leur représentation.

• Dans SOA Model > Components > double-cliquez sur SOA Diagram

Le composant applicatif DossierSinistre doit utiliser (Required interface) les services
du composant Assure et Contrat pour fournir les services qui gèrent la survenance et le dossier.
Notez le niveau de sécurité, ici OAuth 2.0 (Open Authorization).

Le picto clé jaune indique que le composant DossierSinistre est lié à des exigences à visualiser dans l’onglet Linked Requirements et l’autre à droite signifie qu’en double-cliquant sur le composant, on accède au diagramme Component Contract détaillant les opérations.

Contractualiser les opérations d’un service
et les traitements exceptionnels 

Une fois un composant créé avec les interfaces qu’il fournit (Provided) et celles qu’il utilise (Required), on va détailler leurs opérations avec leurs paramètres d'entrée/sorties et les exceptions (Fault) dans un nouveau diagramme.

• Double-cliquez sur le composant, ISD crée automatiquement un nouveau diagramme. On peut aussi passer par le menu contextuel sur le composant : clic droit > New Representation > Component Contract

Le service (Provided Interface) SurvenanceService possède 2 opérations : listerHistoriqueSurvenances avec le picto vert S pour SOAP et le picto paginé. Les paramètres en entrée sont indiqués par une icône bleue, en sortie par une icône verte et les messages d'erreurs en rouge.
L'autre opération possède un picto R pour REST.

Les interfaces apparaissent et, dans la palette, il suffit de faire des drag and drop pour les opérations avec leurs entrées/sorties et les exceptions.

Configurer une opération

Si le nombre d’occurrences retourné par une opération est trop important, vous pouvez décider de paginer le résultat :

• Sélectionnez une opération > onglet Properties > onglet Operation > cochez Paged
  Si ce nombre dépasse la limite métier maximale stipulée dans une exigence, alors vous pouvez renvoyer un message d’erreur (Fault). 

Pour choisir le protocole d'échange :

• Sélectionnez une opération > onglet Properties > onglet Operation > Exposition > choisir entre REST (picto roue verte R), SOAP (picto roue verte S) et NONE (roue grise pour les services internes).

Vous pouvez tout configurer. Par exemple, si vous avez sélectionné REST, l’onglet “Exposition” des propriétés permet de choisir l’URI (Uniform Resource Identifier) et les méthodes HTTP disponibles qui sont GET, POST, PUT, DELETE, HEAD, OPTIONS, PATCH et TRACE.

Pour configurer les données en entrée et en sortie :

• En cliquant sur un paramètre d’une opération, on a le détail et notamment le type, comme ContratDTO, en cliquant sur les 3 points horizontaux,
   
  
• Dans Exposition, on trouve aussi le détail des paramètres entrants, qui peuvent être transmis en : BODY, PATH, QUERY, COOKIE et HEADER et leurs noms Swagger pour la documentation et les tests unitaires,
   
• Pour les paramètres en sortie, on peut choisir un code HTML normalisé (200 : OK, 201 : Created…).

La sécurité n’est pas en reste avec l’API REST 

Les schémas de sécurité peuvent être mis au niveau du service ou d’une opération.

Sécurité d'un composant

Il faut d’abord définir les schémas de sécurité.

• Cliquez dans le diagramme Component Contract > Properties > Security Schemes > clic sur le picto + > vous pouvez alors sélectionner le type de sécurité : API_KEY ; HTTP ; OAUTH2 ; OPEN_ID_CONNECT. Il est possible d’en cumuler.

Création d'un système d'authentification et d'autorisation OAUTH2 (Open AUTHorization)
et par token JWT (JSON Web Token) pour le micro-service DossierSinistre.

Sécurité d’une opération ou d’un service

• Dans le diagramme Component Contract sélectionner une opération ou un service (toutes ses opérations seront sécurisées) > Properties > Security > + > sélectionner parmi les schémas de sécurité > Add

Ici, la sécurité est configurée sur l'opération creerSurvenance.

Une clé rouge indiquera que l’opération est sécurisée.

Traçabilité des exigences
avec les composants et leurs opérations

Contrairement aux DTO qu’on ne peut pas lier aux entités métier définies à l’extérieur du modèle SOA, vous avez la possibilité de lier vos services à des exigences définies dans le modèle Requirement Model. Les générateurs de code en tiendront compte.

• Sélectionner le composant (micro-service), un service (interface du composant) ou une opération de l’interface dans le diagramme Component Contract > onglet Linked Requirements > picto jaune Link Requirements with Selection > sélectionner des exigences dans la fenêtre Link Requirements.

Une clé jaune apparaîtra alors sur l’opération.

La clé jaune en bas du service SurvenanceService indique qu'il est lié à des exigences du Requirement Model. Pour les visualiser, il suffit de sélectionner le service et l'onglet Linked Requirements. 

Sur le conteneur, une clé grise apparaît lorsque toutes les opérations ne sont pas liées à des exigences, sinon une clé jaune sera visible. Ici, seule l'opération creerSurvenance est liée à des exigences.

A lire >

• Comment assurer la traçabilité des exigences avec les user stories, les use cases, les processus métier, la cinématique et les maquettes d'écrans ? Une solution dans notre test Obeo ISD S.1 Ep.3

Conclusion

Que ce soit une architecture micro-services ou Web Services, vous pourrez la modéliser simplement avec ISD qui, une fois de plus, a laissé de côté la complexité des normes comme UML pour laisser la place à l’efficience et au pragmatisme. 

En tant qu’architecte logiciel, vous y trouverez votre compte en créant des cartographies représentant les composants applicatifs, avec leurs échanges basés sur un système d’interfaces fournies et requises, indépendamment de leur implémentation technique. Vous pourrez documenter toutes les spécifications, comme le protocole de transfert, REST ou SOAP, le format d’échanges de données, JSON ou XML, les DTO, les opérations avec leurs paramètres d’entrée/sortie, les traitements exceptionnels, les politiques de sécurité, sans oublier la traçabilité avec les exigences.

Réaliser la modélisation détaillée des composants de votre architecture micro-services permet d’étudier précisément les impacts que des changements auraient sur le reste du système. Ensuite, il vous faudra prendre de la hauteur et la décrire de manière globale, afin de l'intégrer dans le SI et alimenter votre patrimoine existant. En effet, une fois cette modélisation finalisée avec ISD, vous pourrez l'importer dans SmartEA, l’outil d’architecture d’entreprise d’Obeo. La notation utilisée est ArchiMate, le standard de l’Open Group. Ce langage de modélisation est spécialisé dans la cartographie des applications d’un SI, mais également de l’infrastructure technique sur laquelle elles sont déployées (logiciels, serveurs, etc.). Il fournit aussi le moyen de modéliser plus largement l’entreprise (son organisation, sa stratégie, ses processus), de manière à décrire à quels besoins répond le SI et ainsi vérifier son alignement métier.

Cette interopérabilité offre une totale collaboration entre l’ensemble des acteurs d’un projet de réalisation d’une application, des experts métier jusqu’aux concepteurs/développeurs, en passant par les business analysts et les architectes logiciel.

Après avoir présenté Obeo ISD (S.1 Ep.1), abordé la méthode d’analyse Graal (S.1 Ep.2), la traçabilité des exigences avec les user stories, la cinématique et les maquettes d'écrans (S.1 Ep.3) et modélisé une architecture SOA micro-services ou Web Services (S.1 Ep.4), il nous restera, pour atteindre le Graal, à voir comment ISD peut générer le code de l’application. Nous verrons entre autres la modélisation des entités persistantes, les MLD (Modèle Logique de Données), les MPD (Modèle Physique de données), la génération et l’exécution de scripts SQL.

Merci pour vos commentaires et peut-être serez-vous désireux de faire partager vos retours d’expérience ou vos idées sur l’architecture d’entreprise et l’art de la modélisation de système.

Alors, écrivez-nous et nous serons heureux de publier vos articles.

“ Ce n'est pas sa beauté, sa force et son esprit que j'aime chez une personne,
mais l'intelligence du lien qu'elle a su nouer avec la vie. “
Christian Bobin

Des plus petites aux plus grandes entreprises, le concept de bounded context est aujourd’hui au cœur de la conception d’architecture logicielle, mais se pose l’éternelle question de quelle méthode pour parvenir à un découpage produisant le couplage le plus faible, augmentant ainsi l’évolutivité, l'autonomie et l'agilité.

L'architecture hexagonale (ou encore Ports & Adapters Architecture, ce qui est moins sexy) créée par Alistair Cockburn garantit la réutilisabilité de la logique métier, en la rendant agnostique techniquement.

(Diagramme de Composants UML pour l'illustration de l'Architecture Hexagonale, réalisé avec l’outil commercial Enterprise Architect de Sparx Systems https://sparxsystems.com/ Les composants du domaine implémentent les interfaces des API métiers et utilisent les interfaces des SPI de persistance).

Présentation

Chris Richardson, dans son article (en anglais) Jfokus: Cubes, Hexagons, Triangles, and More: Understanding Microservices, explique les pictogrammes métaphoriques utilisés pour marketer les sujets qu'il aborde. Dans la pseudo science des logos, l’hexagone symbolise le travail, la rigueur, l’effort collectif, le réseau, la structure sociale et enfin l'organisation.

Avec UML ou ArchiMate, point d'élément de modélisation hexagonal ! Une vue d'artiste assez commune, montrant l'hexagone, se trouve à la fin de cet article.   

Le domaine est isolé du monde extérieur par l'intermédiaire d'API (Application Programming Interface) et de SPI (Service Provider Interface) qui sont représentées par des interfaces.

Seulement deux mondes existent : à l'intérieur, toute la logique métier et à l'extérieur, l'infrastructure technique.

Les dépendances vont toujours de l'extérieur vers l'intérieur de l'hexagone. 

L'implémentation du domaine métier est indépendante de tous les autres aspects techniques comme la présentation, la gestion des protocoles de communication, les flux de messages, les moyens de persistance des entités métier, y compris des frameworks intrusifs obligeant à inclure du code technique.

Un corollaire de ceci est que le domaine métier ne dépend que de lui-même. 

Description

Un concept clé de cette architecture est donc de mettre toute la logique métier dans un seul endroit nommé le domaine (hexagone), qui ne dépend que de lui-même ; c'est le seul moyen de s'assurer que la logique métier est découplée des couches techniques. 

On y parvient en utilisant l'inversion du contrôle correspondant au "D (Dependency Inversion Principle)" des principes connus sous le nom de “SOLID” de Robert C. Martin ou Uncle Bob (voir son article en anglais : Solid Relevance), base de l’orienté objet, mais aussi de l’organisation structurelle de l’urbanisation des SI.

A noter que certains praticiens ont théorisé d’autres recommandations spécifiques aux microservices, comme celles de Paulo Merson, voir son article (en anglais) : Principles for Microservice Design: Think IDEALS, Rather than SOLID.

Bon nombre d'entreprises intègrent l'hexagone dans leurs logos pour symboliser l'organisation et le travail comme une ruche d'abeilles. 

Puisque les problèmes d'intégration sont traités à part, la testabilité du domaine métier est augmentée. 

De vrais tests fonctionnels sont enfin possibles grâce à cette contrainte de l'Architecture Hexagonale, car ils vont interagir directement avec le domaine métier et uniquement avec lui.

L'extérieur de l'hexagone (l'infrastructure) est divisé en deux parties virtuelles, le côté gauche et le côté droit :

• A gauche, se trouve tout ce qui va interroger le domaine (le contrôleur, les couches REST, Event Streaming, Batch Launcher, etc.),
• A droite, tout ce qui va fournir des informations/services au domaine (couche de persistance SQL ou NoSQL, services tiers, etc.).

Pour laisser l'extérieur interagir avec le domaine, le domaine propose des interfaces ou ports divisés en deux catégories :

• L'API fournit toutes les interfaces pour tout ce qui doit interroger le domaine. Ces interfaces sont implémentées à l’intérieur du domaine,
• Le SPI regroupe toutes les interfaces requises par le domaine pour récupérer des informations auprès de tiers. Ces interfaces sont utilisées dans l'hexagone et implémentées par la partie droite de l'infrastructure. 

L'API et le SPI font partie de l'Hexagone. L'API et le SPI ne manipulent que les objets métier du domaine de l'Hexagone. Ils assurent en effet l'isolement.

Dans une architecture en couches, l'objet métier ou le service crée généralement les DAO (Data Access Object). Dans l'architecture hexagonale, le domaine ne gère que les objets de domaine. Par conséquent, la persistance se charge de traduire les objets du domaine en « DAO » à persister et utilise pour cela des adaptateurs. 

Modèle UML

Dans le diagramme UML de composants ci-dessus, l'API et le SPI sont les ports ; les modules d'infrastructure, qui les implémentent ou les utilisent, sont les adaptateurs, d'où l'autre appellation plus technique de Ports & Adapters Architecture.

Pour cette raison, nous pensons que le langage de modélisation le plus approprié pour l'architecture Hexagonale est la norme UML, avec le diagramme de composants permettant visuellement de mieux représenter les connexions entre les ports (prises) correspondant aux interfaces fournies et ceux correspondants aux interfaces requises.

Modèle ArchiMate

(Modèle ArchiMate réalisé avec l’outil open source Archi de Phil Beauvoir et Jean-Baptiste Sarrodie de l’Open Group ArchiMate Forum https://www.archimatetool.com/)

Changer les technologies n'a aucun impact sur le code du domaine. Cette architecture est parfaitement conforme à la méthode de conception DDD (Domain Driven Design) abordée dans notre article Les couches de l'Architecture Microservices et la méthode de conception DDD (Domain Driven Design).

Intérêts

L'avantage majeur que présente cette architecture vient de sa modularité. Parce que tout est découplé, une couche REST et l'Event Streaming peuvent coexister simultanément sans aucun impact sur le domaine métier.

Du côté SPI, une migration de SQL vers NoSQL est grandement facilitée. Étant donné que le SPI ne changera pas parce qu'on modifie la méthode de persistance, le reste de l'application ne sera pas affecté. 

Limites

Toutefois, l'architecture hexagonale ne convient pas systématiquement à toutes les situations. De la même manière que pour le Domain Driven Design, elle ne s'applique réellement qu'à un domaine métier consistant. Il est déconseillé de la mettre en œuvre pour une application transformant juste des données dans un autre format, par exemple.

Exceptions

Le domaine doit être complètement exempt de toutes technologies, sauf, et c’est l’exception qui confirme la règle, celles qui auraient un très faible impact sur le domaine métier, par exemple un gestionnaire de logs et de traces, comme indiqué dans notre article sur le DDD (Les couches de l'Architecture Microservices et la méthode de conception DDD (Domain Driven Design)).

Méthode de conception

Une équipe de développeurs (la “two-pizza team” popularisée par Jeff Bezos) doit : 

• Commencer par l'intérieur de l'hexagone,
• Se concentrer sur la fonctionnalité, plutôt que sur les détails techniques,
• Retarder les choix sur la mise en œuvre technique. Parfois, il est difficile de savoir de quelle implémentation technique on a besoin au début. Par conséquent, retarder ce choix aide à se concentrer sur ce qui apporte de la valeur à l’entreprise : la fonctionnalité.
  De plus, après la mise en place de la logique métier, de nouveaux éléments peuvent aider à faire le meilleur choix concernant l’infrastructure.
  Cela garantit que l'hexagone est autonome et qu’il est auto-testé avec de vrais tests fonctionnels centrés sur le métier uniquement. Ces tests appellent directement l'API du domaine en évitant toute perturbation de la partie technique. Un adaptateur est créé, simulant le contrôleur pour tester les fonctionnalités du domaine.

Conclusion

Le réel avantage à découpler la logique métier du code technique, c’est de garantir que le domaine d'activité est durable et robuste, face à l'évolution continue de la technologie.

En résumé, les caractéristiques de l'Architecture Hexagonale :

• Mettre toute la logique métier en un seul endroit,
• Le domaine est isolé et agnostique sur la partie technique, car il ne dépend que de lui-même,
• Les dépendances vont toujours de l'extérieur vers l'intérieur de l'Hexagone,
• L'Hexagone est un module autonome. Ainsi, il augmente la testabilité du domaine en écrivant de vrais tests fonctionnels qui n'ont pas à traiter de problèmes techniques,
• Cette architecture offre une modularité puissante. Il aide à écrire autant d'adaptateurs que nécessaire avec un faible impact sur le reste du logiciel. Et comme le domaine est indépendant des technologies, elles peuvent être modifiées sans aucun impact sur l'entreprise,
• En commençant toujours par le domaine, les développeurs assurent d'apporter de la valeur au client en se concentrant sur le développement des fonctionnalités. De cette façon, ils peuvent retarder les choix de mise en œuvre technique, pour faire le meilleur choix au bon moment.

Et pour terminer, voici à mon avis la meilleure vue d'artiste, issue de l'Open Group (https://publications.opengroup.org/), désolée Alistair et Chris.

“Aimer savoir est humain, savoir aimer est divin”

Joseph Roux

Compléments de lecture

• L’Architecture Micro-Services expliquée à ma fille
  
  
• Inconvénients de l'Architecture Micro-Services
  
  
• Orchestration des micro-services avec BPMN
  
  
• Conseils pour réussir vos micro-services et éviter qu’ils ne se transforment en véritable pensum
  
  
• Estimation de la complexité d’une Architecture Micro-Services
  
  
• Solutions sur étagère pour la gestion des défaillances des Micro-Services
  
  
• Comment éviter la loi de Conway et faciliter ainsi l’agilité avec l’approche Micro-Services ?
  
  
• Les couches de l'Architecture Microservices et la méthode de conception DDD (Domain Driven Design)

Nous allons décrire dans cet article le rôle des différentes couches de l'Architecture Microservices et le lien avec la méthode de conception DDD.

(Ce diagramme ArchiMate, montre que toutes les couches dépendent de la couche “Domaine Métier”. Réalisé avec Modelio Open Source outil de modélisation UML, BPMN et ArchiMate)

Certaines grandes plateformes numériques dont certaines font partie des GAFAM ont été confrontées récemment à de gigantesques pannes paralysant l’ensemble de leurs activités écornant leur image de Graal de la technologie. Un des enjeux de l’architecture Microservices est d’offrir une meilleure résilience grâce à des outils de détection, de contournement et de remplacement des blocs défectueux. 

Si la physique de l’infiniment grand et de l’infiniment petit forme un tout, il en va de même pour les Systèmes d’Information qui se basent sur les concepts et patterns des technologies objets de développement, comme les fameux Design Patterns du GoF (1995), les principes SOLID, les GRASP patterns, ceux de Martin Fowler et Sam Newman.

Les systèmes sont faiblement couplés vers l’extérieur et sont constitués d’éléments cohérents en interne.

On est bien en présence d'une architecture fractale. Les domaines d'application des fractales se retrouvent partout même dans l'urbanisme des villes et donc aussi dans l'urbanisme des SI.

Dans sa méthode de conception DDD, Eric Evans, auteur du livre “Domain-Driven Design: Tackling Complexity in the Heart of Software”, intègre et développe ces patterns dans l'Architecture Microservices adoptée aussi bien par les GAFAM que par les PME.  

Couche Contrôleur

Les interfaces de communication ou API (Application Program Interface) sont implémentées.

Le protocole le plus simple et le plus utilisé est REST (REpresentational State Transfer) reposant sur HTTP.

Les données sont représentées textuellement en JSON (JavaScript Object Notation).

Tout est permis, on peut trouver des protocoles de type “Event Streaming Consumer” ou des interfaces pour les programmes batchs. 

Le pattern d’architecture distribuée DTO (Data Transfer Object), consistant à ne transférer que les données utiles est mis en œuvre et s’appuie sur des technologies de sérialisation/désérialisation des objets en JSON.

L'implémentation du pattern "proxy" permet d'utiliser des objets distants et complexes comme s'ils étaient locaux en masquant la gestion des trames HTTP et la transformation en JSON.
Pour les spécificités des microservices, les aspects comme la traçabilité condition sine qua non pour la mise au point, la supervision des états, la conformité des SLA (Service Level Agreement) et l’administration sont effectués par de nombreuses technologies faisant partie de l’entité contrôleur.  

Couche Applicative

Les fonctionnalités sont dérivées des cas d’utilisation UML dans lesquels on trouve des VO (Value Object) qui sont des objets immutables.
La coordination et les transactions longues métier sont réalisées par la gestion de l’état de progression d’un processus métier.
Aucune règle métier n’est exécutée, seuls des contrôles syntaxiques sont opérés pour préparer les données métier pour la couche “Domaine Métier”.
Les authentifications, autorisations, cryptages et les parades aux attaques connues, sont mis en œuvre.
Des contributions à l’amélioration des performances peuvent se traduire par des technologies de cache.

Couche Domaine Métier (DDD)

Ce niveau représente une zone métier (“Bounded context” en DDD) bien délimitée et autonome (“Les bonnes barrières font les bons voisins” Eric Evans).
En MDA (Model Driven Architecture), ce serait la couche PIM (Platform Independent Model).

Ici, on ne trouve pas la moindre trace de framework technologique, la persistance par exemple est reléguée dans l’infrastructure.

A l’intérieur des frontières, on parle le jargon des experts métiers (traduit en DDD cela donne : “Ubiquitous Language”). Le langage ubiquitaire est le concept de définition d'un langage (parlé et écrit) qui est également utilisé par les développeurs et les experts du domaine pour éviter les incohérences et les problèmes de communication dus aux problèmes de traduction et aux malentendus. La même terminologie apparaît dans le code, les conversations entre tous les membres de l’équipe, les spécifications fonctionnelles, etc.
Les modèles sont composés de diagrammes de classes et d’états-transitions UML.
Le métier et le code sont alors liés par l’Ubiquitous Language.

Pour faire communiquer des "bounded context" différents, il faut des adaptateurs permettant l’interopérabilité et garantissant l’indépendance des systèmes. Déjà en 1995 la bande des quatre (Erich Gamma, Richard Helm, Ralph Johnson et John Vlisside) inventeurs des patterns de conception objet et auteurs du livre fondateur “Design Patterns: Elements of Reusable Object-Oriented Software” avaient défini le pattern “adapter”.

Oserait-on l’heuristique : DDD = 80% de bounded context + 20% d’adapter.

Couche Infrastructure

Elle sert de support à toutes les autres couches rendant possible l’interopérabilité.
La persistance des entités métier est réalisée. 
Les autres couches y accèdent en utilisant l’injection de dépendances (pattern IOC Inverse Of control) qui est un des principes SOLID (Single responsibility ; Open closed ; Liskov substitution ; Interface segregation ; Dependency inversion), qui délègue à un tiers la réalisation des relations entre les entités permettant l'agilité, l'évolutivité, la maintenabilité et la réutilisabilité en maintenant un couplage faible entre les composants.

Conclusion

Le domaine ne dépend d’aucune couche
L’infrastructure dépend du domaine.
L’application dépend du domaine
La présentation dépend de l’application et de l’infrastructure.

“Tiny, the only thing you need to know about development, project management and leadership” 
Chad Fowler
(“Minuscule, la seule chose que vous devez savoir sur le développement, la gestion de projet et le leadership”)

Compléments de lecture

• L’Architecture Micro-Services expliquée à ma fille
  
  
• Inconvénients de l'Architecture Micro-Services
  
  
• Orchestration des micro-services avec BPMN
  
  
• Conseils pour réussir vos micro-services et éviter qu’ils ne se transforment en véritable pensum
  
  
• Estimation de la complexité d’une Architecture Micro-Services
  
  
• Solutions sur étagère pour la gestion des défaillances des Micro-Services
  
  
• Comment éviter la loi de Conway et faciliter ainsi l’agilité avec l’approche Micro-Services ?
  
  
• Le meilleur outil pour transformer, dériver, parcourir, requêter sur des modèles afin de mettre en œuvre MDA (Model Driven Architecture)

L'objectif des micro-services est d'accélérer la mise en production des applications, en décomposant l'application en petits services autonomes, qui peuvent être déployés indépendamment les uns des autres. Une architecture de micro-services pose également certains problèmes. Voici une synthèse des patterns les plus utilisés afin d'éviter les pannes.

Le génie logiciel emprunte de nombreuses idées au génie civil, où les ingénieurs s'occupent de la conception, de la construction et de l'entretien des routes, des ponts, des canaux, des barrages et des bâtiments.

Ces ingénieurs prévoient les défaillances des composants individuels et pour pallier cela, ils assurent plusieurs redondances pour des bâtiments plus sûrs et plus stables.

Le même “mindset” peut être appliqué au génie logiciel. Des défaillances isolées sont inévitables, mais l'objectif reste de concevoir des systèmes fonctionnant aussi longtemps que possible. 

Les pratiques d'ingénierie, telles que la modélisation et l’injection de défaillances, devraient être incluses dans le cadre d'un processus d’intégration et de livraison continue, afin de concevoir des systèmes plus fiables. 

Circuit Breaker (Disjoncteur)

Le modèle "Circuit Breaker" (disjoncteur) est couramment utilisé pour garantir que, en cas de défaillance d’un micro-service, l'ensemble du système ne soit pas affecté. 

Cela se produit si le volume des appels au service ayant échoué est élevé et, pour chaque appel, on doit attendre qu'un délai se produise avant de continuer.

Faire l'appel au service défaillant et attendre utiliserait des ressources, ce qui finirait par rendre le système global instable.

Le modèle de "Circuit Breaker" se comporte comme un simple disjoncteur, comme celui de votre circuit électrique domestique. Les appels à un micro-service sont enveloppés dans un objet "Circuit Breaker".

Lorsqu'un micro-service défaille, l'objet "Circuit Breaker" autorise les appels ultérieurs au service jusqu'à ce qu'un seuil de tentatives infructueuses soit atteint.

À ce moment-là, le "Circuit Breaker" pour ce micro-service se déclenche, et tout autre appel sera court-circuité et n'entraînera pas d'appels au micro-service en échec.

Ce pattern d'installation économise de précieuses ressources et maintient la stabilité globale du système.

(Diagramme de séquence UML du "Cicuit Breaker")

Lorsque le "Circuit Breaker" se déclenche et que le circuit est ouvert, un traitement de secours peut être démarré à la place. La logique de secours effectue généralement peu ou pas de traitements et renvoie une valeur. Ces actions de secours doivent avoir peu de chances d'échouer, car ils s'exécutent à la suite d'un échec au départ.

Bulkheads (Cloisonnement) 

L’informatique a souvent repris à son compte des concepts appartenant à d’autres domaines comme pour la sécurité des navires avec les cloisons étanches des coques. Si l'une des cloisons est endommagée, cette défaillance est limitée à cette seule cloison et les autres cloisons permettent de garder le bateau à flot.

La même approche de partitionnement peut également être utilisée dans les logiciels pour isoler une partie du système. 

Ce pattern peut également être appliqué dans les micro-services eux-mêmes. Par exemple, un pool de threads utilisés pour atteindre deux systèmes existants. Si l'un des systèmes a commencé à connaître un ralentissement et a provoqué l'épuisement du pool de threads, l'accès à l'autre système existant sera également affecté.

Avoir des pools de threads séparés garantit qu'un ralentissement dans un système existant n'épuise que son propre pool de threads.

(Exemple de pattern "bulkhead" : utilisation de pools de threads séparés)

Gestion décentralisée des données

Dans une application monolithique, il est facile de traiter les transactions, car tous les composants font partie du monolithe.

Lorsque vous passez à une architecture de micro-services distribuée, vous devez désormais potentiellement traiter des transactions réparties sur plusieurs services.

Dans une architecture de micro-services, la préférence va à "BASE" (Basically Available, Soft state, Eventual consistency), plutôt que de type "ACID" (Atomicity, Consistency, Isolation, Durability).

Les transactions distribuées sont à éviter chaque fois que c'est possible.

Idéalement, chaque micro-service gère sa propre base de données. Cela permet d’être agnostique sur les moyens de persistance (SQL, NoSQL…).

Une contrainte de préservation du caractère ACID d’une transaction peut aboutir à ce que plusieurs micro-services utilisent la même base de données. Quelle qu'en soit la raison, une attention particulière doit être accordée au partage de la base de données.

Les avantages et les inconvénients de le faire doivent être pris en considération.

A l’opposé, le partage d'une base de données peut violer le principe de parfaites indépendance et autonomie de chaque micro-service. En effet dans ce cas, les micro-services pourraient dépendre des changements dans la base apportés par un autre micro-service.

Le niveau de partage entre les micro-services doit être limité autant que possible pour rendre les micro-services aussi faiblement couplés que possible.

Discoverability (Découverte)

L'architecture des micro-services nécessite de rendre les services fiables et tolérants aux pannes. Cela implique la construction de micro-services de telle manière que, si l'infrastructure sous-jacente est détruite, alors les micro-services peuvent être reconfigurés et communiquer avec d’autres micro-services pour les besoins de l’application globale.

L'utilisation du cloud computing et des conteneurs, pour le déploiement de micro-services, offre la possibilité d’une reconfiguration dynamique. Lorsque la nouvelle instance du micro-service est créée, les autres micro-services peuvent la trouver rapidement et commencer à communiquer avec elle grâce à un système de découverte des micro-services reposant sur un registre (ex. open source : Netflix Eureka), auxquels tous les micro-services doivent s’enregistrer explicitement.

Avec un tel système, l’équilibrage de charge (load balancing ; ex. open source : Netflix Ribbon) devient alors une réalité.

Conception de communication inter-services

Lorsque les micro-services sont répartis sur les différents serveurs (Tomcat), conteneurs (Docker) ou machines virtuelles (Oracle Virtual Box), on peut se poser la question : comment communiquent-ils ?

Une première solution est de mettre en place des files d'attente de messages qui suffisent pour les communications unidirectionnelles.

Avec un monolithe applicatif, les clients de l'application (navigateurs ou applications natives) font des requêtes HTTP (Hypertext Transfer Protocol) à un équilibreur de charge, ce qui propage la demande à plusieurs instances identiques de l'application. 
Mais dans l'architecture micro-services, le monolithe a été remplacé par une collection de micro-services. Une deuxième solution consiste à utiliser le protocole REST (REpresentational State Transfer), pour la communication des micro-services entre eux ainsi qu’avec le client.

(Appels entre les clients et les micro-services en utilisant des API REST)

À première vue, cela peut sembler souhaitable. Cependant, certains clients peuvent être « bavards » ; d'autres peuvent nécessiter de nombreux appels pour obtenir les données. Étant donné que les services peuvent évoluer différemment, il y a d'autres défis à relever, comme le traitement des défaillances partielles.

Une meilleure approche pour le client est de faire peu de requêtes, peut-être juste une, en utilisant le pattern du GoF (Gang of Four) "façade", de type API Gateway (passerelle).

(Intégration du pattern "façade" comme l'API Gateway)

L'API Gateway se situe entre les clients et les micro-services et fournit des API qui sont sur mesure pour les clients. Elle consiste principalement à masquer la complexité technologique (par exemple, la connectivité à un ordinateur central), par rapport à la complexité de l'interface.

Une API Gateway est donc une façade. Cependant, une façade offre une vue uniforme des éléments internes complexes aux clients externes, alors qu'une API Gateway fournit une vue uniforme des ressources externes aux composants internes d'une application.

Tout comme le modèle de conception de façade, l'API Gateway fournit une interface simplifiée aux clients, ce qui rend les services plus faciles à utiliser, à comprendre et à tester.

En effet, il peut fournir différents niveaux de granularité aux clients. L'API Gateway peut fournir des API à grosses granularités aux appareils mobiles et des API à fines granularités aux ordinateurs de bureau, qui pourraient utiliser un réseau haut débit. Dans ce scénario, l'API Gateway réduit la conversation en permettant aux clients d'agréger plusieurs demandes en une seule, optimisée pour un client donné (tel que le client mobile).

HTTP synchrone versus messagerie asynchrone

Il existe deux approches principales pour la communication interprocessus :

• Les mécanismes synchrones basés sur HTTP, tels que REST, SOAP ou WebSocket, qui permettent de conserver un canal de communication entre les navigateurs et serveurs, pour les requêtes / réponses pilotées par les événements,
   
• La communication asynchrone utilisant un "message broker" (négociateur de messages ; ActiveMQ, Kafka, RabbitMQ, Redis...).

La communication synchrone est un mécanisme simple, compatible avec le pare-feu. L'inconvénient est qu'elle ne prend pas en charge d'autres modèles, comme le modèle de publication / abonnement. Elle ne permet pas non plus la mise en file d'attente des demandes, ce qui peut ralentir les performances.

Avec les applications synchrones, le client et le serveur doivent être disponibles simultanément et les clients doivent toujours connaître l'hôte et le port du serveur, ce qui n'est pas toujours simple lorsque les services évoluent automatiquement lors d'un déploiement cloud.

La communication asynchrone dissocie les services les uns des autres dans le temps, permettant d’envoyer des messages au fil de l'eau, stockés dans une file d'attente, tandis que le système de messagerie prend la responsabilité du message, en le gardant en sécurité jusqu'à ce qu'il puisse être livré au destinataire.

Le style de messagerie de publication / abonnement est plus flexible que la mise en file d'attente point à point, car il permet à plusieurs destinataires de s'abonner au flux de messages. Cela permet d'ajouter plus facilement plusieurs micro-services à l'application. 

Alternativement, un mécanisme asynchrone utilise un "message broker", cet intermédiaire permet  de diminuer le couplage entre les producteurs et les consommateurs. Le "message broker" met les messages en mémoire tampon jusqu'à ce que le consommateur soit en mesure de les traiter. Ce type de scénario de répartition de la charge permet aux développeurs de créer des applications évolutives et réactives. L'application peut être découpée en threads s'exécutant en arrière-plan, ce qui lui permet de continuer sans attendre la fin d'exécution des threads.

Les deux approches présentent des avantages et des inconvénients. La plupart des applications utilisent une combinaison de ces deux approches, adaptée à leurs besoins.

Faire face à la complexité

Une architecture de micro-services crée une utilisation supplémentaire des ressources pour de nombreuses opérations. Le nombre de composants augmente et en même temps la complexité. Rationaliser le comportement de chaque composant individuel pourrait être plus simple, mais comprendre le comportement de l'ensemble du système est beaucoup plus difficile.

Le réglage d'un système basé sur des micro-services, qui peut consister en des dizaines de processus, en comptant les "load balancers" et les "messages brokers", nécessite une surveillance et une expertise accrues.

Tests 

Le test d'un système complexe nécessite des suites de tests unitaires et d'intégration, et un cadre de tests qui simule les composants défaillants, la dégradation des performances du service, la résistance et le comportement global du système au cours d'une journée classique.

Ces cadres de tests assurent l'exactitude et la résilience globale du système.

En raison de l'accent mis sur le bon fonctionnement du système lorsqu'un composant tombe en panne, dans une architecture de micro-services, il n'est pas rare de tester un échec en production.

Des tests automatisés, qui forcent un composant à échouer, permettent de tester la capacité du système à reprendre en cas d'erreurs, ainsi que les capacités de surveillance.

Surveillance 

En plus des systèmes de surveillance conventionnels, des services bien conçus peuvent fournir des informations supplémentaires sur l'état de santé d'une architecture en utilisant le modèle publication / abonnement.

De cette façon, les informations peuvent être collectées par le service de surveillance, offrant des indicateurs de configuration.

Ces indicateurs peuvent à leur tour être utilisés pour garantir que les services ont la capacité suffisante pour traiter le volume demandé et comparer les performances actuelles par rapport à celles attendues.

Les contrôles personnalisés peuvent être enregistrés pour recueillir des données supplémentaires.

Toutes les informations de collecte peuvent être agrégées et affichées dans le tableau de bord de surveillance.

DevOps 

Le défi de maintenir les micro-services opérationnels signifie que vous avez besoin d'expertise en DevOps dans votre équipe de développement.

Programmation polyglotte

Très souvent, une architecture micro-services utilise plusieurs langages, Java pour la partie back-end, Python pour l'IA… ce qui présente un défi pour maintenir un tel système hyper-polyglotte.

Des développeurs peuvent déployer, exécuter et optimiser les produits noSQL (MongoDB) et remplacer l'administrateur de base de données (DBA).

Maintenir un pipeline de développeurs et d'architectes techniques qualifiés est aussi critique que la maintenance du pipeline DevOps.

On doit garantir qu’il y a suffisamment de développeurs qualifiés pour maintenir la plate-forme et améliorer la conception du système à mesure que de nouvelles évolutions sont réalisées.

La plupart des organisations ont une liste restreinte de langages de programmation qu'ils utilisent. Cela présente des avantages du point de vue de la réutilisation du code et des compétences.

Conception évolutive

L'architecture des micro-services permet une approche de conception évolutive. L'idée centrale est que vous pouvez introduire de nouvelles fonctionnalités dans votre application en changeant un seul micro-service. Il vous suffit de déployer les micro-services que vous avez modifiés. Le changement n'affecte que les consommateurs de ce micro-service et, si l'interface n'a pas changé, tous les consommateurs continuent de fonctionner.

Étant donné que les micro-services sont faiblement couplés, petits et ciblés, et ont un contexte borné, des modifications peuvent y être apportées rapidement et fréquemment avec un risque minimal.

Cette facilité de l'évolutivité d'un micro-service permet d'évoluer rapidement.

Parce qu'un micro-service est petit et généralement conçu, développé et entretenu par une petite équipe « deux pizzas », il est typique de trouver des micro-services entièrement réécrits, par opposition à être mis à niveau ou maintenus. Un compromis courant réside dans la petite taille de votre micro-service.

Cependant, plus chaque micro-service est petit, plus il est probable qu'une mise à jour d'une application classique nécessite plus de micro-services à déployer, augmentant ainsi le risque de dysfonctionnement.

Les principes des micro-services, tels que la déployabilité indépendante et le couplage lâche, doivent être pris en compte pour déterminer quelle fonctionnalité métier devient un micro-service.

Conclusion

Les micro-services peuvent avoir un impact positif sur votre entreprise.

Ce nouveau paradigme qu'est l'architecture micro-service (MSA) nécessite l'utilisation de modèles de conception pour la fiabilité, exactement comme pour le paradigme objet, où il existe des design patterns pour l'évolutivité, la maintenabilité et la réutilisabilité.

Rhona Maxwel
@rhona_helena

"Au calme clair de lune triste et beau,
Qui fait rêver les oiseaux dans les arbres
Et sangloter d'extase les jets d'eau,
Les grands jets d'eau sveltes parmi les marbres."

Clair de lune, Paul Verlaine

En complément :

Comment éviter la loi de Conway et faciliter ainsi l’agilité avec l’approche Micro-Services ?

Estimation de la complexité d’une Architecture Micro-Services

Conseils pour réussir vos micro-services et éviter qu’ils ne se transforment en véritable pensum

Inconvénients de l'Architecture Micro-Services

L’Architecture Micro-Services expliquée à ma fille

« Les organisations qui conçoivent des systèmes [...] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation. » Melvin Conway (Source Wikipédia)

(Mars Climate Orbiter est une sonde spatiale de la NASA lancée en 1998 pour étudier la planète. A la suite d'une confusion d'unités, la sonde se place en orbite trop basse et est détruite.

Un logiciel développé par les ingénieurs de Lockheed, concepteurs de la sonde, communiquait la poussée des micro-propulseurs en unités de mesure anglo-saxonnes (livre-force · seconde), tandis que le logiciel de l'équipe de navigation du JPL qui recevait ces données pour les calculs des corrections de trajectoire attendait des données en unités du système métrique (newton · seconde)).

Lorsqu'un système cible est décomposé en services, il existe un risque réel que sa décomposition s'aligne sur les silos ou les strates (cela dépend comment on voit les choses) existants au sein de l'organisation.

 
L’organisation des équipes a un effet direct sur le système que l’on conçoit. Les applications peuvent alors refléter les intérêts de l’organisation au détriment des réels besoins utilisateurs.
Ça signifie qu'il existe un risque pour que le système soit plus fragile, car il y a plus de modules indépendants à gérer et ne s’intégrant pas bien, même si le service résultant peut communiquer avec chacun d’entre eux.

 
De plus, si les services qui composent le système ne sont pas conçus pour le bon objectif, ils ne peuvent pas être réutilisés. Les coûts de développement et de maintenance peuvent également augmenter si les services sont conçus selon des périmètres organisationnels ou technologiques.

 
Une conception en ayant à l’esprit le métier comme unique objectif peut devenir critique. 

 
Les équipes, au-delà des frontières organisationnelles, doivent se réunir et concevoir les services conjointement, plutôt que d'utiliser des micro-services pour acheminer les appels entre les équipes.

 
Voici un extrait du contexte d’une de nos études de cas, qui nous sert comme POC pour tester des outils, illustrer des patterns ou des architectures comme les micro-services.

 
Pour avoir de la matière, nous avons choisi le monde assurantiel. Nous appellerons ClairPrev notre assureur fictif, résultant de nombreuses fusions/acquisitions et reflétant ce qui s'est passé ces derniers temps.

Dans ce scénario, la conception du système a été calquée sur la structure de communication de l'organisation. Des défauts évidents apparaissent à cause de services isolés. 

 
Le système de prestation ne peut pas évoluer, car chaque domaine métier a son propre processus, chacun a sa propre vision de l’entité métier “Personne”. Chacun utilise des termes différents ou, pour une même entité métier, leur prête des sémantiques différentes.

 
Les services conçus dans ce scénario vont également être impactés par des changements qui affectent généralement une organisation, comme les aspects légaux, les fusions et acquisitions. 

 
Aujourd’hui, les exigences d’agilité dans les organisations et les systèmes sont devenues stratégiques. Tout change tout le temps, mais pas toujours au même moment. Un système n’est donc agile que s’il est possible de le faire évoluer par morceau. Il est d’autant plus agile que les morceaux sont plus petits et qu’ils sont faiblement couplés entre eux.

 
Les services ne doivent pas être évalués par chaque domaine, avec leurs propres paramètres de configuration, tests, performance, qualité, sécurité, time to market... 

 
L'architecture micro-services fonctionne bien si les architectes métier et techniques de chaque domaine communiquent entre eux pour concevoir les services conjointement, afin de servir les objectifs stratégiques de l’entreprise. 

Le diagramme ArchiMate ci-dessus montre un refactoring avec une approche architecture micro-services (AMS). A ce niveau d’échelle, on ne peut la différencier d’une architecture SOA (Service Oriented Architecture), qui de toute manière n’est que l’ancêtre de l’AMS.

 
En appliquant la loi de Conway, les équipes appartenant au domaine “Processus Transverses” se sont réunies pour concevoir un service amont de prestation. Lorsqu'une telle demande est reçue, elle est stockée, fournissant une vue unifiée de la personne (déclarant). Suivant les principes de la SOA, on ajoute un service d'orchestration (Service Orchestration de Prestation), qui reçoit la demande, puis selon les cas, appelle les services Santé, Prévoyance ou Services à la Personne. 

 
Ces appels activent ensuite chaque module de gestion de paiement.

 
Comme la conception des services ne suit plus les frontières organisationnelles, technologiques ou de communication, ils peuvent alors résister à des changements dans l'organisation, comme des fusions, des nouvelles réglementations nationales ou européennes, ainsi que le reengineering de processus. 

 
Les services sont indépendants et supportent des fonctions métier bien spécifiques.

Notes sur les outils utilisés

Visual Paradigm Free Edition

Pour ceux qui seraient intéressés par les outils utilisés pour des 2 diagrammes ArchiMate montrant les flux échangés entre blocs fonctionnels, le premier a été réalisé avec Visual Paradigm :

https://online.visual-paradigm.com/fr/diagrams/

C’est la mallette “James Bond” du parfait consultant powerpointer qui doit dégainer des présentations avec des schémas sexy. Mais attention, ici point de référentiel d'artefacts d’architecture, d’outils de traçabilité, d’analyseur d’impact…, non non, juste du coloriage !

ADOIT:CE Community Edition

Le 2ème diagramme a été réalisé avec ADOIT:CE. Voir nos articles :

• ADOIT:CE pour la gestion de l’Architecture d’Entreprise
   
• ADOIT:CE (compléments d’information)

Là, par contre, c’est du lourd (bien qu’il s’agisse d'un client léger), avec, bien sûr, un référentiel d’objets, le support complet d’ArchiMate 3, des outils de traçabilité, bref la mallette du parfait cartographe.

Conclusion

Nos systèmes, nos produits, nos outils reflètent nos rôles, nos processus et nos méthodes.

Pour enfoncer le clou, on peut citer, par exemple, Eric S. Raymond qui écrivait : "si vous avez quatre équipes travaillant sur un compilateur, vous aurez un compilateur à quatre étapes".

Rhona Maxwel

@rhona_helena

" Sauriez-vous compléter la suite de Conway, John de son prénom :

1

11

21

1211

? "

A découvrir aussi

L’Architecture Micro-Services expliquée à ma fille

Le nouveau style d’architecture pour concevoir des applications informatiques, voire pour urbaniser enfin le Système d’Information de l’entreprise.

Inconvénients de l'Architecture Micro-Services

Intéressons-nous à quelques considérations techniques importantes, puis aux inconvénients de l’Architecture Micro-Services et enfin à son impact sur l’organisation.

Estimation de la complexité d’une Architecture Micro-Services

pour la comparer avec la complexité d’une architecture monolithique.

ADOIT:CE pour la gestion de l’Architecture d’Entreprise

Les articles de notre blog concernant les outils rencontrant généralement un grand succès, en voici un concernant un outil intéressant, et pas seulement parce qu’il est gratuit.

ADOIT:CE (compléments d’information)

Voici quelques compléments d’information intéressants qui ont été donnés par l’éditeur BOC Group.