Data driven

Les Microservices s’inscrivent dans une démarche agile

11 décembre 2017

L’organisation en Feature Teams est le mode d’organisation le plus adapté au pattern des Microservices.

Une Feature Team est une équipe agile :

  • Stable
  • Avec un périmètre fonctionnel réduit et bien défini.
  • Autonome au sein de son périmètre (décentralisation des décisions et auto-organisation).
  • Avec une forte orientation client : équipe orientée produit et non pas projet
  • Pluridisciplinaire : la pluridisciplinarité des Feature Teams est un levier pour garantir leur autonomie.

Le mode d’organisation en Feature Team est le mode d’organisation qui reflète au niveau de l’organisation les principes de décentralisation d’autonomie que les Microservices implémentent au niveau de l’architecture logicielle.

Les architectures Microservices s’inscrivent dans une démarche agile : les Microservices ont une durée de vie finie. La taille réduite et l’autonomie des Microservices permet aux équipes de régulièrement les faire et les défaire sans difficulté majeure.

Un Microservice est centré sur le client : il implémente une fonctionnalité qui doit fournir une plus-value au client. Cette plus-value pour le client justifie l’existence même du Microservice. Un Microservice qui n’offre pas de plus-value client doit faire l’objet d’une étude pour vérifier s’il ne peut pas être supprimé ou dissous dans d’autres Microservices.

Il est important de noter que le découpage d’une application Monolithe en Microservices n’est pas figé.

Ce découpage peut, en effet, se révéler plus ou moins inefficace dans le temps et donc plus être aussi performant.
L’architecture Microservices a l’avantage d’apporter de la souplesse en permettant de facilement faire évoluer et revoir ce découpage.

Caractéristiques d’un Microservice

schema des caractéristique du micro service

Le découpage de notre exemple d’application Monolithe en Microservices

schema des application monolithe en microservice

Si l’on reprend l’exemple de l’application monolithe de l’article n°2, et que nous la découpons en Microservices, nous obtenons les Microservices suivants :

  • Un Microservice pour la gestion des livraisons
  • Un Microservice pour la gestion des factures
  • Un Microservice pour la gestion des commandes

Chaque Microservice de notre exemple est autonome en ce qui concerne ses données.
Pour un découplage maximal entre les Microservices et pour respecter l’orientation forte qui déconseille autant que possible la réutilisation, chaque Microservice possède son propre référentiel de clients. Cela est cohérent car, selon le contexte de chaque Microservice, la notion de client est différente :

  • Pour le Microservice gestion des livraisons, un client est un nom, un prénom et une adresse postale
  • Pour le Microservice gestion des factures, un client est un nom, un prénom, un taux de TVA applicable et une adresse.
  • Pour le Microservice gestion des commandes, un client est un numéro de client, un taux de réduction et un mode de paiement.

 

Le découpage en Microservices de l’exemple d’application monolithe

schema de découpage des micro services

Les Microservices communiquent en asynchrone

Un mode de communication asynchrone ne nécessite pas de synchronisation entre les deux parties qui communiquent.
Par exemple, la communication par mail (ou par SMS) est un mode de communication asynchrone : je ne dois pas me synchroniser avec le destinataire de mon mail pour qu’il puisse le lire. De plus, je peux envoyer un autre mail sans pour cela devoir attendre que mon premier mail soit lu. A l’inverse, un mode de communication synchrone nécessite que les deux parties se synchronisent pour pouvoir échanger un message. A l’inverse du mail ou du sms, la communication par téléphone ou talkie-walkie est un mode de communication synchrone.

dessin sur la communication asynchrone

De même, une application qui communique avec un serveur par des requêtes Http communique de façon synchrone si elle doit attendre la réponse du serveur pour pouvoir continuer l’exécution de ses traitements.
Pour garantir l’autonomie maximale entre les Microservices, les communications asynchrones à travers un broker de messages sont privilégiées autant que possible par rapport aux communications synchrones (par des requêtes http).

L’asynchronisme permet un découplage temporel entre les Microservices mais en contrepartie on ne peut plus garantir la consistance du système à tout instant : on parle alors de consistance éventuelle, c’est à dire que le système accepte un état inconsistant temporaire tant que l’on garantit qu’il reviendra à un état consistant dans le futur (une fois les messages en attentes consommés par chaque Microservice). Afin de garantir cette consistance à terme, les Microservices synchronisent l’état de leurs référentiels respectifs en s’échangeant des messages de façon asynchrones.

Au cours des 5 premiers articles, nous avons étudié les avantages apportés par les Microservices dans la recherche d’agilité et de réduction du Time To Market. Nous étudierons dans le prochain article quels sont les difficultés à surmonter lorsque l’on diffuse un grand nombre de Microservices dans un Système d’Information.


Illustrations : Sandy Malosse


5ème billet d’une série d’articles décrivant comment l’architecture logicielle est un levier d’optimisation du Time To Market :

  1. Le Time To Market : un enjeu stratégique
  2. Le Time To Market : les applications monolithes
  3. Le Time To Market : Microservices vs Applications Monolithes
  4. Le Time To Market : caractéristiques des Microservices
  5. Le Time To Market : Microservices et agilité
  6. Le Time To Market : les difficultés posées par les Microservices (1/2)
  7. Le Time To Market : les difficultés posées par les Microservices (2/2)
  8. Le Time To Market : une trajectoire pour la mise en œuvre de Microservices

 

 

 

Les informations recueillies sur ce formulaire sont enregistrées dans un fichier informatisé de gestion des Clients et Prospects (CRM).

Le Responsable de traitement est la société weave, 37 rue du rocher 75008 Paris RCS Paris 802 396 085.

Elles sont destinées à l’activité marketing du groupe weave ainsi quà celle de ses filiales, à l’exclusion de tout transfert hors de l’UE. Elles sont conservées pour une durée conforme aux dispositions légales (par exemple 3 ans pour les données prospects).

Ce traitement nécessite votre consentement que vous pourrez retirer à tout moment sans que cela ne remette en cause sa licéité.

Conformément à la loi « Informatique et Libertés » et au règlement européen n°2016/679, vous bénéficiez d’un droit d’accès, de rectification ou d’effacement, ainsi que d’un droit à la portabilité de vos données ou de limitation du traitement. Vous pouvez également pour des raisons tenant à votre situation particulière, vous opposer au traitement de vos données et donner des directives relatives à la conservation, à l’effacement et à la communication de vos données après votre décès. Vous disposez également du droit d’introduire une réclamation auprès de la Commission Nationale de l’Informatique et des Libertés (www.cnil.fr).

Vous pouvez exercer vos droits en nous contactant à l’adresse vosdonnees@weave.eu.

En poursuivant votre navigation sur ce site, vous acceptez l’utilisation de cookies pour mesurer notre audience, vous proposer des contenus et des offres personnalisées, ainsi que des fonctionnalités de partage sur les réseaux sociaux. En savoir plus sur notre politique de cookies et notre charte des données personnelles