Pourquoi utiliser Azure Integration Services ?

On définit l’intégration comme l’ensemble des services et/ou pratiques permettant de connecter les différentes applications d’un Système d’Information (SI) ensemble. Il s’agit donc d’un processus de transfert de données entre deux systèmes ou plus, qui permet d’automatiser des process métier.

Pour autant, l’intégration ne se limite pas à une simple transmission de données ; il faut prendre en compte un ensemble complexe de considérations :

• La sécurisation des données en transit est essentielle pour protéger les informations sensibles.
• La fiabilité des systèmes est cruciale, car la perte de donnée peut avoir un impact significatif sur les opérations métier.
• La performance revêt une importance particulière, par exemple dans le domaine du e-commerce, où la rapidité des transactions peut faire toute la différence.
• Une attention particulière doit être portée aux problématiques FinOps, car nous utilisons des services nécessitant des ressources de calcul dont les coûts peuvent être fortement impactés en fonction des volumétries.
• L’excellence opérationnelle, qui englobe des aspects tels que le monitoring et le time-to-market, est indispensable pour assurer le fonctionnement continu des systèmes et la rapidité à délivrer des solutions afin d’avoir un avantage concurrentiel.
• Enfin, la connectivité des systèmes est un élément capital, couvrant une variété d’environnements (SaaS, On-Premise, Cloud privé et hybride, services PaaS, etc.) qu’il faut intégrer de manière transparente, tout en garantissant la sécurité et la performance des échanges de données.

Bien concevoir sa plateforme d’intégration dans Azure est donc fondamental pour répondre à ces enjeux.

Les solutions Legacy EAI (Enterprise Application Integration) telles que Biztalk Server ou IBM WebSphere, utilisées depuis des décennies pour répondre aux besoins d’intégration des entreprises, sont historiquement déployées dans des environnements On-Premise. Elles sont souvent associées à une architecture et une infrastructure complexes, une scalabilité limitée et/ou fastidieuse à mettre en place, des coûts de licences élevés et des structures monolithiques qui ne répondent pas toujours aux besoins simples de certaines entreprises, ou à des besoins d’évolutivité pour faire face aux enjeux d’aujourd’hui.

Comparativement, Azure Integration Services (AIS) représente une approche moderne et évolutive de l’intégration dans le Cloud Azure. Contrairement à d’autres solutions d’éditeurs spécialisés dans l’intégration, proposant notamment des offres SaaS, Microsoft propose avec AIS une offre PaaS (Platform As A Service) et une suite d’outils d’intégration distincts et modulaires, offrant un contrôle plus élevé sur l’infrastructure sous-jacente. Elle permet également une intégration plus fluide dans l’écosystème Azure existant.

La réflexion autour de la conception d’une plateforme iPaaS dans Azure ne se limite pas uniquement aux problématiques d’intégration, mais nécessite une compréhension de son SI et de l’écosystème Azure dans son ensemble. C’est pourquoi il est essentiel de s’appuyer sur des cadres et des outils tels que le Cloud Adoption Framework (CAF) et l’Azure Well-Architected Framework (WAF), proposés par Microsoft, pour guider la réflexion architecturale. Ces outils fournissent un cadre structuré pour une conception efficace et optimisée de la plateforme d’intégration dans Azure.

Quels sont les outils à notre disposition pour nous aider dans notre réflexion et conception ?

Cloud Adoption Framework

Le Cloud Adoption Framework (CAF) est un ensemble de bonnes pratiques et de lignes directrices développées par Microsoft pour aider les organisations à adopter et à réussir leur transition vers le Cloud.

Dans le contexte de la conception d’une plateforme d’intégration dans le Cloud, le CAF nous aide à comprendre les principaux aspects à prendre en compte, tels que la planification stratégique, les options d’implémentation, les questions autour de la gouvernance, de la sécurité, de la gestion des coûts et de la conformité réglementaire.

Le CAF met également en avant la notion de Landing Zones. Ces dernières représentent des environnements Cloud prédéfinis et préconfigurés qui servent de base pour le déploiement des charges de travail dans Azure. Les Landing Zones fournissent une infrastructure de référence conforme aux meilleures pratiques en matière de sécurité, de conformité et de performance, ce qui permet de démarrer rapidement et de réduire les délais de mise en œuvre.

