urbanisation-si.com

urbanisation-si.com

Micro-Services études de cas

Etudes de cas tirées de la vraie vie couvrant tous les aspects des micro-services : modélisation, conception, intégration dans l'architecture d'entreprise, dernières technologies utilisées, patterns/anti-patterns.


Architecture Hexagonale, exemple de mise en pratique de la méthode DDD Domain Driven Design

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.

 

architecture-hexagonale-uml-diagramme-composant-domain-driven-design

 

(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

architecture-hexagonale-archimate-domain-driven-design-ddd

 

(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.

architecture-hexagonale-open-group

 

 

urbanisation-si_logo

 

 

Rhona Maxwel

urbanisation-si

@rhona_helena

“Aimer savoir est humain, savoir aimer est divin”

Joseph Roux

 

Compléments de lecture

 


04/01/2022
0 Poster un commentaire

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.


architecture-microservice-couche-application-technologique

(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.

 

 

urbanisation-si_logo

 

 

Rhona Maxwel

urbanisation-si

@rhona_helena

 

“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

 


14/12/2021
0 Poster un commentaire

Solutions sur étagère pour la gestion des défaillances des Micro-Services

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.

 

solutions-sur-etagere-defaillances-micro-service

 

 

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.

 

 

micro-service-circuit-breaker

 

(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.

 

 

micro-service-bulkheads

 

(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.

 

 

micro-service-communication-rest

 

(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).

 

micro-service-api-gateway

 

(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

 


11/02/2021
0 Poster un commentaire

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

« 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)

 

conception-microservice-loi-de-conway-adoit-ce-visual-paradigm

 

(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.

 

architecture-micro-services-loi-de-conway-visual-paradigm-free

 

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. 

 

architecture-micro-services-redesign-loi-de-conway-adoit-ce

 

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/

 

Visual-Paradigm-Free-Edition

 

 

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 :

 

 

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.

 

ADOIT-CE

 

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.

 


12/01/2021
0 Poster un commentaire