Intégration d’applications sur le Cloud
Les entreprises qui ont fait le pari de l'externalisation ont de plus en plus d’applications sur Internet. S'ajoutant à cela la nécessité stratégique de pouvoir s’interfacer toujours plus vite avec d'autres partenaires, de nouveaux besoins d'intégration sont apparus:
- la continuité de l'information entre SI interne et Cloud (scénarios SI2Cloud et Cloud2SI)
- la continuité de l'information entre applications sur le Cloud (scénarios Cloud2Cloud)
Le besoin de continuité entre SI interne et Cloud ravive d'anciennes problématiques. Les principaux freins ont été jusque là:
- la réticence au changement (manque de confiance dans le Cloud, crainte de perdre le contrôle des données)
- le risque encouru en exposant davantage le réseau de l'entreprise (ouvertures de ports supplémentaires sur le firewall)
- le manque de visibilité des adresses IP internes depuis le Cloud (contrainte du NAT, mécanisme IPV4 de passage du réseau public au réseau privé)
Face à ces défis nouveaux et anciens, l’intégration d’applications sur le Cloud est en pleine émergence. Tâchons dans cet article d'appréhender les différentes technologies d'intégration disponibles et leurs écueils, et d'identifier les tendances pour les années à venir.
SI2Cloud & Cloud2Cloud
Les éditeurs de SaaS proposent un interfaçage plus ou moins riche avec leurs solutions. Cela va de la simple exposition de services web pour les petits éditeurs, à la couche d’intégration complète de SAP (SAP Information Interchange), en passant par le moteur de workflow de Salesforce.com. Dans de nombreux cas, ces modules d’intégration se suffisent à eux-mêmes, mais sont indissociables de la solution SaaS en question. Ils sont particulièrement appropriés pour des échanges SI2Cloud (à l'initiative du SI interne) où les contraintes de sécurité sont négligeables, puisqu'il n'est pas nécessaire d'exposer davantage l'entreprise sur le réseau public.
Des spécialistes comme RunMyProcess et Cast Iron poussent leur offre d'intégration Cloud2Cloud. L’achat d’une solution standalone et propriétaire pour couvrir ce seul scénario ne semble pas pertinente, dans la mesure où les solutions SaaS exposent et consomment déjà des services web, voire embarquent un moteur de workflow. C’est la simplicité d’utilisation de ces solutions que l’on appréciera ici, ainsi que l’outillage pour le design et le monitoring des échanges. Leur côté très démocratique et l'implémentation complète des flux par paramétrage en font plutôt des solutions SaaS.
Aucune de ces solutions SaaS ne permet de passer outre les contraintes de sécurité du SI, ni d'accéder directement aux ressources internes de l'entreprise. La problématique des échanges Cloud2SI (à l'initiative du Cloud) reste entière.
Internet Service Bus
Le concept embryonnaire d'Internet Service Bus (ISB) ne ressemble pas à un serveur d’échange classique tel qu’un EAI, un ESB ou tout autre middleware. L’ISB se situe au niveau PaaS et à pour vocation de relayer des messages sur Internet au travers de protocoles rudimentaires comme TCP et HTTP; que les échanges soient à l'initiative du Cloud ou du SI interne. C’est tout du moins la définition que je vous en propose.
La motivation première qui a conduit aux solutions Linxter ISB, Microsoft Azure AppFabric, ou encore Amazon Simple Queue Service, est la difficulté et la réticence des entreprises à ouvrir leur réseau interne, empêchant les échanges Cloud2SI. En initiant lui-même la connexion, le service lève ici les problématiques de NAT et de firewall:
Les ISB de Linxter et Microsoft sont très proches, puisque tous deux reposent sur Windows Communication Foundation. Ils permettent la négociation automatique du protocole approprié (HTTP ou TCP) et, sur le modèle des réseaux Peer2Peer, d'établir une connexion directe entre client et service. La plupart des ISB proposent également le queuing de messages.
Pour assurer la continuité entre SI et Cloud, l’ISB peut aussi être employé comme une extension du serveur d’échange interne. C’est typiquement la stratégie Software + Services de Microsoft.
Dans ce cas, c'est l'intégration native entre l'ESB et l'ISB qui permet de passer au travers du firewall et du NAT. Une seule liaison permanente et bidirectionnelle relie les deux serveurs d'échanges, permettant ainsi aux applications internes et aux applications sur le Cloud de communiquer librement.
Les ISB sont bâtis sur un modèle d’architecture distribuée à base d'API propriétaires, couplant très fortement les systèmes. En outre, là où les serveurs d'échange actuels ont atteint de très bons niveaux de maturité, les ISB sont pauvres en terme de fonctionnalités d'intégration, ce qui ne permet pas de couvrir les scénarios Cloud2Cloud:
- Pas de mécanisme de transformation
- Connectivité réduite au strict minimum
- Pas de couplage lâche producteur/consommateur
Integration as usual
Les fonctionnalités nécessaires à l’intégration d’applications Cloud2Cloud sont peu ou prou les mêmes qu’à l’intérieur de l’entreprise: la connectivité technique, le mapping de données, les différents patterns d’échange, etc. Pourquoi alors ne pas héberger son ESB de prédilection directement sur une plateforme d'IaaS comme Amazon Virtual Private Cloud ?
Par ailleurs l'arrivée progressive de l'IPV6 ne bouleversera pas la manière de gérer la sécurité dans les DSI. Celles-ci seront toujours aussi réticentes à s'exposer sur le réseau public. Quelle que soit la technologie retenue, un pont logiciel prenant la forme d'un flux technique générique s'avère nécessaire entre plateforme d'intégration interne et externe. L'approche ESB prend tout son sens au travers d'une architecture hybride de ce type:
Il faut interfacer un nombre critique d’applications sur le Cloud pour justifier d’une telle architecture. La charge de travail sur un ESB et le traffic réseau étant relativement constants - au moins étalés - l’approche IaaS pourrait être économiquement peu avantageuse. C'est pourtant à mon sens la seule solution qui couvre aujourd'hui tous les scénarios Cloud2SI, SI2Cloud et Cloud2Cloud. Cette approche présente un autre avantage de taille: offrir une bonne évolutivité en cas d'externalisation et de rapatriement de services applicatifs.
Et pour demain
La notion d’ISB reste à préciser. Fort est à parier que les éditeurs ne tarderont pas à se positionner davantage sur ce segment; mais probablement pas sur ce modèle de connecteurs propriétaires qui va à l’encontre de l’esprit même du Cloud Computing. L’ISB a un rôle essentiel dans l’Internet des Objets, où l’un des enjeux est de structurer un très grand nombre d’échanges de données, depuis et vers le Cloud. Au lieu d'API propriétaires les ISB devraient reposer uniquement sur des standards, qui restent à définir. Pour convaincre les entreprises et toucher l’informatique de gestion, les ISB devront s'enrichir de nouvelles fonctionnalités. L’approche IaaS semble pour l'instant plus pérenne. Faut-il alors attendre plusieurs années pour que les éditeurs d’ISB fournissent les mêmes fonctionnalités que les ESB conventionnels ? Il convient de choisir sa solution d’intégration en prenant en compte les scénarios d'intégration SI2Cloud, Cloud2SI ou Cloud2Cloud présents et à venir, la nature des applications à interfacer (SaaS, PaaS ou IaaS), et la maturité de l’entreprise en termes d’architecture d’échange.