Cet article a été initialement publié sur le blog de Glenn Donovon.
J'ai récemment décidé de m'intéresser de près à cloud iPaaS (intégration plateforme en tant que service) et, en particulier, à SnapLogic, parce qu'un de mes bons amis s'est joint à eux pour participer à la mise en place de leur programme de comptes nominatifs. Il s'agit d'un site plateforme intéressant qui, à mon avis, a le potentiel d'aider l'informatique à franchir le " dernier kilomètre " de la mise en place de cloud dans l'entreprise, non seulement en raison de ses fonctionnalités, mais aussi en raison de l'évolution de l'ingénierie et de la conception logicielles qui a commencé dans des endroits comme Google, Amazon et Netflix - et dans les startups qui ne pouvaient pas se permettre une " pile technologique d'entreprise " - et qui fait maintenant son chemin dans l'entreprise.
Cependant, en discutant avec mon ami, il est devenu clair qu'il faut comprendre l'histoire des serveurs d'intégration, des intergiciels EAI, des normes SOA, ESB et WS pour mettre en contexte les leçons qui ont été tirées en cours de route en ce qui concerne l'agilité réelle de l'informatique. Mais permettez-moi de m'expliquer avant d'entrer dans le vif du sujet. Mon point de vue est basé sur le fait que j'ai été représentant en technologie d'entreprise et que j'ai vendu des intergiciels à faible latence, des intergiciels basés sur des normes, des intergiciels EAI, un bus de messagerie en grille SOA ainsi que des applications telles que le CRM, le BPM et la gestion des risques de marché/crédit à l'échelle de l'entreprise, qui ont des exigences massives en matière d'intégration des systèmes. Bien que j'aie fait un peu d'université et de codage dans ma vie (j'ai été consultant en bases de données pour de petites entreprises pendant un certain temps), je ne suis pas un architecte, ni un codeur, ni même un analyste de systèmes. J'ai vu de près et personnellement pourquoi ces technologies ont été achetées, comment elles ont évolué au fil du temps, ce que les clients en ont retiré et comment tous nos plans et aspirations se sont concrétisés. J'essaie donc d'élaborer un récit qui relie les points pour les personnes autres que les développeurs d'intergiciels et les directeurs techniques/architectes. Bon, ceci dit, attachez votre ceinture.
Le terrain
Définissons quelques termes - middleware est un terme générique - je l'utilise pour faire référence aux bus de messages/ESB et aux serveurs d'intégration (EAI). L'histoire de ces domaines nous a conduits à notre état actuel et nous aide à comprendre où nous devons aller ensuite, et pourquoi l'ancienne façon de faire de l'intégration de systèmes et de construire des SOA est en train de tomber en faveur des services web RESTful et de la conception basée sur les micro-services en général.
Serveurs d'intégration - qu'il s'agisse d'IBM ou de concurrents de l'époque comme SeeBeyond (pour qui j'ai travaillé), l'intérêt d'un serveur d'intégration était de mettre fin à la pratique consistant à écrire à la main un code pour chaque système/projet afin d'accéder aux données/systèmes. À l'époque, on parlait souvent d'intégrations "point à point" et, lorsque l'on construisait des systèmes complexes dans de grandes entreprises avant les serveurs d'intégration, les flux de données entre les systèmes ressemblaient souvent à un plat de spaghettis. Un projet d'entreprise sur le risque de marché sur lequel j'ai travaillé à la Bank of New York me vient toujours à l'esprit lorsque je pense à cela. Les flux de données de plus de 100 points d'intégration à partir desquels le système de risque consommait des données avaient été présentés dans un diagramme que nous avons laminé sur du papier 11×17 pour en faire une sorte de set de table. Il est devenu pour moi le symbole de ce type de problème. Il ressemblait à peu près à ceci :
(Image attribuée à John Schmidt, autorité reconnue dans le domaine de la gouvernance de l'intégration et auteur d'ouvrages sur le Centre de compétences en intégration et l'intégration allégée)
C'est ainsi qu'est apparu le "serveur d'intégration". L'objectif était de fournir une interface commune et des outils à utiliser pour connecter des systèmes sans écrire de code à partir de zéro, afin que les intégrations entre systèmes soient faciles à construire et à maintenir, tout en étant sûres et performantes. Une autre motivation majeure était de coupler librement les systèmes cibles et les systèmes consommateurs de données afin de les isoler des changements dans le code sous-jacent de l'un ou de l'autre. Le service résultant était essentiellement disponible en tant qu'API, il s'agissait de systèmes propriétaires et, dans un sens, de boîtes noires à partir desquelles vous consommiez ou fournissiez des données. Ils effectuaient les transformations, géraient le trafic, chargeaient les données de manière efficace, etc. Bien sûr, il y avait aussi ceux qui se consacraient aux données en vrac/batch, comme Informatica et plus tard Ab Initio, mais il est amusant de constater que ces deux mondes très liés n'ont jamais réussi à s'unir en une offre unifiée.
Cette approche n'a cependant pas modifié radicalement la manière dont les systèmes logiciels étaient conçus, développés ou déployés. Il s'agissait plutôt d'isoler les exigences d'intégration et de les améliorer grâce à un serveur et à une boîte à outils dédiés. Cette approche a apporté beaucoup de valeur aux entreprises en termes de construction d'intégrations de systèmes robustes, et a également aidé les grandes entreprises à adopter des logiciels packagés avec beaucoup moins d'écriture de code, mais en fin de compte, elle n'a offert que des améliorations marginales dans l'efficacité du développement, tout en injectant encore une autre dépendance de système (nouvel outil, personnel spécialisé, coûts d'exploitation continus) dans la "pile". Bien sûr, il est possible de créer des centres de compétences et des "usines", mais à ce jour, ces approches finissent par créer plus de bureaucratie, plus de dépendances et de complexité tout en ajoutant de moins en moins de valeur par rapport à ce qu'un développeur peut construire lui-même avec des services/micro-services RESTful, et la plupart des choses que l'on veut intégrer aujourd'hui ont déjà des API bien définies, de sorte qu'il est souvent beaucoup plus facile de se connecter et de partager des données de toute façon. Des idées novatrices telles que les "données cohérentes à terme" et les incroyables avantages en termes de coûts et de calcul des technologies open source par rapport aux technologies propriétaires, en plus de l'IaaS public accueillant de telles charges de travail informatiques au niveau des conteneurs, eh bien disons simplement qu'il y a beaucoup plus de choses qui changent que la simple intégration. Les personnes intelligentes à qui je parle me disent que l'utilisation d'un ESB comme épine dorsale d'un système basé sur des micro-services est contraire à l'architecture.
Bus de messagerie/ESB - Il s'agit d'un système de gestion du trafic de messagerie sur un bus à usage général à partir duquel un développeur peut publier, s'abonner, diffuser et multidiffuser des messages provenant de services/systèmes cibles et sources. Ce site plateforme est antérieur au web, pour information, et était présent à la fin des années 80 et dans les années 90 dans les systèmes spécialisés de messagerie à grande vitesse pour les salles de marché, ainsi que dans la fabrication et d'autres environnements industriels où une faible latence était cruciale et où d'énormes pics de trafic étaient la norme. Le succès précoce de Tibco dans les salles de marché était dû au fait qu'il fournissait une architecture basée sur les services pour la consommation des données de marché qui s'étendait et qui permettait également de construire des systèmes utilisant la conception de bus de services/messages. Ces systèmes permettaient d'approcher les exigences de temps quasi réel de ces environnements, mais ils étaient propriétaires, extrêmement coûteux et pas du tout applicables à l'informatique générale. Cependant, l'utilisation d'une architecture de services et de bus avec des communications pub/sub, broadcast, multipoint et point à point disponibles en tant que services pour les développeurs a été formidable pour isoler les applications des dépendances de données et pour gérer les pics de trafic de ces données.
Avec le temps, il est devenu évident que la construction de systèmes à partir de services était très prometteuse (héritant en fait des idées de base de la conception orientée objet), et c'est à ce moment-là que l'idée des services web a commencé à émerger. Des organismes de normalisation entiers ont été créés et de nombreux projets open source et autres ont vu le jour pour soutenir l'approche normative de la conception et du déploiement des systèmes de services web. Les architectures orientées services ont fait fureur - j'ai travaillé sur un projet pour Travelers Insurance lorsque j'étais chez SeeBeyond, dans le cadre duquel nous avons présenté un grand nombre de leurs applications centrales sous forme de services web. Cette approche était censée donner de l'agilité au développement informatique.
Mais en cours de route, un problème est devenu évident. Le coût, l'expertise, la complexité et le temps nécessaires à l'élaboration de cadres de systèmes aussi élégamment conçus et régis allaient à l'encontre de la construction rapide de systèmes. Un bon développeur pouvait obtenir quelque chose de fonctionnel et de haute qualité sans avoir à utiliser tous ces services normalisés WS et à se conformer à leur structure. Parmi les principaux problèmes, citons l'utilisation de XML pour représenter les données, car la puissance de traitement nécessaire à la transformation de ces structures était toujours beaucoup trop coûteuse par rapport aux bénéfices. SOAP était également un protocole hautement spécialisé, injectant encore une autre couche de systèmes/connaissances/dépendances/complexité dans la construction de systèmes avec un haut degré d'intégration.
L'ensemble du cadre WS était trop formel, si bien que des développeurs entreprenants se sont demandés comment utiliser une architecture basée sur les services à leur avantage pour construire un système sans dépendre de toutes ces absurdités. C'est là qu'interviennent les services web RESTful, puis JSON, qui change tout. Soudain, de nouveaux services web complexes et sophistiqués ont commencé à pouvoir être appelés simplement par HTTP. La création et l'utilisation de ces services sont devenues trivialement faciles par rapport à l'ancienne méthode. Les performances et la sécurité pouvaient être gérées d'une autre manière. Ce qui a été perdu, c'est l'idée d'opérer avec des normes de "systèmes ouverts" du point de vue de la conception des systèmes, mais il s'avère que c'est moins utile dans la pratique étant donné tous les frais généraux.
Le point de vue de l'informatique
Les responsables informatiques se doutent déjà que les cadres de bus de messagerie ne leur ont pas apporté l'avantage le plus important qu'ils recherchaient au départ - l'agilité - et pourtant ils disposent de toute cette infrastructure de messagerie et de tous ces services web qui se comportent incroyablement bien. D'une certaine manière, on peut considérer que tout cela fait partie de la façon dont les organisations informatiques apprennent ce qu'est la véritable agilité lorsqu'elles utilisent des architectures basées sur les services. Je pense que beaucoup sont prêts à se débarrasser de tous les frais généraux très complexes et coûteux liés aux bus de messagerie lorsqu'un site plateforme de classe entreprise leur permettra de le faire.
Mais les services informatiques continuent d'aimer les serveurs d'intégration. Je pense qu'ils sont impatients de disposer d'un serveur d'intégration (iPaaS) légitime, hybride, basé surcloud , qui leur permette de construire et de maintenir facilement des interfaces pour divers projets à un coût inférieur à celui des solutions basées sur l'ESB, tout en fonctionnant sur le site cloud et sur place. Il devra offrir les avantages d'une architecture basée sur les services - relations au niveau contractuel - sans la complexité et les frais généraux des bus de messagerie. Elle doit tirer parti de la flexibilité de JSON tout en fournissant un contrôle au niveau des métadonnées sur les services, ainsi qu'une gouvernance opérationnelle complète et un cadre de gestion. Il doit également s'adapter massivement et être distribué dans sa conception afin d'être considéré pour ce rôle central dans les systèmes d'entreprise.
Le véritable moteur de l'adoption des technologies de l'information et de la communication Cloud
Ce que l'on perd parfois de vue avec toute notre attention technique, c'est que l'économie est le principal moteur de l'adoption de cloud . Avec les écarts de coûts massifs qui se créent dans l'informatique publique par rapport aux centres de données sur site ou même externalisés, en raison des dizaines de milliards qu'IBM, Google, MSFT, AWS et d'autres déversent dans leurs services, le site public cloud deviendra le plateforme de prédilection pour toute l'informatique à l'avenir. Tout ce qui reste à débattre au sein de toute bonne organisation informatique, c'est la durée de cette transition.
De nombreuses grandes organisations informatiques voient clairement que le point de basculement en termes de coûts est déjà proche en ce qui concerne l'IaaS et le PaaS. Cela s'est déjà produit sur de nombreux marchés cloud - Salesforce n'a vraiment écrasé Siebel que lorsque ses frais d'abonnement annuels ont été inférieurs aux frais de maintenance on prem de Siebel. N'oubliez pas que Salesforce ne présentait aucun avantage fonctionnel par rapport à Siebel. Indice : puisque l'économie est le moteur, il ne s'agit pas d'avoir la solution la plus élégante, mais d'être capable de faire le travail d'une manière ou d'une autre, même si ce n'est pas joli ou si cela implique des compromis.
Indice plus profond : donnez à un bon ingénieur système le choix entre naviguer dans un nid d'outils, de normes et de services, avec toutes les pénalités de performance, les frais généraux, les compromis fonctionnels et les dépendances qu'ils impliquent, et devoir écrire un peu plus de code et être attentif à la gestion des systèmes, et il/elle choisira la seconde option à chaque fois. Une autre façon de dire cela est que la complexité et l'abstraction sont très coûteuses lors de la construction de systèmes et que les avantages doivent être vraiment importants pour que le compromis ait un sens, et je ne crois pas qu'en fin de compte, les ESB et les normes WS pour l'épine dorsale de la SOA aient jamais été rentables de la façon dont ils devaient l'être. Et cela ne sera jamais le cas. L'industrie a payé cher pour apprendre cette leçon, mais il semble qu'il y ait une grande réticence à en discuter ouvertement. La leçon ? Simplicité = agilité informatique.
La question la plus importante est de savoir quelles charges de travail essentielles de l'entreprise peuvent être transférées vers le site public cloud de manière réalisable, et c'est encore un travail en cours. Des plates-formes comme Apprenda et d'autres solutions hybrides cloud sont des éléments cruciaux de ce mélange, car il faut pouvoir affecter les données et les processus aux ressources appropriées du point de vue de la sécurité/de la confidentialité et des performances/du coût. Une future application unique "cloud" construite par une entreprise pourrait avoir certaines de ses données dans des serveurs sur Azure dans trois centres de données différents pour gérer la résidence des données, d'autres données dans des magasins de données sur site, accéder à des données à partir d'applications SaaS, et accéder à d'autres données encore dans des magasins de données simples super bon marché sur AWS. Il s'agit essentiellement d'une question de " politique " et je dirais que si un iPaaS hybride comme Snaplogic peut s'intégrer dans ces politiques, se comporter correctement avec elles et faciliter la connexion de ces systèmes, il a de bonnes chances d'être un élément central de la grande reconstruction des systèmes informatiques de base que nous allons voir se produire au cours des 10 prochaines années. En effet, il fournit à l'entreprise ce dont elle a besoin, un serveur d'intégration, tout en exploitant les services RESTful, les architectures basées sur les microservices et JSON, sans ESB.
Tout cela est en train de se mettre en place, de sorte que vous verrez un intérêt croissant pour l'abandon des anciennes architectures de serveur d'intégration/bus de messages dans les organisations axées sur la transformation et l'agilité en tant que valeurs fondamentales. Je pense que les dirigeants de la plupart des organisations informatiques sont prêts à abandonner les anciennes normes WS, ainsi que les architectures de bus/message/service, mais leurs propres organisations techniques sont encore construites autour d'elles, ce qui prendra un certain temps. Il est également vrai que les bus de messages ne seront pas entièrement éliminés, car les services de messagerie ont leur place dans le développement des systèmes, mais pas en tant que ciment de l'architecture SOA. Et bien sûr, les bus à faible latence continueront à s'appliquer à la création d'applications en temps quasi réel dans les environnements d'ingénierie ou les salles de marché, mais l'utilisation des bus de messages en tant que modèle de conception général disparaîtra de plus en plus.
En fin de compte, les responsables informatiques sont tout aussi frustrés de ne pas avoir obtenu l'agilité nécessaire à la construction de systèmes utilisant des bus de messagerie/SOA que les responsables commerciaux le sont des coûts et de la latence de ces systèmes. Toutes les parties prenantes sont impatientes de découvrir le prochain paradigme et le moment est venu d'entamer un dialogue sur cette nouvelle vision. Selon moi, il s'agit de l'une des dernières parties cruciales de l'infrastructure informatique à moderniser et à activer cloud pour déplacer les charges de travail informatiques de l'entreprise vers cloud, et je pense que SnapLogic a de bonnes chances d'aider les entreprises à concrétiser cette vision.
______
A propos de l'auteur
Glenn Donovon a été conseiller, consultant ou employé de 23 startups, et il a une grande expérience des entreprises informatiques B2B. Pour en savoir plus sur Glenn, visitez son site web.
