Discussion :

[Monstros Velu]

Bonjour,

Ma problématique est pour le moment toute théorique puisque je fais de la veille et m'intéresse actuellement aux microservices, mais je n'ai pas trouvé de réponse qui me convienne.

Les microservices sont composés de blocs indépendant qui gèrent un petit ensemble d'actions/données indépendant les uns des autres. Par exemple, nous aurions un service pour les clients, un service pour les produits, et un service pour les commandes, et donc des bases indépendantes pour ces blocs.

Or, je pense que ceci ne respecte pas plusieurs règles de Codd :
- La règle d'' "indépendence d'intégrité" (règle 10/12 de Codd) spécifie que les contraintes d'intégrité doivent être stockée dans le catalogue, indépendamment des applications qui utilisent les données. Or, une commande concernant un client et des produits ne peut pas avoir ses contraintes appliquées au niveau de la base de donnée puisque les données n'existent pas dans la base.
- La règle d' "Indépendance de distribution" spécifie que peu importe comment les données sont distribuées sur les serveurs, cette organisation est invisible pour les applications qui les utilisent, de manière à pourvoir réorganiser la distribution de manière transparente. Or, avec les microservices, les règles de distribution de données me semblent figées.
- La règle de "non subversion" spécifie qu'on ne peut pas contourner le système. Or, si les règles de validation sont au niveau des micro-services, il est aisé de contourner les règles. Et si on peut contourner les règles, comment s'assurer que sa base de donnée est sécurisée... qu'on ne puisse pas y valider des commandes pour un client suspendu ou pour un produit désactivé, qu'on ne puisse pas accéder aux produits commandés par un client en outrepassant les règles d'accès...

De plus, il me semble difficile de modéliser les cas limites : Le produit préféré d'un utilisateur par catégorie de produit fait fortement référence aux produits et aux utilisateurs.

Enfin, les bases données sont optimisées pour gérer les jointures, en particulier pour les questions complexes. Ne perd-on pas toute cette optimisation en découpant le système ?

Pour moi, les microservices posent donc problème pour l'intégrité des données et pour leur sécurité... Quelles solutions existent pour palier à ces problèmes ?

[escartefigue]

L'architecture orientée services concerne les traitements, rien à voir avec la ou les bases de données sous-jacentes.
Les règles de Codd concernent les données

Si un service (un traitement donc), publié par le département "commandes clients", cherche à ajouter une ligne de commande qui pointe sur un produit non référencé dans la base produit gérée par un autre département, alors, les contraintes d'intégrité s'appliqueront, indépendamment de l'urbanisme applicatif qui a conduit à tel ou tel découpage applicatif !

[Monstros Velu]

Pourtant, les articles sur les microservices sont clairs : les données doivent être séparées et c'est le microservice "commande" qui va demander au microservice "produit" si le produit existe

les données détenues par chaque microservice sont privées et ne sont accessibles que par le biais de l’API du microservice
(source : https://docs.microsoft.com/fr-fr/dot...r-microservice)

ou

Each microservice should have its own database and should contain data relevant to that microservice itself.
(source : https://dzone.com/articles/breaking-...your-microserv )

[Waldar]

Ça fonctionne jusqu'à un certain point. Typiquement je suis confronté à une architecture microservice java qui veulent remonter des informations assez complexes depuis un entrepôt de données.
Chaque microservice lance environ 10 requêtes avec un identifiant. Les 10 requêtes répondent en 1 sec. environ.
Le problème ça reste le scaling. Les démos avec 100 identifiants sont OK, ça tourne en moins de 2 minutes.
Puis avec 4000 identifiants, ah bah oui on a dépassé l'heure de traitement.
Mais le métier au final veut 200.000+ identifiants.

Résultat ? A la poubelle les microservices.
Pourquoi en est-on arrivé là ? Lobbying des développeurs java qui pensent qu'une base de données sert à stocker et que les traitements se font dans l'application.

[Monstros Velu]

Donc les microservices, ça a l'air bien pour remplir rapidement une page web, mais s'il s'agit d'écrire des données ou de ramener beaucoup de données, on se heurte aux limites du système... C'est donc une architecture qui considère

qu'une base de données sert à stocker et que les traitements se font dans l'application

et qui ignore donc les avantages du SQL.


PS : Je marque comme résolu, vu le retour d'expérience, mais n'hésitez pas à donner d'autres exemples de pourquoi ça marche, ou pas... Merci !

[Waldar]

Ça a sa place en tant qu'API d'une IHM, ou qu'interface d'écriture depuis une application ou un flux kafka par exemple.