Architecture vs design

Quand nous évoquons que l’architecture d’un SI repose sur Kafka ou Redis, sommes-nous vraiment en train de parler architecture ? Ne parlons-nous pas plutôt de design (ou d’implémentation) ?

Cela nous est tous arrivés d’avoir la présentation d’une architecture qui ressemble à ceci :

Ce qui est intéressant est la considération différente entre le service applicatif, NginX et Apache Kafka. Pourquoi, pour le service, n’avons-nous pas le framework et le langage utilisé ? Une réponse est de dire que cette description fait partie de l’implémentation et n’a pas à être représentée. Cet argument est valide, mais dans ce cas, il s’applique également aux autres « briques » : Apache Kafka et NginX sont également des implémentations.

Revenons à ce qu’est l’architecture d’un système : c’est la combinaison de composants déployés, communiquant par des connecteurs, qui a la charge de satisfaire un ensemble d’attributs de qualité (QA) et de contraintes. Chaque composant a une responsabilité pour répondre à ces points. Arrivé à ce point, pourquoi ne pas considérer NginX, Kafka, Redis, etc. comme des composants pour représenter une architecture ? Le premier rôle de l’architecture est de présenter les principes mis en place pour répondre aux besoins et cela passe par des abstractions et non des produits. Lorsque nous abordons la partie intégration de solutions techniques, nous entrons dans la partie design du système.

Prenons le cas où nous avons comme QA une bonne disponibilité d’un service, une solution est d’avoir plusieurs instances de ce service avec en amont un load balancer. À ce stade, le point n’est pas de savoir lequel. Si un autre QA est la communication asynchrone et découplée entre services, le composant nécessaire est un pub/sub. Sur un plan purement architecture, nous obtenons cette représentation :

Et si nous voulons réduire la charge d’une base de données qui exécute souvent les mêmes requêtes, une solution est de mettre un cache :

Voici un exemple de 2 designs d’une architecture utilisant un pub/sub:

L’utilisation de REDIS est souvent intéressante, car lors d’échange, on nous dit : « Notre architecture repose sur REDIS et … ». À part que REDIS est utilisable comme :

• Base de données clé/valeur en mémoire
• Cache distribué
• Pub/Sub

Tout comme le choix du langage de programmation et du (non)framework va dépendre du contexte de l’entreprise (compétences disponibles, choix techniques, coûts), il en est de même sur le choix du design à mettre en place. Si vous avez besoin d’un pub/sub avec une charge modérée et que l’entreprise ne sait exploiter que des bases Postgres, il est contre productif, et faux, d’exiger le déploiement d’un Apache Kafka (ou autre solution technique) pour réaliser le projet. Déployer une solution non connue et l’exploiter n’est pas aussi simple que de l’installer en local sur un poste de développement et suivre le QuickStart Guide. Par contre, si des dizaines de milliers de messages par seconde doivent être gérés, vous devrez trouver un autre design et expliquer aux responsables de cette entreprise que ce QA n’est pas atteignable dans leur contexte, entraînant soit une modération du QA, soit la mise en place d’un design nécessitant des nouvelles compétences.

Un autre point : l’architecture expose les différentes responsabilités devant être prise en charge par des composants. Rien n’empêche qu’un design propose une solution dans laquelle un produit regroupe plusieurs composants. On peut choisir une API gateway qui gère la sécurité (vérification du token et des droits) et le load balancing ou bien avoir deux produits différents. Les deux designs sont différents, mais pas l’architecture. Pour les curieux, cette architecture expose le QA de centraliser le contrôle de l’accès aux services.

En résumé, quand vous définissez une architecture, ne raisonnez pas « produits / solutions techniques » mais d’abord QA et contraintes pour trouver une architecture générale. Car en prenant directement une solution technique comme base de votre architecture, vous allez être dirigés par cette solution via ses propres QA et contraintes. Par exemple, le parallélisme des clients d’un cluster Kafka va être lié à sa gestion des partitions. Cette gestion peut amener une complexité non nécessaire qui aurait été évitée avec une autre solution, voire ne pas répondre à vos contraintes. Un autre point de distinguer architecture et design est la mise en place d’une réflexion sur la mise en place d’une indépendance aux solutions techniques avec la mise en place d’adaptateurs par exemple.

---

Note: Cet article a également été publié sur le blog d’Arolla.

• QA
• Services
• Cache