Toutefois, comme tout modèle, il ne constitue qu’un point de départ pour la réflexion. Il est donc essentiel dans cette phase de prendre du recul, d’être critique et d’adapter ce modèle de référence aux solutions nécessaires pour répondre pleinement aux besoins et exigences spécifiques de l’entreprise.

Pour approfondir le sujet, nous vous invitons à consulter la documentation Microsoft dédiée à la mise en œuvre d’une Landing Zone AIS « Landing zone Accelerator for AIS ».

Architecture de référence de Azure Integration Services Landing Zone accelerator 

(Source : Documentation Microsoft)

Well Architected Framework

Les 5 piliers du Well Architected Framework

Le Azure Well-Architected Framework (WAF) est une méthodologie développée par Microsoft pour aider à concevoir, évaluer et améliorer les solutions Cloud sur Azure. Il repose sur cinq piliers fondamentaux :

• la fiabilité,
• la sécurité,
• l’efficacité des coûts,
• la performance opérationnelle,
• l’excellence opérationnelle.

Dans le contexte de la conception d’une plateforme d’intégration, le WAF s’inscrit dans les phases de réflexion et de Maintien en Condition Opérationnelle (MCO) en fournissant un cadre structuré pour évaluer et optimiser la conception de l’infrastructure d’intégration dans le Cloud.

Comme pour toute conception de plateforme, il est important de noter que la réflexion et la planification doivent être menées à un niveau global au sein de l’entreprise. L’architecte d’intégration ne peut pas nécessairement posséder une expertise exhaustive dans tous les aspects de la Landing Zone, notamment en ce qui concerne le réseau, la sécurité, la gestion des identités, les problématiques de gouvernance… Ainsi, il est primordial de maintenir une collaboration étroite avec d’autres parties prenantes clés telles que :

• l’architecte d’entreprise qui assure la cohérence de la conception avec les besoins et la stratégie de l’entreprise ;
• le CISO (Chief Information Security Officer), qui garantit la conformité de la plateforme aux normes de sécurité de l’entreprise ;
• le responsable de l’infrastructure Cloud, qui veille à ce que les bonnes pratiques Cloud définies par l’entreprise soient respectées, et peut assister l’implémentation de la plateforme.

Cette collaboration doit être guidée par une vision stratégique clairement définie. L’architecte d’intégration doit être capable de comprendre et d’identifier les exigences spécifiques de la plateforme d’intégration, en posant les questions appropriées, tout en se basant sur les cadres conceptuels précédemment mentionnés.

Réflexion/Planification : quels sont les objectifs de ma plateforme ? Quelles sont les questions importantes à se poser ?

Dans cette section, nous abordons la phase cruciale de réflexion/planification, conformément aux principes du Cloud Adoption Framework. Afin de comprendre les objectifs fondamentaux de notre plateforme, nous proposons une liste non exhaustive des questions essentielles à considérer pour une planification efficace et stratégique de notre transition vers le Cloud.

Besoins d’Intégration

• Quels sont les besoins actuels en termes d’intégration dans mon organisation ?
• En comprenant les besoins, nous pouvons identifier les lacunes éventuelles dans les processus d’intégration, les technologies utilisées et les défis rencontrés. Par exemple, il y a souvent des différences significatives entre les besoins d’intégration des secteurs comme le e-commerce et la santé.
• Quels patterns d’intégration sont les plus pertinents pour répondre à nos besoins ?
  Avons-nous des besoins d’exposition d’APIs, de mise en place d’intégrations ad hoc, d’ingestion et de distribution d’événements, de traitements par lots, de systèmes de messagerie ou de livraisons ordonnées ?
• Il n’est pas nécessaire de pouvoir répondre à l’ensemble des patterns dès le départ, mais il est important d’avoir une idée de leur future mise en place.
• Comment pouvons-nous anticiper les besoins futurs en matière d’intégration, en prenant en compte des aspects tels que l’évolutivité des ressources et l’expansion potentielle des services ?
• Un exemple ici est d’anticiper les futurs besoins réseau en réservant des plages d’adresses IP suffisamment larges et alignées sur les besoins projetés.

