ESB : Enterprise Spaghetti Bus ?

Lors d’une récente séance de brainstorming avec plusieurs de mes collègues français et hollandais, un intéressant concept a émergé : celui de l’Enterprise Spaghetti Bus. Je vous en fait part, je suis sûr que vous aurez l’occasion de le replacer…

Le concept du plat de spaghetti est familier à quiconque a eu l’occasion de travailler sur des architectures distribuées à grande échelle (ou à petite échelle d’ailleurs). Le principe en est simple : à force de multiplier les interactions point-à-point entre des composants ou systèmes hétéroclites, on tisse une véritable toile de dépendances croisées qui, à une vitesse surprenante, conduit l’ensemble du système à la sclérose. Faire évoluer un composant (ou service) devient une tâche impossible, impactant un nombre croissant (et souvent inconnu) de systèmes tiers qui en sont les clients et, du coup, les victimes.

Le schéma suivant résume l’idée :

En règle générale, on cherche donc, lorsque l’on conçoit une architecture distribuée, à adhérer au paradigme ravioli plutôt qu’à celui spaghetti. Dans l’architecture ravioli, chaque composant est petit, et faiblement couplé aux autres ; il encapsule de la viande et d’autres aliments pour le système ; on peut enlever ou changer un raviolo (oui, au singulier, c’est raviolo, ne serait-ce que pour faire plaisir à une charmante italienne de ma connaissance) sans impacter les autres ravioli. A l’occasion, je vous parlerai plus en détail de la Théorie Générale des Pâtes Appliquée au Génie Logiciel (Pasta Theory on Software, en anglais)…

Pour revenir aux problèmes d’architecture, les ESB sont à première vue un moyen simple de s’affranchir du modèle point-à-point au profit du modèle spoke-hub, en d’autres termes de transformer à peu de frais votre plat de spaghetti en plat de ravioli. Le schéma suivant illustre cette évolution :

Présenté de la sorte, l’ESB fait figure de composant magique. Mais cette vision – que certains n’hésitent pas à exploiter sans vergogne dans leurs arguments commerciaux – néglige la nature duale du couplage dans une architecture distribuée.

En effet, lorsque deux composants (ou systèmes ou services ou applications) établissent une communication point-à-point, ils établissent une dépendance à deux niveaux :

• au niveau technique : les deux systèmes doivent trouver un protocole de communication partagé – et ceci est vrai quelle que soit la sémantique d’échange, synchrone ou asynchrone
• au niveau fonctionnel : les deux systèmes doivent s’entendre sur un format d’échange

Appliqué tel quel, un ESB ne fait que résoudre la problématique de couplage au niveau technique – et c’est rarement le niveau le plus critique (les protocoles de remoting ne changent qu’exceptionnellement, et leurs évolutions assurent le plus souvent la rétrocompatibilité).

Si le couplage fonctionnel n’est pas pris en compte, l’ESB ne fait que déplacer le problème – et nous obtenons notre fameux Enterprise Spaghetti Bus :

D’aucuns prétendront que cette situation est préférable, puisqu’elle permet de gérer la complexité en un point unique, et d’utiliser les services de transformation offerts par l’ESB pour gérer les évolutions dans les formats déchange ; l’argument est probablement recevable sur le court terme, tant que le nombre de services et de versions permet une combinatoire de taille raisonnable. Mais il ne fait aucun doute que rapidement, cette combinatoire va exploser – et avec elle le coût d’évolution de chaque service.

La parade à l’Enterprise Spaghetti Bus existe : elle consiste à définir un format pivot, ou modèle canonique, auquel se conforme les producteurs et consommateurs de services. La mise en conformité – c’est-à-dire la conversion du format de données interne dans le format canonique – peut être réalisée par chaque sous-système, ou par l’ESB (la première solution a ma préférence, mais ce n’est pas le sujet du moment). Chaque composant est désormais uniquement couplé au modèle canonique, et la figure rassurante du plat de ravioli semble de nouveau à portée de main.

Reste un problème épineux auquel tous ceux qui tentent de mettre en place une architecture orientée services sont potentiellement confrontés : qui définit et maintient le (ou les) modèle(s) canonique(s) ? Les apôtres de l’urbanisation bureaucratique et de la gouvernance centralisée tendent à promouvoir un long et coûteux travail de modélisation transverse en amont. Je crois cette approche fondamentalement erronée : au mieux, elle risque d’aboutir à un report sans fin de la mise en oeuvre ; au pire, elle conduit à la mise en place d’un modèle rigide, excessivement complexe, mal adapté aux besoins réels des applications et hermétique au changement. Incrémentaliste convaincu, je crois au contraire que le modèle canonique doit être construit de façon progressive et collaborative, en prenant en compte les besoins à mesure qu’ils se présentent ; cela suppose que l’architecture intègre les évolutions du modèle canonique – faute de quoi le problème, une nouvelle fois, aura juste été déplacé. Il doit donc être possible de refactorer le modèle canonique – une opération que les ESB, précisément, rendent possible. Mais ceci est une autre histoire…