Des ESBs et des nuages

La vie terrestre des ESB, aura été courte. À peine compris et apprivoisés, les voilà qui s’envolent vers d’autres cieux. En effet, depuis quelque temps, on commence à percevoir les premières initiatives d’ESB dans les nuages comme celle de la firme WSO2 avec sa plateforme Stratos ou encore celle de Savoir technologies, dans le milieu hospitalier, où la mise en place d’un ESB dans les nuages a facilité les échanges des données des patients entre les différents départements.

Dans la suite de ce billet, nous allons essayer d’analyser cette tendance émergente en revenant brièvement sur :

• Ce qu’est un ESB et les besoins des systèmes en terme d’intégration.
• Les plates-formes de cloud computing et leurs différents modèles.

Les ESB

Les tentatives pour couvrir la définition et l’utilisation des ESB ont fait couler beaucoup d’encre. Revenir brièvement sur le sujet s’avère donc un exercice très difficile. Néanmoins, on pourrait le synthétiser de la sorte (pour plus d’approfondissement, n’hésitez pas à consulter notre livre blanc sur le sujet) :

Un ESB est une plate-forme d’intégration basée sur des standards ouverts. Elle combine les fonctions d’échange de messages, de transformation, de routage et d’exposition de services, afin de permettre de relier efficacement et de coordonner les différentes composantes d’un système d’information étendu. À bien des égards, un ESB pourrait être un point de départ pour l’émergence d’une SOA orientée événement ou « Event-Driven SOA ».

Quelles motivations pourraient pousser une telle plate-forme à migrer vers les nuages ? Essayons de les appréhender en s’intéressant de plus près à ce nouvel environnement d’exécution.

Le cloud computing

Wikipedia définit le cloud computing, selon le livre blanc de notre cher SYNTEC, comme un concept se déclinant sous trois formes :

• IaaS : infrastructure as a Service. C’est le niveau le plus bas. Le fournisseur assure dans ce cas les infrastructures matérielles nécessaires à la demande et selon les besoins de scalabilité et de stockage de l’application. Le client doit prendre en charge tous les aspects OS, pile logicielle et configuration pour tirer profit de l’élasticité des infrastructures fournies. On pourra citer comme exemple Amazon EC2.
• PaaS : plate-forme as a Service, niveau intermédiaire. Le fournisseur met à disposition une pile logicielle spécifique à ses infrastructures matérielles. Il assure derrière la disponibilité de votre application en lui allouant dynamiquement les ressources nécessaires selon les variations de sa charge. Un des exemples les plus célèbres est Google App Engine
• SaaS : Software as a Service, niveau le plus haut du concept. Le client consomme le logiciel hébergé par la plate-forme sur une base de paiement par utilisation (pay per use). SalesForce a été un des pionniers de ce type de service.

Notons que le principe du « pay per use » s’applique aux différentes déclinaisons citées ci-dessus. Il représente un des avantages principaux du cloud computing. Il permet la rationalisation des coûts et l’élimination du gaspillage en exploitation, licences, …

Et comme il y a toujours un « Mais », celui du cloud computing a toujours été la sécurité des données et dans une moindre mesure le lock-in par rapport aux fournisseurs. Ce qui a donné naissance à une nouvelle variante, les clouds privés. Les entreprises désireuses de tirer profit du concept et ne voulant pas confier leurs données stratégiques à Amazon, Google et consorts, ont opté pour cette alternative. Elles gardent ainsi la main sur l’exploitation et la gouvernance de leurs infrastructures existantes tout en les mutualisant entre leurs différentes filiales.

Les premières applications à avoir été mises dans les nuages ont été les commodités telles que les solutions de stockage, les CRM, quelques modules d’ERP (par exemple l’offre Business ByDesign de SAP)…

Quels arguments pour les ESB dans les nuages ?

À la suite de ce bref tour d’horizon, deux arguments semblent se dégager en faveur d’un déploiement des ESB dans le cloud :

1. Les ESB, de par leur adoption de standards ouverts, pourraient être un jour considérés comme des commodités, ce qui en fait un bon candidat pour le cloud. Cependant, les tentatives de standardisation, telles que JBI, n’ont à ce jour pas rassemblé un nombre critique d’acteurs et l’offre actuelle du marché reste composée de solutions hétérogènes, adoptant des architectures différentes.
2. Un déploiement dans les nuages permettrait une intégration pervasive inter-SI, rendant les échanges entre les départements d’une même entreprise plus directs. Cela permet aussi de faciliter l’intégration des éventuelles nouvelles applications en mode SaaS avec le reste du parc applicatif.

Par ailleurs, porter son bus dans les nuages induira des défis différents selon si l’on choisit un cloud privé ou public. Dans le premier cas, ils seront plutôt du côté de l’exploitation traditionnellement orientée vers la gestion des bases de données, des serveurs d’applications et des serveurs web et il faudra donc se munir d’un framework approprié pour la gestion d’ESB dans son cloud privé tel que Stratos. Dans le deuxième cas, ils seront plus nombreux. On citera principalement, la sécurité, la gouvernance et l’ouverture des firewall afin de pouvoir communiquer avec une plate-forme publique externe.

Perspectives

Les ESB dans les nuages ne sont qu’à leur début et la pertinence de ce portage est loin encore de faire l’unanimité. Certaines parties affirment même que les ESB n’ont pas leur place dans le cloud. Le débat promet d’être intéressant et animé.

Références

• Le système d’information durable
• Entreprise service bus
• ESBs in the cloud: Tricky in the early going
• What’s Next for the ESB? End of the Line, or Cloud Broker
• RunMyProcess