Dans mon dernier article, j'ai passé en revue les exigences classiques en matière d'intégration et j'ai décrit quatre nouvelles exigences qui stimulent la demande d'intégration plateforme en tant que service(iPaaS) dans l'entreprise :
- La résilience
- Fluidité dans les déploiements hybrides
- Absence de gestion du cycle de vie des plateforme
- Préparer l'avenir pour le monde du social, du mobile, de l'analytique, de cloud et de l'internet des objets (SMACT)
Dans ce billet, j'examinerai l'exigence n° 2 : la fluidité dans les déploiements hybrides.
Tout comme les changements de structure de données sont fréquents (comme nous l'avons vu dans l'article sur la résilience), l'introduction ou le retrait d'applications est un phénomène auquel la plupart des organisations informatiques sont confrontées dans l'entreprise. Le logiciel en tant que service (SaaS) continue d'alimenter la croissance mondiale des logiciels et les fournisseurs d'infrastructure en tant que service (IaaS) et plateforme en tant que service (PaaS) tels qu'Amazon Web Services (AWS) offrent aux clients la flexibilité de construire des systèmes tels que les services de données relationnelles (RDS) ou Redshift et de les démanteler sur des cycles courts. Les spécialistes du marketing numérique sont toujours à la recherche de nouveaux canaux pour élargir leurs marchés potentiels et de sources de données supplémentaires pour enrichir leurs profils d'audience. Le changement est la seule constante de l'entreprise agile. L'impact de ces changements sur la couche d'intégration est qu'on attend d'elle qu'elle passe en toute transparence de la connexion de systèmes sur site à des systèmes cloud ou vice versa, tout en garantissant un haut degré de continuité des activités.
Les technologies iPaaS développées au cours de la dernière décennie n'ont pas été conçues pour la fluidité nécessaire à l'architecture informatique hybride d'aujourd'hui. Même si de nombreux fournisseurs de solutions d'intégration traditionnelles proposent un modèle de déploiement double - l'un dans les locaux et l'autre sur le site cloud - ils ne sont généralement pas homologues en ce qui concerne la gestion, la surveillance et la configuration (sans parler des fonctionnalités). Voici quelques problèmes courants auxquels les clients sont confrontés avec ce que j'appelle les technologies d'intégration " franken-hybrid " :
-
Le déploiement sur le site cloud n'est pas le même que le déploiement du moteur sur site. Le fournisseur peut avoir besoin d'un ensemble différent d'exigences en matière de préparation et de configuration entre les deux environnements. Par exemple, la mise en place de configurations généralement locales, telles que la mise en commun de connexions ou même la fourniture d'emplacements de pilotes avec leurs produits sur site, doit toujours être effectuée localement et manuellement pour chacune des installations du moteur d'exécution. Cette approche peut s'avérer très manuelle, lourde et sujette aux erreurs.
-
Les tableaux de bord de gestion et de surveillance doubles - l'un pour le moteur d'exécution sur site et l'autre pour le moteur cloud - signifient que l'administrateur doit surveiller manuellement deux environnements. Cela prend du temps et présente des risques.
-
Le moteur sur site a été conçu pour connecter des systèmes sur site et nécessite souvent l'ouverture de nombreux ports de réseau pour les communications afin de recevoir des instructions de traitement des données ou de renvoyer des informations de surveillance au serveur. Si les serveurs de surveillance et de métadonnées fonctionnent sur le site cloud, les clients doivent souvent percer des trous dans le pare-feu de leur réseau pour que toutes les fonctionnalités de l'iPaaS puissent fonctionner.
Une solution iPaaS vraiment moderne doit offrir ce que j'appelle la "fluidité" dans un déploiement hybride. Plus précisément, il y a deux choses auxquelles vous devez faire attention lorsque vous prenez la décision d'acheter une solution iPaaS :
- Lorsque vous examinez les solutions d'intégration cloud des anciens fournisseurs, assurez-vous de regarder sous le capot pour vérifier qu'ils ne se contentent pas de "cloud washing " leur produit sur site et de l'héberger dans cloud. Même s'il s'agit de la même base de code qui est hébergée dans cloud et à l'intérieur du pare-feu et qui peut être déployée à l'aide d'une option déroulante, vous rencontrerez des problèmes de gestion, de surveillance et de configuration. La gestion et la surveillance de ces deux runtimes nécessiteront des consoles distinctes, car ils ne sont pas homologues et n'ont pas la capacité de communiquer avec le serveur de surveillance à travers le pare-feu. En outre, les runtimes sur site ont été conçus pour avoir des fichiers de configuration qui ne sont pas gérés de manière centralisée et qui sont locaux à l'installation. La gestion et la configuration de ces environnements hybrides deviennent un coût récurrent à chaque mise à jour du logiciel et peuvent représenter une somme considérable.
- De même, ne tombez pas dans le piège de la cartographie qui consiste à "cartographier une fois et exécuter partout". Il n'y a pas assez de valeur lorsque vos mappings créés une fois peuvent fonctionner partout parce que les mappings sont généralement très spécifiques à la source et aux cibles qui sont intégrées. La plupart du temps, elles ne sont pas transférables de l'entreprise à cloud , car les points de terminaison typiques de l'entreprise (Oracle ERP, SAP, Teradata, etc.) sont très différents des points de terminaison de cloud (Salesforce, Workday, Redshift, etc.). Cela rend l'idée d'un "run everywhere" tout à fait inefficace. L'autre problème de cette approche est qu'elle masque en réalité le fait que le " partout " implique une variété de produits différents que l'on essaie de faire paraître similaires. Cet ensemble de produits distincts implique également des problèmes de gestion et de surveillance. Enfin, les mappages représentent un coût unique et, par conséquent, la réutilisation ne rapporte pas grand-chose. Ce sont les coûts de gestion et de contrôle qui sont les plus importants.
C'est en raison des défis que j'ai énumérés ci-dessus qu'une intégration définie par logiciel plateforme en tant que service est devenue un élément clé de la "cloudification de l'entreprise". Un degré élevé de fluidité de l'intégration se traduit par une plus grande agilité de l'entreprise.
Restez à l'écoute pour le prochain article de cette série iPaaS, qui examinera l'importance de la gestion du cycle de vie et la bonne approche de l'intégration cloud , alors que vous vous préparez à la transition de l'entreprise vers le social, le mobile, l'analytique, cloud et l'internet des objets (SMACT).