Sécurité

• Quelle stratégie de sécurité adopter pour assurer la confidentialité, l’intégrité et la disponibilité des données transitant par notre plateforme d’intégration ?
• Devons-nous mettre en œuvre des mécanismes spécifiques d’authentification, de chiffrement, de surveillance des accès, etc. ?
• Souhaitons-nous exposer nos services à l’externe et/ou en interne ?

Performance et Résilience

• Quelles sont les exigences en termes de performance et de disponibilité ?
• Devrons-nous faire face à des volumétries élevées, des pics de charges ? Devons-nous mettre en place des solutions résilientes (et à quel niveau) pour limiter les conséquences d’une interruption de service ?

Opérations

• Quels mécanismes de gestion des erreurs devons-nous mettre en place pour assurer la fiabilité et la robustesse de nos intégrations ? Devons-nous avoir un système central permettant d’agréger les logs, qu’ils soient techniques ou fonctionnels ?
• Comment prévoyons-nous de surveiller et de gérer la performance de notre plateforme d’intégration ? Quels outils et métriques utiliserons-nous pour suivre les performances, détecter les goulets d’étranglement et optimiser les flux d’intégration ?
• Comment prévoyons-nous de gérer les mises à jour et les évolutions de notre plateforme d’intégration au fil du temps ? Quels processus de déploiement et de gestion des changements devons-nous mettre en place pour assurer une évolution continue et une maintenance efficace de notre architecture d’intégration ?
• Ici il est important de définir nos options en termes d’outils de déploiement d’infrastructure et d’applicatif, de gestion des sources…
• Comment prévoyons-nous de gérer les scénarios où un système que nous intégrons est temporairement indisponible, ou lorsque des erreurs surviennent ? Quels critères devons-nous définir pour déterminer les tentatives de rejeu et les stratégies de gestion des erreurs à adopter dans ces situations critiques ?
• Il est indispensable de prévoir la mise en place de mécanismes de rejeu des données, automatiques ou non, pour garantir la cohérence des systèmes que nous intégrons.

Coûts

• Quelles sont les contraintes budgétaires et de ressources associées à la conception et à la mise en œuvre de notre plateforme d’intégration ? Comment pouvons-nous analyser les coûts de notre plateforme, optimiser l’utilisation des ressources pour maximiser l’efficacité et minimiser les coûts ?
• Il est nécessaire de faire une étude prévisionnelle des coûts fixes et des coûts liés aux opérations (coût lié au stockage des logs, utilisation des ressources…).

Développement

• Combien d’environnements différents devons-nous provisionner pour notre plateforme d’intégration, compte tenu du nombre d’environnements dans les systèmes que nous intégrons ?
• Il s’agit d’un point important, car nous intégrons des systèmes avec plus ou moins d’environnements disponibles que ceux de notre plateforme d’intégration. On aura à minima un environnement de Non-Production et un environnement de Production, dans le but d’optimiser les coûts. Nous pouvons bien sûr prévoir plus d’environnements (3, 4 ou plus) pour nous aligner avec la norme du SI de l’entreprise afin de faciliter la connectivité et les phases de test.

Conception d’une plateforme d’Intégration dans Azure : approches et complexités

Dans le processus de conception d’une plateforme d’intégration dans Azure, il est crucial de considérer les différentes approches et niveaux de complexité en fonction des besoins spécifiques de l’entreprise.

Deux approches principales se dégagent : partir de zéro sans qu’il existe déjà une plateforme Azure en place, ou bien intégrer de nouveaux éléments dans une infrastructure Azure existante répondant à d’autres besoins.

Approche : Départ de zéro sans plateforme Azure existante

Dans le cas où aucune plateforme Azure n’est encore établie, il est primordial de prendre en compte les exigences spécifiques de l’entreprise, et de construire une solution qui répond parfaitement à ses besoins. Cette approche peut nécessiter la création d’un POC pour prouver la solution, ou être le point de départ d’une Landing Zone plus vaste, et donc avoir une stratégie à long terme nécessitant une analyse approfondie des processus métier et des flux de données, afin de concevoir une plateforme intégrée et évolutive.

