Architecture des services de persistance, état de l’offre

Sous ce titre pompeux se cache la question que se posent nos architectes d’applications et nos clients quand il s’agit de déterminer quelle technologie employer pour rendre les données persistantes : bases de données relationnelles, ORM, base de données orientées document, etc. Si le problème est devenu vaste c’est que l’offre a récemment été bouleversée par l’entrée en scène de l’initiative NoSQL avec des plateformes crédibles. En évoquant ce vocable, cet article a aussi la prétention de battre en brèche quelques idées reçues.

N’attendez pas de ma part un guide méthodologique exhaustif et une matrice de choix de technologie. L’architecture des systèmes d’information reste un art plus qu’une science et dans ce domaine, rien ne remplace une solide analyse métier. Tout au plus ai-je l’ambition de vous aider à y voir plus clair.

Les bases de données traditionnelles

Présents depuis 30 ans dans les systèmes d’informations, incontournables jusqu’au début des années 2000, les SGDBR restent la solution de choix par défaut lorsqu’un projet de développement qui voit le jour requiert une solution de persistance des données. On rappellera pour mémoire les avantages inhérents aux SGDBR : le SQL comme langage uniforme et le support de l’intégrité et de la cohérence par les transactions.

Il faut noter que si l’offre SGDBR s’est diversifiée avec l’entrée en scène des acteurs Open Source (PostgreSQL, MySQL et leurs forks respectifs), elle a aussi gagné en maturité avec le support de la haute disponibilité, du calcul réparti et des interfaces hybrides (Objet/Relationnel, Structuré/Non-Structuré), néanmoins, ces aspects restent peu appliqués en pratique par les architectes.

Les nouvelles interfaces

Le frein à l’adoption des fonctionnalités hybrides offertes par les SGBDR vient du fait que les technologies des tiers architecturaux ont évolué indépendamment. De ce fait, l’interface Objet-Relationnel est devenue plus difficile à mettre en œuvre et, surtout, à réutiliser. La désaffection des développeurs pour le SQL et les L4G hôtes (PL/SQL, T-SQL) a fait le reste. Néanmoins, vue de mon côté d’expert, les bases de données n’ont jamais proposé autant de protocoles d’interface différents. Même si les protocoles natifs tiennent le haut du pavé, les avantages de l’échange de données en format XML n’est plus à démonter pour assurer le couplage le plus faible possible entre deux tiers architecturaux.

D’un autre côté, les ORM (Object/Relational Mapper) ont eux aussi gagné en maturité et permettent maintenant d’assurer l’intégration continue du tiers de persistance. Cependant, ils gardent leur inconvénient essentiel d’être totalement sourds aux spécificités du SGBD supporté. En clair, il reste difficile de leur faire accepter certaines fonctionnalités SQL. Tout cela en vertu du principe d’indépendance (pourvoir changer de SGBD) qui est et restera un mythe, du moins pour les applications data-centriques.

L’initiative NoSQL

NoSQL qu’il faut comprendre comme Not Only SQL (en non No SQL comme je l’entends parfois) est une initiative de quelques architectes de grands groupes (Yahoo, LinkedIn) de publier dans le domaine public le code source des systèmes de base de données non relationnelle en service chez leurs employeurs respectifs (et avec l’accord de ces derniers).

Après presque 5 ans d’existence pour les systèmes les plus anciens se réclamant de cette initiative, l’offre NoSQL semble plus complète et plus mature. Néanmoins, il reste, à mon avis, du chemin à faire pour faire émerger un langage standard d’interrogation. La grande force de ces produits est d’avoir vaincu par le pragmatisme l’idéologie de l’intégrité des données à tout prix. Se passer de transaction et fournir une disponibilité constante et une forte tolérance aux pannes, voilà le principal apport de l’initiative NoSQL.

Bien entendu, il est des domaines où l’intégrité des données n’est pas un dogme mais une contrainte effective à satisfaire. Mais là encore, il convient d’être pragmatique et de choisir la bonne technologie.

Quelle technologie pour quelle représentation des données ?

