Microservices et procédures stockées

Les procédures stockées sont-elles considérées comme une mauvaise pratique dans une architecture de microservice?

Voici mes pensées:

• la plupart des livres sur microservices recommandent une base de données par microservice. Les procédures stockées fonctionnent généralement sur une base de données monolithique.

• Là encore, la plupart des ouvrages sur l’architecture de microservices indiquent qu’ils devraient être autonomes et couplés de manière lâche. L'utilisation de procédures stockées écrites, notamment dans Oracle, associe étroitement le microservice à cette technologie.

• la plupart des ouvrages sur l'architecture de microservices (que j'ai lus) recommandent que les microservices soient orientés métier (conçus à l'aide de la conception pilotée par domaine (DDD)). En déplaçant la logique métier dans les procédures stockées de la base de données, ce n'est plus le cas.

Des idées à ce sujet?

Rien n'interdit explicitement l'utilisation de procédures stockées avec des microservices ou ne conteste.

Clause de non-responsabilité: je n'aime pas les procédures stockées dans le POV d'un développeur, mais cela n'a aucun rapport avec les microservices.

Les procédures stockées fonctionnent généralement sur une base de données monolithique.

Je pense que vous succombez à une erreur logique.

Les procédures stockées sont en déclin de nos jours. La plupart des procédures stockées en cours d'utilisation proviennent d'une base de code plus ancienne conservée. À l'époque, les bases de données monolithiques étaient également beaucoup plus répandues que lorsque les microservices sont devenus populaires.

Les procédures stockées et les bases de données monolithiques se trouvent toutes deux dans d'anciennes bases de code. C'est pourquoi vous les voyez plus souvent ensemble. Mais ce n'est pas un lien de causalité. Vous n'utilisez pas de procs stockés parce que vous avez une base de données monololithique. Vous n'avez pas de base de données monolithique parce que vous utilisez des procs stockées.

la plupart des livres sur microservices recommandent une base de données par microservice.

Il n'y a aucune raison technique pour laquelle ces petites bases de données ne peuvent pas avoir de procédures stockées.

Comme je l'ai mentionné, je n'aime pas les procs stockés. Je les trouve encombrants et résistants à la maintenance future. Je pense effectivement que la diffusion de sprocs sur de nombreuses petites bases de données exacerbe les problèmes que je n'aime pas déjà. Mais cela ne signifie pas que cela ne peut pas être fait.

Là encore, la plupart des ouvrages sur l’architecture de microservices indiquent qu’ils devraient être autonomes et couplés de manière lâche. En utilisant des procédures stockées écrites spécifiquement dans Oracle, associe étroitement le microservice à cette technologie.

De l’autre côté, le même argument peut être avancé pour tout ORM utilisé par votre microservice. Tous les ORM ne prendront pas en charge chaque base de données non plus. Le couplage (en particulier son étanchéité) est un concept relatif. C'est une question d'être aussi lâche que possible.

Les sprocs souffrent généralement d'un couplage étroit, indépendamment des microservices. Je conseillerais contre les sprocs en général, mais pas particulièrement parce que vous utilisez des microservices. C'est le même argument que précédemment: je ne pense pas que les sprocs soient la voie à suivre (en général), mais cela pourrait bien être mon parti pris, et cela ne concerne pas les microservices.

la plupart des livres de msa (que j'ai lus) recommandent que les microservices soient axés sur les entreprises (conçus avec ddd). En déplaçant la logique métier dans les procédures stockées de la base de données, ce n'est plus le cas.

Cela a toujours été mon principal reproche pour les sprocs: la logique métier dans la base de données. Même si ce n’est pas l’intention, cela tend toujours à se terminer ainsi.

Mais encore une fois, ce reproche existe, que vous utilisiez ou non des microservices. La seule raison pour laquelle cela semble être un problème plus important tient au fait que les microservices vous poussent à moderniser votre architecture dans son ensemble, et que les sprocs ne sont plus privilégiés dans les architectures modernes.

Pour écrire un logiciel, vous devez être étroitement associé à une technologie.

Au minimum, à l'environnement d'exécution fourni par le langage de programmation en cours de développement.

Plus généralement, vous constaterez que votre micro-service est étroitement associé à plusieurs technologies:

• Network Service Framework pour fournir des implémentations de protocole HTTP / SSL / SOAP de haut niveau
• Repository / ORM / DAO Framework pour assurer la persistance.
• Cadres de manipulation de données pour fournir des outils permettant de travailler avec des données.
• Process / Threading / Framework OS pour fournir un accès aux ressources du système d'exploitation telles que le multitâche, le système de fichiers, la mémoire, le calcul GPU, les cartes d'extension, etc.

Et c’est faire un micro-service simple.

Procédures stockées

Une procédure stockée est simplement une autre technologie que vous pouvez choisir d'utiliser ou de ne pas utiliser. Comme par magie, votre code n'est pas monolithique ni micro.

Qu'est-ce que c'est cependant:

• Une autre technologie. Chaque technologie présente dans l’application réduit les chances d’un programmeur donné de lire, de comprendre et de faire des choix de conception judicieux pour cette combinaison de technologies.
• Un langage utilisant un paradigme de programmation différent. Il est beaucoup trop facile pour des non-experts d’essayer d’imposer leur propre perspective impérative, fonctionnelle, orientée objet, etc., ce qui conduit souvent à des résultats moins que brillants.
• Une API. Ce qui doit être maintenu comme toute autre classe de la base de code. Cela signifie également que la base de données fournit une interface non générique. Cela rend plus difficile à la fois le remplacement du moteur de base de données et l'application transparente d'un comportement générique, tel que la mise en cache de la mémoire.
• Un artefact. Ce qui doit être versionné, testé et déployé. Cela peut être fait, mais les bases de données sont des artefacts vivants nécessitant une approche différente. Vous ne pouvez généralement pas simplement supprimer l'original et le remplacer. Souvent, une orchestration minutieuse des modifications au fil du temps est nécessaire pour migrer le système vers l'état souhaité.

Chacun de ceux-ci est un coût réel. Dans certains cas, le coût est justifiable, dans d'autres ce n'est pas le cas.

Vous paieriez presque le même ensemble de coûts en hébergeant un moteur de script. La seule réduction est que vous pouvez choisir le même paradigme de programmation que le langage hôte.

Logique d'entreprise

Déplacer des règles métier dans la base de données est une mauvaise pratique. Juste pas à cause des procédures stockées.

C'est une mauvaise pratique, car la base de données et la logique métier opèrent à différents niveaux de cisaillement.

• Une base de données dans une application mature peut être utilisée pendant des décennies. Généralement, le moteur est mis à jour périodiquement sur ces systèmes, mais la base de données elle-même a été migrée. Il n'a pas été tué et reconstruit depuis le début. Il n'y a aucune raison pour qu'un micro-service ne puisse être vécu aussi longtemps.

• Contrastez des décennies avec la rapidité avec laquelle les règles commerciales changent. D'après mon expérience, une vieille règle de gestion date peut-être de quelques années. La plupart d'entre elles changent rapidement, mais on ne peut jamais dire quelle sera la prochaine. Une nouvelle exigence émanant d'un organisme de réglementation, un ancien produit en cours de déclassement, des modifications du en-tête de lettre, des modifications du nombre d'employés relevant du supérieur hiérarchique, etc., etc., etc.

Si la logique métier est répartie sur les couches de cisaillement, en particulier dans une couche dont la durée de vie est plus longue et plus lente, elle générera une résistance au changement. Ce n'est pas forcément une mauvaise chose. Après tout, la seule base de données ne contenant aucune logique métier est un triple magasin.

Le simple fait de spécifier un schéma de table déplace la logique métier dans la base de données.

Architecture

Vous vous battez pour utiliser l'outil approprié au problème en question, sans avoir besoin de trop d'outils, ni de le rendre trop difficile à résoudre, pour créer et maintenir une solution.

Ce n'est pas facile

Mais imaginons l'impensable, comment maintiendriez-vous une logique métier répartie dans plusieurs langues?

• Un catalogue ... afin que chaque implémentation de règle de gestion puisse être suivie et maintenue.
• Des tests ... pouvant être utilisés pour chaque règle de gestion, peu importe où et comment elle a été mise en œuvre.
• Une implémentation de référence .. de sorte que, lorsque des divergences sont trouvées, une source de vérité existe (ou au moins une source de débat).

Mais cela a aussi un coût.

• Est-il préférable d'autoriser les règles métier à avoir plusieurs implémentations? Chacun peut tirer parti des compétences de l’équipe et des dispositions-cadres, mais nécessite des contrôles de qualité rigoureux pour éviter de nombreux petits aléas?
• Ou vaut-il mieux avoir une seule source de vérité, écrite dans une seule langue? Peut-être moins cher à mettre en œuvre, mais aussi une source unique d'échec, elle-même un composant monolithique qui résiste au changement face à différentes plates-formes, cadres ou outils à inventer?

Avant de commencer ma réponse, je dirai que je maintiens quelques microservices utilisant des procédures stockées. De plus, j'ai écrit beaucoup de procédures stockées à différents moments de ma carrière et je suis absolument d'accord pour dire que les choses peuvent mal tourner si elles ne sont pas utilisées correctement.

Donc, la réponse courte est non, les procédures stockées ne sont pas intrinsèquement mauvaises dans une architecture de microservice. Mais vous devez comprendre:

1. Vous ajoutez des obstacles à la substitution des moteurs de stockage. Si certaines caractéristiques opérationnelles ou de performance ou les limitations de fonctionnalités vous obligent à changer de moteur de stockage, le coût sera plus élevé car vous allez écrire et tester de nombreux nouveaux codes. L'exécution de plusieurs moteurs de stockage (au cours d'une phase de migration ou pour isoler des activités en fonction des besoins de performances) peut entraîner des problèmes de cohérence, sauf si vous utilisez la validation en deux phases (2PC), qui présente elle-même des problèmes de performances.
2. Vous avez une autre API à gérer, ce qui signifie que vos dépendances peuvent être rompues. L'ajout, la suppression ou la modification des types de paramètres dans les procédures peut endommager le code existant. La même chose se produit avec les tables et les requêtes, mais vos outils peuvent être moins utiles pour localiser les problèmes éventuels. Les problèmes avec les procédures stockées sont généralement rencontrés au moment de l'exécution, très tard dans le processus de développement / déploiement.
3. Vos autorisations de base de données sont devenues plus compliquées. Une procédure est-elle exécutée en tant qu'utilisateur connecté ou sous un autre rôle? Vous devez réfléchir à cela et le gérer (de manière automatisée, de manière automatisée).
4. Vous devez pouvoir migrer vers les nouvelles versions en toute sécurité. Souvent, une procédure doit être supprimée et recréée. Encore une fois, les autorisations peuvent vous causer des problèmes.
5. L'annulation d'une migration échouée peut signifier un effort supplémentaire. Lorsque l'environnement de production est séparé des développeurs, les choses deviennent encore plus difficiles.

Voici quelques utilisations de procédures stockées qui, à mon avis, en valent souvent la peine:

1. Application de l'historique d'édition (journaux d'audit). Les déclencheurs sont couramment utilisés à cette fin, et les déclencheurs sont des procédures stockées. Dans certaines bases de données, il est également possible d’interdire entièrement les insertions et les mises à jour pour le rôle d’application: les clients exécutent des procédures exécutées sous un rôle différent avec les autorisations appropriées et qui appliquent tous les comportements nécessaires.
2. Extension des contraintes de vérification. Cela pourrait vous faire entrer dans le champ de la logique métier, mais dans certains cas, les outils de contrainte intégrés à une base de données pourraient ne pas suffire à vos besoins. Souvent, le code impératif est le meilleur moyen d’exprimer des chèques. Vous risquez de laisser entrer de mauvaises données si vous dépendez de votre application pour le faire à votre place.
3. Encapsulation de requêtes complexes lorsqu'une vue est inappropriée ou trop compliquée. J'ai vu quelques cas où une vue correcte nécessite du code SQL extrêmement complexe qui peut être exprimé de manière beaucoup plus compréhensible dans une procédure stockée. C'est probablement rare, mais cela se produit.

En général, je vous suggère d'essayer les points de vue en premier et de ne recourir aux procédures que lorsque cela est nécessaire. Des vues bien conçues peuvent en réalité fonctionner en tant qu'API, en résumant les détails de la manière dont les tables sous-jacentes sont interrogées. L'augmentation de votre API (vues) avec des procédures stockées est logique dans certaines circonstances. Il est même possible d'émettre du JSON directement à partir d'une requête SQL, en contournant tout le gâchis des données de mappage des résultats de la requête au modèle de données de votre application. Déterminez si c'est une bonne idée en fonction de vos propres besoins.

Étant donné que vous devriez déjà gérer vos ressources de base de données (schéma, autorisations, etc.) via un outil automatisé, non, les procédures stockées ne sont pas intrinsèquement mauvaises pour les microservices.

Les procédures stockées sont des détails de mise en œuvre. Les fonctions de base de données, les lambdas ou un script shell stocké quelque part dans le système de fichiers sont tous des détails d'implémentation et sont sans intérêt pour l'architecture.

la plupart des livres sur microservices recommandent une base de données par microservice.

Ok, nous pouvons donc coder les procédures stockées dans ces bases de données.

encore une fois, la plupart des livres d’architecture de microservices indiquent qu’ils devraient être autonomes et couplés de manière lâche

Entre les capacités de l'entreprise, les cycles de vie du développement, la gestion, les déploiements, les emplacements des équipes, etc. Rien à voir avec les détails de la mise en œuvre. Les microservices ne résolvent pas un problème technique (au contraire). Ils viennent résoudre les problèmes de gestion et de time-to-market. C'est une stratégie, pas une tactique. Un moyen d'échec rapide avec le moins de coûts possible. S'il s'avère que certaines fonctionnalités de l'entreprise ne servent à rien, nous les abandonnons sans compromettre les autres fonctionnalités, déploiements, gestion de projets, versions ...

Notez que la "scission" agit déjà comme un agent de découplage. Supposons que nous ayons deux services, A est pris en charge par Oracle et B par MongoDB. Si nous ne respectons pas la règle d'or du découplage, il devrait être possible d'abandonner A + Oracle avec des effets secondaires négligeables sur B.

En utilisant des procédures stockées écrites spécifiquement dans Oracle, associe étroitement le microservice à cette technologie.

Cela pourrait causer un blocage du vendeur. Souvent, le fournisseur est imposé par l'entreprise pour des raisons historiques ou contractuelles ¹ . Il est important de savoir comment ne pas verrouiller notre code au fournisseur. Par exemple, certains ORM et certains frameworks implémentent un nouveau langage de requête qui masque les fonctions et fonctionnalités intégrées à la base de données.

Bien que, si nos services sont suffisamment micro-économiques, le blocage des fournisseurs n’est plus un problème car il n’impacte qu’une petite partie de l’ensemble. Une petite pièce qui devrait pouvoir être remplacée (ou isolée) rapidement.

la plupart des livres de MSA (que j'ai lus) recommandent que les microservices soient orientés métier (conçus avec DDD).

Il devrait être axé sur les entreprises et voici la chose. Toutes les entreprises ne profitent pas de DDD. DDD et microservices se chevauchent sur de nombreux points, mais ils ne sont pas une cause à effet. Nous pourrions nous retrouver avec un écosystème de microservices composé de services anémiques. Ou composé d’un mélange des deux: services mettant en œuvre un domaine complexe et services anémiques produisant des POJO directement à partir de la base de données. Il n'y a rien de mal à ça.

En ce qui concerne les livres, ils se concentrent uniquement sur l'exécution de la stratégie. La tactique - comment tirer parti de l’informatique distribuée - comment la faire fonctionner avec succès, mais elle est (généralement) agnostique vis-à-vis de la stratégie. Les stratégies varient d'une entreprise à l'autre et dépendent rarement des développeurs. Il nous reste donc à extrapoler et adapter ce que les livres disent à nos besoins, exigences et contraintes spécifiques. L'objectif est de rendre la stratégie commerciale rentable et durable.

Gardez toujours à l'esprit que toute architecture est un moyen d'atteindre un but. Les règles de l'entreprise. Nous ne construisons pas d'écosystèmes de microservices pour la mode ou pour l'amour de l'art.

Cela n'a rien à voir avec les microservices.

Les procédures stockées peuvent avoir un sens si votre service dispose d'une architecture en couches «à l'ancienne» dans laquelle la base de données constitue la base du service, avec les couches d'accès aux données et de logique métier au-dessus. L’interface entre le service et la base de données dans une telle architecture est très spécifique aux détails les plus internes du service. En règle générale, il existe des adaptateurs spécifiques au service pour chaque type de base de données prise en charge, et la spécificité de l'API exposée par l'adaptateur permet d'utiliser des procédures stockées dans les couches sous-jacentes.

Il y a beaucoup de problèmes avec les architectures comme ça. Plus important encore, il est très difficile de réaliser la logique d'un test unitaire. Ces architectures ne sont plus en faveur.

Si vous utilisez une "architecture propre", une "architecture d'oignon" ou un style similaire, la base de données sera alors une dépendance injectée , spécifiée dans les couches externes. Comme elle est définie dans les couches externes, l'interface fournie pour la base de données doit être générique . Il ne peut pas refléter les détails les plus internes du service, car ceux-ci doivent être cachés des couches les plus externes de l'architecture. Définir une interface de procédure stockée générique pouvant fonctionner avec n'importe quel harnais de test de base de données ou d'unité est incroyablement difficile et n'est pas vraiment nécessaire. Par conséquent, les procédures stockées ne sont pas pratiques dans ce type d'architecture.

La relation avec les microservices est simplement que les microservices sont nouveaux et ascendants - nous ne faisons plus de monolithes - et que ces nouveaux styles architecturaux sont également ascendants - nous ne faisons plus de couches plates.