Approche : Intégration dans l’existant Azure

Si une infrastructure Azure est déjà en place, l’intégration de nouveaux éléments doit se faire de manière cohérente et sans perturber les opérations existantes. Cette approche nécessite une compréhension approfondie de l’architecture Azure en place, et une planification minutieuse pour garantir une intégration fluide des nouveaux composants.

Un exemple d’architecture suit la topologie réseau Hub & Spoke, où l’on intègre la plateforme d’intégration dans un réseau Spoke :

Exemple de réseaux Spoke se connectant entre eux et vers un Hub 

(Source : documentation Microsoft)

Dans cet exemple, on peut imaginer que les réseaux Spoke1 et Spoke3 sont nos plateformes d’intégrations dans les environnements de Développement et de Production, et qu’ils sont chacun connectés avec d’autres Réseaux Spoke pour assurer la connectivité avec d’autres services déployés dans Azure.

Complexité du SI : simple à moyenne

Dans le cadre d’une entreprise de petite ou moyenne taille (PME), les besoins en matière d’intégration peuvent être relativement simples. Il peut ne pas être nécessaire d’avoir une équipe dédiée à l’intégration, mais plutôt des ressources disponibles pour gérer les tâches d’intégration de manière ad hoc. Il est important de suivre le principe KISS (Keep It Simple, Stupid) et de privilégier des solutions simples et efficaces. L’avantage des solutions modulaires AIS est qu’elles permettent de démarrer simplement, de réaliser des preuves de concept, de valider des cas d’utilisation métier et de préparer une éventuelle migration à partir d’un EAI existant.

L’offre Cellenza MVP Integration  est idéale pour les entreprises recherchant une solution simple et efficace pour démarrer leur parcours d’intégration dans Azure. Elle met l’accent sur la mise en place de solutions ajustées aux besoins de l’entreprise, et propose une approche agile pour permettre aux clients de commencer rapidement, d’accélérer leur time-to-market et de réaliser des succès à faible coût.

Complexité du SI : Complexe

Pour les entreprises ayant des besoins d’intégration plus complexes, avec un grand nombre d’applications à intégrer ou à faire évoluer, une approche plus élaborée est nécessaire.

Il convient d’établir un socle solide pour l’ensemble des intégrations dans l’entreprise, avec une équipe dédiée à la gestion et à l’optimisation de cette plateforme. La plateforme sera souvent intégrée à des Landing Zones existantes.

L’offre Cellenza Modern Integration répond à ce besoin : elle offre aux entreprises ayant des besoins plus complexes en matière d’intégration une solution complète et évolutive pour analyser, concevoir, mettre en place et optimiser leurs processus d’intégration à grande échelle.

Comment concevoir une plateforme qui répond à mes besoins mais reste modulaire/Agile ?

Une fois les besoins généraux établis, la stratégie claire et le cadre de conception défini, nous pouvons établir une architecture conceptuelle (aussi appelée logique), qui va définir les grands Building Blocks de notre plateforme.

Ces Building Blocks sont un concept formalisé et intégré au Framework TOGAF, et dont la définition est la suivante : « Un Building Block est une unité de base qui encapsule une certaine fonctionnalité, des données ou une technologie spécifique, définies pour répondre aux besoins métier d’une organisation ».

• Ils sont utilisés pour faire l’abstraction de la complexité d’une architecture en la divisant en plus petites parties gérables.
• Idéalement, ils sont réutilisables et remplaçables, et peuvent évoluer pour suivre les évolutions technologiques et les standards.

Pour imager, on peut voir un Building Block comme un lego ou une brique servant à la construction d’un ensemble.

Par nos différentes expériences, on peut découper les cas d’usage d’une plateforme d’intégration en quatre catégories pour répondre aux besoins de nos clients :

• Exposer des APIs :  solution permettant de faciliter la création, la publication, la gestion et la sécurisation d’APIs dans un environnement centralisé ;
• Orchestrer des workflows simples ou complexes, avec des faibles ou hautes volumétries : solutions permettant d’automatiser des processus métier, allant des tâches simples aux workflows complexes ;
• Avoir un message broker d’entreprise : solution centralisée de messagerie asynchrone, permettant le transfert fiable et sécurisé de messages entre les applications et les services, tout en garantissant la mise en file d’attente, la livraison des messages et la gestion des erreurs.
• Délivrer des évènements : solution permettant la diffusion en temps réel d’événements et de notifications