On en revient à la question existentielle évoquée en début d’article. Il n’y a naturellement pas de réponse toute faite car une telle réponse serait indiscutablement dogmatique. L’architecte en systèmes d’information recherche avant tout la satisfaction de contraintes objectives dans un souci d’harmonie technologique. Ce sont ces contraintes, raffinées en leurs composantes de plus haut niveau, qui vont guider nos choix technologiques.

La première contrainte est celle de la représentation structurée ou non des données. La représentation structurée obéit à la règle une entité = un schéma. Son expression serait celle d’un langage à typage statique. A l’opposé, la représentation dynamique des données autorise à avoir plusieurs ensembles d’attributs différents pour une même entité. L’avantage de la représentation structurée vient du contrôle qu’elle garantit sur le typage des entités ce qui peut être un inconvénient pour les projets actuels basés sur l’intégration continue et l’agilité de la réponse aux nouvelles spécifications. D’un autre côté, si la représentation non-structurée permet un tel dynamisme, les fonctions de vérification de la conformité deviennent une part importante de l’effort d’implémentation.

La seconde contrainte porte sur le respect du Théorème de Brewer-Lynch-Gilbert plus communément appelé Théorème CAP. Ce théorème énonce simplement ce que les acteurs de l’initiative NoSQL avaient empiriquement constaté : Pour un réseau de données distribuées, il est impossible de garantir à la fois que chaque nœud accède à la même vue des données (Consistency), que la perte d’un nœud du réseau n’empêche pas le système de répondre aux requêtes (Availability) et, enfin, que la perte d’une partie du réseau n’empêche pas le système de répondre aux requêtes (Partition Tolerance).

Au risque de paraître vouloir enfoncer des portes ouvertes, je rappellerais que ces problématiques de données distribuées sont largement prégnantes dans les systèmes d’information actuels. Et que la réponse des architectes se doit d’être précise et adaptée à chaque cas d’espèce.

L’approche architecturale de la persistance

Comme je l’ai indiqué en introduction, cet article a pour but de battre en brèche certaines idées reçues. La première est celle de la nécessaire uniformité des solutions de persistance.

Admettons qu’un logiciel complexe doive à la fois permettre le support transactionnel pour assurer que des invariants soient respectés, être résilient au morcellement du réseau et favoriser l’emploi de types non-structurés. Tout cela en assurant la persistance de 30 Go de données par mois sous une charge moyenne de 5000 utilisateurs.

Il serait tentant de choisir une base de données en cluster Oracle 11g couplée à un ESB (Entreprise Service Bus) et exposant des Web Services. Mais cette architecture ne pourrait certainement pas évoluer pour proposer une application pour terminaux nomades en raison de sa tolérance imparfaite au morcellement du réseau. Sans compter qu’une telle architecture aurait un prix que seules les organisations dotées en capacités financières et en compétences pourraient se permettre de soutenir.

A la place, une architecture basée sur le même ESB et offrant un découplage entre deux systèmes de persistance, l’un transactionnel, de back-office et d’archivage et l’autre, non-transactionnel, opérationnel, de front-office, assurerait, au prix d’un composant de réconciliation, un service adapté aux spécifications et évolutif face aux nouvelles exigences de mobilité. C’est d’ailleurs une conséquence de l’approche SOA de proposer ce type de découplage technologique.

La seconde idée reçue est la nécessaire complexité des systèmes de persistance. Sans entrer dans la polémique du rejet du SQL par les développeurs orientés-objets qui peut se résoudre par un effort de formation et d’évangélisation adapté, la mise en œuvre de systèmes de gestion de données non-structurées ou d’API de transformation permet de limiter la complexité technologie aux tiers concernés. Développeurs de base de données et développeurs de services applicatifs ne parleraient que le langage commun du contrat d’interface au lieu de s’ignorer mutuellement voire de se combattre (technologiquement parlant, j’entends).

Pour conclure cet article, je conseillerais à tous, donneurs d’ordres, architectes et développeurs de garder à l’esprit qu’une bonne solution est une solution qui fonctionne et qui est optimisée sur la base des contraintes de son environnement humain et technologique. Alors, soyez pragmatiques et observateurs, soyez curieux et imaginatifs et l’innovation architecturale sera à votre portée.