urbanisation-si

urbanisation-si

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

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

20200703115506_01_recadrée

Dans notre premier article sur l’Architecture Micro-Services, nous avons indiqué parmi les principes que :

 

  • une application composée de micro-services serait plus simple et donc moins complexe qu’une application monolithique équivalente (c.-à-d. ayant les mêmes fonctionnalités).

 

Il s’agit là d’une sorte d’intuition, présentée comme un postulat. Pourrions-nous le démontrer ?

Postulats et formule magique

La programmation modulaire est apparue peu après les prémices de l’informatique, dès les années 1970, et quelques connaisseurs se sont intéressés à l’impact de la modularité sur la complexité d’un système. Cette complexité est liée au nombre de fonctions dans un système. Une constatation généralement faite par tous permet de formuler un second postulat :

 

  • la complexité d’un système croît exponentiellement avec le nombre de ses fonctions.

 

Comment quantifier cette croissance exponentielle ? Selon l’étude de Scott N. Woodfield en 1979 :

 

  • accroitre de 25 % le nombre de fonctions d’une solution logicielle double sa complexité.

 

Cette constatation est connue comme la loi de Robert L. Glass, qui porte le nom de celui qui l’a exprimée en 2003. Puis Roger Sessions l’a formulée ainsi en 2011, après une simplification mathématique justifiée : Complexité(NombreFonctions) = NombreFonctions3,11.

 

Dans le cadre d’une Architecture Orientée Services (SOA), il convient d’appliquer cette formule pour estimer la complexité de chaque partition, une partition étant un module contenant une ou plusieurs fonctions. Roger Sessions a constaté que la complexité dépendait également du nombre de dépendances entre les partitions-modules. La complexité totale est donc formulée ainsi :

 

ComplexitéTotale(NombreFonctions,NombreDépendances) =
NombreFonctions3,11 + NombreDépendances3,11

 

N.B. Afin de ne pas compter les dépendances deux fois, on les comptera au niveau de chaque module qui dépend d’autres modules (les pointes de flèches sur un diagramme de dépendances).

 

Vous noterez qu’une dépendance a la même pondération d’une fonction. L’unité de mesure est la SCU (Standard Complexity Unit). Il ne s’agit pas vraiment d’une mesure absolue, mais d’une mesure relative, qui va permettre de comparer la complexité des différentes solutions d’architecture d’un système.

Vers la simplexité ?

Appliquons cette formule d’estimation de la complexité à un exemple relativement simple. Soit une application de vente de livres en ligne, avec 5 fonctions principales :

 

  • Gestion des utilisateurs (les clients, mais aussi les libraires),
  • Catalogue des livres,
  • Avis des lecteurs,
  • Gestion des achats (paniers, commandes),
  • Vitrine (interface utilisateur).

 

Les dépendances entre ces 5 fonctions principales peuvent être représentées comme cela :

 

 

Comparons la complexité d’une application monolithique, qui contient ces 5 fonctions, avec une application où chaque fonction a été partitionnée en un micro-service :

 

 

On constate que l’estimation de la complexité de l’application micro-services avec ce partitionnement maximum est presque deux fois moins élevée que celle de l’application monolithique.

 

Considérons maintenant qu’il serait logique de regrouper l’avis des lecteurs avec le catalogue des livres, soit deux fonctions dans le même module-micro-service :

 

 

Ce regroupement divise encore par deux l’estimation de la complexité ! En effet, on obtient un module-micro-service un peu plus complexe, car contenant deux fonctions au lieu d’une seule, mais on supprime une dépendance, ce qui a un impact plus fort.

Compromis, chose due

Bien sûr, nous pourrions débattre sur le postulat de départ et notamment sur la valeur 3,11 de la puissance, qui traduit l’augmentation exponentielle de la complexité selon le nombre de fonctions. Mais une chose est sûre :

 

  • la complexité du système conçu ne sera maitrisée que si l’architecte trouve un compromis entre son partitionnement en modules et la dépendance entre ces modules.

 

Thierry BIARD

 

« En mettant au premier plan l'expérience vécue et le corps en action, la simplexité est également utile pour penser un environnement mieux adapté à l'homme. »
Petit traité de cyber-psychologie de Serge Tisseron



03/07/2020
1 Poster un commentaire

A découvrir aussi


Inscrivez-vous au blog

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 388 autres membres