SOA sans ESB

esbUn de mes clients m’a récemment poussé cette vidéo de Martin Fowler et Jim Webber sur une présentation acide sur la SOA et son outillage. Je vous partage ma vision.

En résumé, Martin et Jim attaquent là où ça fait mal: au niveau de l’agilité des processus de construction des intermédiations et sur la complexité des outils. Leur constat est (était?) le suivant:

Middleware propriétaire Technologies Web Centriques
– Non performant
– Coûteux
– Risqué
– Echelle de l’entreprise
– Spécialisé
– Intégration est une activité à part en tiers
– Design évolutif
– Delivry continue
– Pas couteux
– Incrémental
– Croix avec internet
– Intégration contrôlée par le consommateur

En un mot, ils préconisent la mise en oeuvre d’une démarche de services sans ESB car ils portent une complexité trop importante à contrario de l’approche Web. A ce propos, est-ce l’origine de la vague d’API Management actuelle ?

Bref, je comprends complètement leurs critiques. Pour être franc, j’ai moi-même connu des mastodontes tant sur leurs besoins en ressources matérielles que sur leur incapacité à évoluer. Mais…

Tirer à l’artillerie lourde sur une solution ou une technologie est toujours simpliste. Je travaille avec des développeurs AS400 qui réalisent des programmes très intéressants et performants. Ce qui nous précède n’est pas que “horreur et désolation”. Lors de cette présentation, j’ai l’impression d’entendre des développeurs NodeJS présentant des arguments contre la plateforme Java Entreprise Edition. Je vous propose de reprendre chacun de ces arguments.

Argument n°1: Non performant

Les produits ESB sont très performant lorsqu’ils sont bien utilisés. Leur capacité à monter en charge est similaire aux serveurs web classiques pour les médiations sans état. Il faut aussi comprendre que ces outils ouvrent chaque message pour les router et les transformer.

1ère interrogation: Est-ce que la démonstration prenait en compte uniquement les services avec état ? La persistance des états est effectivement consommaterice de ressources.

Argument n°2: Coûteux

Le prix est une notion très subjective. Le coût des licences est un facteur important et variable pour chaque éditeur, fonction des options, etc. Je ne pense pas que les ESB soient plus cher que d’autres produits. De manière pragmatique, des solutions open-source gratutes telles que RedHat Fuse ou WSO2 ESB existent.

2nde interrogation: Que couvre le coût indiqué dans la présentation ? Est-il global (licences, formation, montée en compétence, expertise, etc) ou sur un axe particulier ?

Argument n°3: Risqué

Le risque provient de nombreux facteurs: maturité de la solution, robustesse, compétences humaines, limites de capacité, complexité de la solution, etc.

Il existe de nombreuses solutions ESB tant matérielles que logicielles proposées en open-source ou en solutions commerciales. Les produits sans état sont plus simples à appréhender alors que les solutions avec états demandent effectivement un investissement humain et matériel plus important.

3ème interrogation: De quel(s) risque(s) s’agit-il ?

Argument n°4: Echelle de l’entreprise

Il existe 3 approches classiques pour mettre en oeuvre un ESB:

  • approche opportuniste
  • approche entreprise
  • approche spécialisée

L’approche opportuniste consiste à exposer les interfaces d’un produit avec un ESB. Les solutions comme MuleESB ou Fuse sont idéales. Ils sont petits, légers, rapides à déployer. Cependant il ne faut pas attendre plus d’un fichier de traces pour le suivi.

L’approche entreprise consiste à utiliser l’ESB comme support à une approche SOA globale avec la mise en place de règles de factorisation, d’urbanisation et d’uniformisation. Le suivi des flux est ici essentiel et nécessite donc une solution complète, robuste, protectrice et exploitable.

L’approche spécialisée consiste à dédier l’ESB à un rôle précis tel que la gestion des flux depuis l’extérieur du SI. Il facilite la gestion de la sécurité et permet des ruptures de protocoles diverses. Le niveau d’exigence dépend du SLA attendu, souvent plus faible que pour l’approche entreprise.

Réponse: Les flux de niveau Entreprise sont bien plus lents à produire car ils doivent respecter les règles communes et suivre un processus précis.

Argument n°5: Spécialisé

La connaissance d’un outil est effectivement une spécialisation technique. La connaissance d’une solution Java ou Node.JS ou JavaScript est bien une spécialisation.

Réponse: La maîtrise d’un ESB demande bien une spécialisation.

Argument n°6: Intégration est une activité à part en tiers

En général, la manipulation des outils d’intégration est réalisée par une équipe dédiée et considérée comme une activité annexe d’un projet. L’outillage étant différent, la structuration en équipe dédiée améliore la productivité. Je ne peux que vous orienter vers mon article sur l’ agilité de l’intégration pour bousculer les schémas habituels.

Réponse: Je suis tout à fait d’accord qu’utiliser un seul protocole de communication, HTTP, et un seul format, JSON, réduit les temps d’intégration. Aujourd’hui, les ERP, les AS400, les produits maisons, les DB, etc n’offrent pas cette possibilité. Il est préférable de centraliser les problématiques d’interconnexions en un point unique du SI (cf. approche opportuniste ou entreprise). L’intégration est bien une activité.

Approche incrémentale

La mise ne oeuvre d’un ESB n’est pas synonyme de rigidité et de réponse monolithique. Il est essentiel de bien classer les usages comme pour l’API Management. Les intermédiations peuvent être classées de la manière suivante:

Niveau Clients / Utilisateurs Agilité Description Contraintes
Publique 1..* Aucune Utilisation libre des Services. L’image de marque de l’entreprise est engagée. Guidé par le marketing.
Partenaire 1..* Aucune Un contrat lie les parties. La gestion du changement doit être bien maîtrisée et vérifiée. Compromis technologiques entre les entités: sécurité, facturation, suivi marketing, respect des SLA.
Entreprise 2..* Faible Plusieurs applications consomment un service mis en commun. Règles communes: nommage, sécurité, facturation, restriction, supervision.
Domaine applicatif 1..5 Moyenne Flux mis en commun dans un domaine applicatif, pour plusieurs applications. Règles du périmètre applicatif: nommage, protocole, charge.
Application 1 Forte Flux mis en jeu par une application Règles du périmètre applicatif: nommage, protocole, charge.
Jetable 1 Forte Aucune pérennité n’a été définie. Aucune

Cette organisation nécessite une approche incrémentale. Ainsi le niveau de chaque service peut évoluer et glisser vers un cadre différent et mieux adapté en fonction des usages et du succès. Le challenge est ici: accepter le refactoring !

 

Laisser un commentaire