La semaine dernière, nous avons organisé un webcast très populaire avec Stefan Ried, analyste principal et vice-président de Forrester au service des DSI. Stefan a donné un aperçu détaillé de la recherche de Forrester sur l‘intégration basée sur cloud, les tendances du marché et il a expliqué pourquoi l‘hybride est la réalité informatique d‘aujourd‘hui et de demain. Le webcast a également présenté une vue d‘ensemble de la stratégie de Forrester en matière d‘intégration basée sur les technologies de l‘information et de la communication.
SnapLogic Integration Cloud et une séance interactive de questions-réponses sur un large éventail de sujets. Les questions et réponses ont porté sur les raisons pour lesquelles le bus de service d‘entreprise (ESB) n‘est pas bien adapté aux scénarios d‘intégration cloud , sur les avantages de la multi-location et sur les défis auxquels les technologies d‘intégration traditionnelles sont confrontées lorsqu‘elles répondent aux exigences d‘intégration modernes.
Avant la discussion, Stefan a résumé la position de SnapLogic sur le marché :
"Comme vous l‘avez vu, SnapLogic peut être à la fois une intégration dans le site cloud et une intégration avec le site cloud. Si vous voulez que Snaplex soit sur site, vous avez une gouvernance des données sur site et vous pouvez pointer vers les applications SaaS auxquelles vous voulez vous connecter. Mais si vous avez la majorité des applications dans le site cloud, vous voulez que Snaplex soit dans le site cloud. Une telle architecture est très flexible et permet de garder les deux options ouvertes."
Voici la transcription des questions-réponses :
Question : Vous avez mentionné que les ESB ne sont généralement pas multi-tenant et qu‘ils ne sont pas bien adaptés à cloud. Existe-t-il des raisons spécifiques pour lesquelles un ESB n‘est pas le bon choix pour l‘intégration ? pourquoi un ESB n‘est pas le bon choix pour l‘intégration de cloud ??
Réponse : Il y a plusieurs raisons à cela.
- L‘évolutivité d‘un ESB. Les ESB peuvent devenir très grands, comme vous avez pu le constater dans votre propre infrastructure si vous utilisez un ESB de grande taille, mais les ESB ont du mal à devenir très petits. Cela peut paraître amusant, mais ce n‘est pas le cas. Par exemple, si vous utilisez votre scénario d‘intégration basé sur cloud pour faire de l‘intégration B2B. Vous pouvez donc facilement intégrer non seulement votre système Salesforce.com à votre système ERP, mais aussi tous les partenaires de distribution de votre locataire Salesforce.com à votre système ERP. Vous pouvez réaliser une intégration de canaux très élégante de cette manière. Si vous créez un ESB pour chacun de ces partenaires et qu‘il n‘est utilisé que pour quelques messages par jour, vous gaspillez beaucoup d‘infrastructure (et de licences, soit dit en passant). Ces exemples montrent les limites des architectures ESB traditionnelles.
- Le paradigme du développement de scénarios d‘intégration complexes. Ces scénarios sont utiles si vous avez des exigences très complexes, mais si vous voulez synchroniser vos données clients NetSuite avec vos données clients SAP, ou n‘importe quel ERP que vous avez sur place, il s‘agit d‘un outil exagéré. J‘ai vu des clients qui essayaient d‘utiliser un ESB traditionnel pour ces scénarios cloud se retrouver avec des coûts beaucoup plus élevés, d‘où les compétences qu‘ils doivent acheter, même en externe, et qui apprécient vraiment l‘intégration basée sur cloud comme alternative.
Question : Pourquoi ne puis-je pas simplement faire cela avec mon middleware existant et quelle est ma recommandation pour utiliser mon middleware existant avec certains de ces nouveaux scénarios ?
Réponse : Tout d‘abord, j‘aimerais motiver et encourager tout le monde à essayer les nouvelles solutions. Non seulement parce qu‘il s‘agit d‘une conversation sponsorisée par SnapLogic, mais aussi parce que l‘intégration d‘applications traditionnelle et l‘intégration de données traditionnelle sont tout simplement trop lourdes dans de nombreux cas pour répondre aux exigences de synchronisation des données avec cloud. Cela signifie que j‘aimerais vous encourager à essayer, à trouver quels cas d‘utilisation de votre entreprise correspondent à cela et ensuite à trouver un équilibre entre l‘utilisation de votre ancien middleware et l‘extension à ces cas d‘utilisation ou l‘apprentissage de quelque chose de nouveau et l‘obtention d‘une licence pour quelque chose de nouveau. De nombreuses moyennes et grandes entreprises finissent par utiliser les deux. L‘intégration basée sur cloud n‘est donc pas un remplacement, mais un complément. Elle permet de répondre aux cas où les outils ESB ou d‘intégration de données traditionnels sont tout simplement superflus.
Question : Pouvez-vous développer votre concept de collaboration en matière de métadonnées et expliquer pourquoi les plates-formes d‘intégration cloud sont mieux adaptées que les plates-formes sur site ?
Réponse : Si vous exécutez les métadonnées dans le site cloud, vous pouvez évidemment utiliser la collaboration cloud . Par exemple, vous pouvez mettre en place une place de marché. Ou vous pouvez mettre en place des scénarios de crowdsourcing où vous pouvez simplement partager les métadonnées, qu‘elles aient été créées par un intégrateur ou un vendeur professionnel ou par l‘un de vos pairs, peut-être quelqu‘un d‘une entreprise totalement différente avec le même type de configuration ou les deux mêmes points d‘extrémité. Cela signifie que l‘on peut envisager de traiter les métadonnées comme on le ferait avec une feuille de calcul Google, par exemple. Vous pouvez facilement partager avec d‘autres personnes en temps réel. L‘ancienne façon de traiter les métadonnées dans les intergiciels traditionnels était plutôt du type Microsoft Office traditionnel, où l‘on envoyait une feuille de calcul Excel. Lorsqu‘elle arrive, elle est déjà obsolète.
C‘est ce qui fait la différence sur le site cloud. Il s‘agit d‘un travail plus collaboratif. C‘est plus partagé. Vous pouvez imaginer une place de marché et le crowdsourcing, le partage des métadonnées d‘une manière totalement différente. En fin de compte, cela réduit les coûts de mise en œuvre et rend les compétences beaucoup moins chères parce que les gens apprécient la simplicité et prennent simplement les exemples d‘autres personnes au lieu de lire des manuels volumineux ou d‘acheter les services d‘un consultant.
Question : Le mulitenancy a-t-il encore de l‘importance ? Quelles sont les raisons pour lesquelles elle est importante dans une intégration cloud plateforme ?
Réponse : Le multitenancy apporte sans aucun doute une réduction significative des coûts. Techniquement, vous pouvez réaliser beaucoup des choses dont nous avons parlé aujourd‘hui en faisant tourner une machine virtuelle dédiée sur Amazon ou ailleurs et vous pouvez techniquement réaliser la même chose. Mais il est évident que si vous avez créé une machine virtuelle dans votre propre environnement, vous ne pouvez pas faire les choses dont nous venons de parler sur le partage des métadonnées. Mais si vous avez un environnement partagé, l‘environnement peut définir que nous partageons des métadonnées ou que nous extrayons des métadonnées dans un Appstore - nous collaborons sur les métadonnées, mais nous gardons les données elles-mêmes secrètes et privées. C‘est la forme actuelle que Forrester a commencé à appeler "Collaborative Tenancy". Il s‘agit d‘être privé sur les parties qui doivent l‘être, comme vos flux de données, mais d‘être très collaboratif sur les parties qui peuvent l‘être, comme les métadonnées. Ces concepts sont évidemment très différents de ce que l‘on peut obtenir dans un environnement à locataire unique.
Enfin, j‘ai déjà mentionné l‘exemple de l‘évolutivité. Dans un environnement multi-locataires, si un locataire n‘est pas nécessaire, il s‘endort. Il n‘a plus besoin d‘infrastructure. Cela se traduit par des coûts d‘infrastructure et, potentiellement, par des prix de licence basés sur les transactions. Dans l‘ancien monde, regardez vos ESB, ils sont tous tarifés en fonction de l‘unité centrale. S‘ils sont inutilisés, ils restent chers. Tout cela est très différent.
Question : Nous avons récemment débattu de l‘héritage d‘un fournisseur de services d‘intégration. l‘héritage d‘un fournisseur d‘intégration. Comment les fournisseurs traditionnels évoluent-ils ? Peuvent-ils changer ? Qu‘est-ce qui est important sous le capot ?
Réponse : Vous ne pouvez pas modifier le logiciel de l‘architecture de base. Vous ne pouvez pas. S‘il est basé sur un environnement Java traditionnel et construit avec un modèle d‘objet traditionnel, vous ne pouvez pas le transformer en une représentation JSON. Ce n‘est tout simplement pas si facile. Cependant, les gens essaient de le faire. En fin de compte, vous pouvez évidemment servir des applications écrites dans les deux paradigmes des deux façons, mais vous n‘obtiendrez pas la performance. Cela signifie que si vous avez un trafic important, les nouveaux environnements du site cloud, donc par exemple si vous êtes une application orientée client, un ancien GS par exemple ou une application pour traiter avec vos clients qui est également connectée à Facebook et qui a des volumes de trafic imprévisibles, je pense que les nouvelles architectures de middleware comme celle de SnapLogic ont définitivement des avantages. En fin de compte, c‘est une question de coût. Il s‘agit du volume d‘infrastructure physique dont vous avez besoin pour desservir le trafic et si vous utilisez une architecture moderne, vous êtes définitivement construit pour faire face au trafic.
Consultez notre page d‘événements pour connaître les prochains programmes en ligne et en direct. Vous trouverez peut-être aussi ce billet intéressant - pourquoi la SOA est morte grâce à l‘ESB.