Afin de pouvoir utiliser ces services efficacement et pour suivre les bonnes pratiques, nous devons également mettre en place des solutions permettant de gérer les secrets et les certificats, le stockage (des données de configurations, des logs), les identités, le monitoring.

Chacune de ces fonctionnalités est définie par un Building Block, qui peut bien sûr interopérer avec les autres (ex : Système de gestion des APIs en Front d’une solution d’Orchestration de Workflow).

Exemple d’Architecture Conceptuelle d’une plateforme d’Intégration

On s’attachera donc à définir nos besoins pour chacun de ces services, toujours d’un point de vue conceptuel.

Pour donner un exemple concret, on peut définir, pour notre solution permettant d’orchestrer des workflows, les besoins suivants :

• Cas d’utilisation principal – Déployer un outil d’intégration basé sur des workflows pour orchestrer les processus de services et connecter divers services, avec des transformations simples/moyennement complexes.
• Fiabilité – Disponibilité attendue de 99,9 %. La solution doit pouvoir être restaurée conformément au RTO (Recovery Time Objective) défini par l’entreprise (< 4h).
• Performance – La solution doit être scalable horizontalement et verticalement pour traiter des volumes faibles à moyens (<10k exécutions/jour).
• Sécurité – Le service doit pouvoir être exécuté dans un environnement entièrement isolé. Nous devons avoir la possibilité de sécuriser tout le trafic entrant et sortant, et de router le trafic sortant vers un Endpoint spécifique.
  • Les Endpoints du service ne doivent pas être exposés en direct sur Internet. Les données doivent être chiffrées au repos.
  • Pour le trafic entrant et sortant, le TLS doit être activé.
• Réduction des coûts (TCO) – Possibilité de réservation d’instance si des coûts fixes sont associés à la solution. Possibilité de réduire le nombre d’instances au minimum si le service n’est pas utilisé.
• Opérations – Intégration native de la solution avec les outils standards de monitoring proposés dans Azure.
• TTM (Time To Market) rapide – Intégration native avec les principaux services Azure et intégration avec Azure DevOps pour déployer via CI/CD (Intégration Continue/Déploiement Continu).

L’essentiel à retenir sur la conception d’une plateforme d’Intégration dans Azure

Pour conclure cet article, voici un récapitulatif des points qui nous semblent essentiels :

• La conception d’une plateforme d’intégration dans Azure représente un pas significatif vers une approche Cloud-First, offrant agilité, scalabilité et résilience aux entreprises souhaitant se moderniser, et pour anticiper l’obsolescence de certains systèmes Legacy.
• Une réflexion en amont avec une stratégie clairement définie est essentielle pour la conception réussie d’une plateforme d’intégration dans Azure.
• L’utilisation d’outils comme le Cloud Adoption Framework (CAF) et le Azure Well-Architected Framework (WAF) offre une méthodologie structurée, et assure une conception optimale des solutions Cloud sur Azure.
• La réussite de la conception d’une plateforme d’intégration dans Azure dépend également de la collaboration étroite entre les équipes techniques, les architectes d’entreprise et les parties prenantes clés, ainsi que de l’alignement sur les objectifs stratégiques de l’entreprise.
• Rester modulaire dans la conception permet d’adapter la plateforme aux évolutions technologiques et métier avec agilité, de maximiser la réutilisation des composants, et de minimiser les risques liés aux changements.

Dans le prochain article de cette série, un de nos experts présentera de manière détaillée les différents services mis à disposition par la suite Azure Integration Services.

Vous souhaitez en savoir plus sur le développement d’une plateforme d’intégration moderne ? Consultez les autres articles de cette série :

• Pourquoi développer une plateforme d’intégration moderne ?
• Comment décliner sa plateforme d’intégration en services Azure avec AIS ?
• DevOps et AIS : quelle stratégie adopter pour optimiser sa plateforme d’intégration Azure ?
• Comment superviser sa plateforme d’Intégration : enjeux et bonnes pratiques