Intégration agile, une formalisation des pratiques pour répondre à l’adaptabilité des organisations, un article rédigé par Charly Clairmont, CTO, Synaltic.
Intégration Agile, une formalisation des pratiques pour répondre à l’adaptabilité des organisations
Depuis les vingt dernières années, les organisations ont dû faire preuve d’une grande adaptabilité : Web, Réseaux Sociaux, mobile, le Big Data et le cloud ; maintenant le Edge Computing et l’Intelligence Artificielle… Les technologies ont fait apparaître de nouveaux enjeux qui ont apporté leurs lots de transformations dans les organisations. Les technologies ne sont pas les seuls éléments qui conduisent les entités à se repenser. Il y a de nombreux événements extérieurs qui les percutent et accélèrent cette transformation. A tel point que certaines entités se retrouvent même dans une situation de changement complet de modèle économique.
L’informatique fait partie des services support dans les organisations, c’est-à-dire qu’elle est transverse à l’ensemble de toutes les directions, de tous les départements ou services.
Ainsi, si les organisations doivent savoir s’adapter, et l’informatique doit pouvoir offrir cette capacité d’évolution et d’adaptabilité ! Autrement, les organisations ne vont pas savoir suivre…
Effectivement, la pression des changements et des innovations ne cesse plus ; les logiciels et les données sont les nouvelles armes des organisations. C’est pour cela qu’ils doivent être en mesure de changer de politique de prix, de lancer un nouveau produit, d’en repenser ceux déjà présents sur le marché avec en plus une démarche circulaire, intégrer des capteurs (IOT)…
Ces initiatives sont soutenues grâce à des objectifs stratégiques qui s’appuient sur des socles Big Data, des API, ou du Cloud…
Pour avoir une telle adaptabilité, les organisations doivent avoir une capacité à délivrer et intégrer tant des applications que des données pour répondre stratégiquement à leur nouveaux enjeux et rester compétitives.
Cette capacité à intégrer des applications et des données : c’est l’intégration d’entreprise.
L’intégration d’entreprise (EAI, ESB) subit une pression importante et n’arrive plus à suivre ! La gouvernance des données imposée par les règles telle que la RGPD, oblige à une traçabilité fine que de tels systèmes n’intègrent pas.
En même temps, l’écosystème informationnel des organisations ne cesse plus de s’étendre : plus de partenaires, cloudification, sassification des environnements…
L’intégration d’entreprise doit désormais être plus agile !
Qu’est-ce que l’intégration agile ?
L’Agilité, en informatique, fait souvent référence aux méthodes agiles (Scrum, Kamban, XP, …). Et l’intégration agile peut être confondue avec l’intégration continue (CI / CD).
Ici, l’intégration Agile s’articule tel un cadre d’architecture pour l’intégration d’entreprise. Elle renvoie à la fois aux méthodes agiles et aux architectures micro services, dans le but de faciliter une grande proactivité des organisations.
Pour Red Hat, l‘intégration agile s’appuie sur des plateformes, processus et technologies modernes conçues pour les solutions adaptables à l’évolution rapide des organisations.
Les architectures micro services offrent l’adaptabilité nécessaire aux organisations.
Les bus d’entreprise avaient apporté une réponse à la fluidification des échanges dans les organisations. Toutefois, aujourd’hui ils ne savent plus répondre tant ils peuvent présenter des problématiques liées à leur complexité de mise en œuvre. Par exemple avec les échanges inter-applicatifs en SOAP, surtout quand il s’agissait d’applications écrites dans des langages autres que Java, .Net.
Même si les technologies REST ont simplifié l’écriture de services web, même si depuis peu sont apparus des “portails d’API” (API Gateway)… bien des points peuvent encore être améliorés : centralisation des métadonnées, traçabilité des dépendances entre services, découplage entre services et machines qui les hébergent…
Ainsi les architectures micro services ont apporté la modularisation nécessaire afin de découper plus aisément une application en éléments singuliers réutilisables. Chacune des fonctions des modules en services permet alors aux organisations de franchir de nouveaux pas vers l’agilité. (des équipes de développement autonomes et responsables pour un pool de services).
Toutefois, cette modularisation n’a pas pour autant fait disparaître les besoins en transformation, orchestration et échange entre ces services. L’intégration est toujours fortement utile.
Une convergence très forte s’est opérée ces dernières années ; elle place la donnée au centre de tout !
Il convient ainsi que toute application dès sa conception prend d’emblée en compte la nécessité d’Intégration !
Nous ne saurions mieux résumer ce qu’est l’intégration agile que Red Hat :
“En adoptant une approche agile de l’intégration, il est possible d’inclure l’intégration aux processus de développement des applications, notamment aux architectures de micro services, et de gagner ainsi en agilité.”
Elle repose sur trois piliers
Toutes les organisations ont un portefeuille d’applications, de bases de données qui grandissent parce qu’il y a toujours plus de processus à mettre en données (digitalisation, numérisation).
Aujourd’hui elles peuvent être hébergées sur site, dans le Cloud, voire les deux, ou même sur plusieurs fournisseurs de services Cloud. Le besoin en intégration est toujours aussi conséquent.
Si l’intégration était déjà au cœur même de l’urbanisation du système d’information, elle prend tout comme la donnée une convergence, qui l’amène à être associée au processus même de développement de nouvelles applications, et à connecter le système existant.
Les architectures orientées services d’entreprise évoluent
Ce schéma explique l’évolution d’architecture qui est en train de s’opérer ; depuis l’ESB en passant par les architectures micro services pour finalement atteindre les architectures de type services mesh.
L’architecture très centralisée, peu résiliente, avec des services étroitement couplés. Un couplage fort que l’on retrouve aussi entre logique et connectivité est abandonné au profit d’une décentralisation complète. Elle va permettre à chaque équipe et chaque application de choisir le langage de développement qui lui convient.
Les équipes de développement deviennent autonomes et responsables des applications et des services qu’elles développent, et donc des “intégrations” nécessaires.
Déstructurer l’application
Service Mesh
Netflix a été le premier à séparer la couche de mise en réseau des applications. Ils ont créé des projets Open Source comprenant Hystrix, Eureka et Ribbon. Docker, à son tour, a développé et popularisé les containers et leur format d’image. Cela permet à Google de travailler sur l’abstraction de son infrastructure qui passe alors en Open Source avec Kubernetes.
C’est l’un des projets les plus importants de cette nouvelle vague du Cloud. Les développeurs du monde entier ont réalisé que Kubernetes offrait de nouveaux outils pour résoudre les problèmes détectés par Netflix dans le passé.
Par la suite, le proxy Envoy (on pourrait aussi citer Linkerd) s’exécute au sein de Kubernetes. Il s’agit d’un proxy distribué hautes performances développé à l’origine chez Lyft qui a jeté les bases du “services mesh”.
Le Service Mesh est donc la connectivité entre les services d’application qui ajoute des fonctionnalités telles que la résilience, la sécurité, l’observabilité, le contrôle du routage, une gestion de métadonnées, et le suivi de la qualité de service.
Les apports d’une approche services mesh
Une API répond à une problématique métier, et justement, ce service répond aussi à une rationalisation, il est clairement identifié. De ce point de vue, il sera sollicité par tous les autres services, applications, traitements batch qui en auraient un usage. Et ainsi, de veiller au bon fonctionnement d’un processus de l’organisation. Ce scénario est très commun.
Il met en lumière une des grandes difficultés dans la mise en œuvre des API : l’appel des services. Effectivement, plus il va y avoir d’interactions avec le service plus le risque de défaillance se retrouve diffusé aux autres services qui en dépendent.
Le Service Mesh aide ainsi les organisations à résoudre de manière plus élégante certaines des préoccupations telles que les appels de service, l’équilibrage de charge, l’observabilité ou encore la résilience.
Avec une approche Service Mesh, un proxy est délivré avec le service ; ce qui allège son code et la complexité de développement. Au lieu de “sur-développer”, il s’agit davantage de configuration portée par le proxy ; les équipes de l’administration système peuvent mieux reprendre le contrôle sur la manière dont les services vont interagir entre eux ; mieux surveiller et agir sur les problématiques réseau.
Nous voilà à l’intégration Agile
A ce niveau, nous devons reconnaître que nous évoquons des interactions assez génériques : un traitement batch appelant un simple service.
Mais qu’en est-il des compositions de plusieurs services, plus larges, répondant à des règles d’intégration moins génériques, plus complexes ?
La capacité d’intégration utile aux organisations dépasse donc les apports du Service Mesh.
Tout en s’appuyant sur le Service Mesh, il est préférable de déléguer la mise en œuvre d’intégration d’entreprise à des frameworks distribués dédiés et bien testés qui implémentent des modèles d’intégration d’entreprise déjà connus. Les développeurs et les intégrateurs peuvent utiliser ces outils pour gérer correctement l’orchestration, la transformation des données ou le routage de données.
Christina Lin, Enterprise Architect chez Red Hat, a défini cette architecture de référence pour l’intégration agile. On y découvre différentes couches :
- Couche de passerelle (Gateway Layer) : fournit une capacité de routage simple vers les différentes versions de votre API ou selon les types d’appareils qui accèdent aux microservices.
- Couche de composition (Composite Layer) : un niveau intermédiaire important qui gère la composition de plusieurs microservices. Ils effectuent un routage plus complexe à partir de traitements des données de contenu elles-mêmes et gèrent parfois une agrégation ou une normalisation de données plus complexes.
- Couche de base (Base Layer) : comme son nom l’indique, elle représente les composants de base du système. Elle gère la récupération des données ou le traitement de la logique métier.
- Couche anti-corruption : elle gère l’interface avec une application héritée, où tout ce qui émane du système d’informations et qui ne répond pas à la modularité des micro services. Cette couche est intégrée au pare-feu de données du système, en effectuant un travail de transformation et de traduction entre deux implémentations très distinctes du système. (micro service et non micro service, système hérité (legacy))
Ces couches ici définies, renvoient à l’architecture 5 couches bien connues dans le développement objet ; ici nous sommes à une autre échelle.
L’Intégration agile a une focalisation particulière bien évidemment au niveau de la couche de composition.
Cette couche est la couche qui renvoie précisément aux problématiques d’intégration d’entreprise ; elle couvre les fonctionnalités suivantes :
- Composition de micro services :
- En appelant l’API disponible à partir de micro services, en transformant les données selon leurs besoins propres et en acheminant les données vers les micro services correspondants, en fonction de leur contenu.
- Déclenchement d’événements :
- L’événement représente le meilleur socle pour découpler l’adhérence entre chaque service. Cela permet des performances optimales en raison de sa nature asynchrone. Le bus événementiel, ici, ne doit pas forcément être un broker de messages, ou toute autre forme de bus.
- Enrichissement de contenu :
- L’enrichissement du contenu ici doit être spécifique au format et éviter tout enrichissement métier supplémentaire, lorsque cela est possible.
- Application de modèles d’intégration :
- Les anciennes problématiques d’intégration déjà bien connues ne disparaissent pas avec le monde des micro services. En appliquant des modèles éprouvés (EIP), cela évite de réinventer la roue et écarte les erreurs que l’on pourrait reproduire !
- Mise en cache :
- L’architecture REST parle spécifiquement d’une couche de mise en cache. Il est logique que la couche de composition essaie d’appliquer un mécanisme de mise en cache, car il n’est pas spécifique à la problématique métier. Cependant, il a un impact significatif sur les performances et la capacité de tolérance aux pannes du système.
Et concrètement…
Apache Camel, une brique essentielle de l’intégration agile
C’est pourquoi, comprendre et assimiler tous ces concepts prend plus de sens s’il est possible de les manipuler concrètement.
Désormais, les modèles d’intégration d’entreprise (EIP) sont largement maîtrisés, ils ont fait leurs preuves et sont largement utilisés. Effectivement le nombre de projets permettant l’intégration de données sont pléthoriques et ce, autour des nombreux langages de programmation qui existent.
Dans le monde Java, il y a Apache Camel qui regroupe plus de 300 composants et sait tout intégrer ou à peu-près tout !
Depuis la version 3.0 d’Apache Camel, il y a quelques sous-projets qui ont été livrés. Ces derniers offrent tout le cadre permettant de mettre en œuvre votre plateforme moderne ; de manière à gérer l’intégration de données en toute agilité.
Les deux projets les plus importants de cette stack sont Apache Camel K et Apache Camel Quarkus. Le premier couplé à son opérateur pour Kubernetes gère de bout en bout l’intégration de données. Quant au deuxième, il optimise les images des containers et les performances de votre service d’intégration de données.
Ces dernières années, toutes les connaissances acquises autour de Camel se trouvent ainsi démultipliées sur des plateformes telles que Kubernetes, Openshift, Rancher… En effet, Camel K ouvre tout l’écosystème d’Apache Camel au monde de Kubernetes, facilitant au passage la migration d’applications existantes vers les nouvelles plateformes.
Ce standard de l’intégration et de développement de services permet ainsi l’intégration d’entreprise pour tous les environnements Cloud, Kubernetes étant la plateforme la plus avancée, tant sur le cloud que sur site.
Dans la foulée, Apache Camel dans cette nouvelle version 3.0 devient aussi “serverless” !
Ce qu’il faut savoir, c’est qu’avec son opérateur pour Kubernetes, Apache Camel K vient gérer toutes les tâches connexes pour le développeur / intégrateur. C’est-à-dire construire l’image du micro service d’intégration, le publier dans le registre pour le rendre disponible au cluster Kubernetes, exécuter et gérer le cycle de vie de ce micro service d’intégration, y appliquer les éléments de configuration de sécurité et de paramétrage, y référencer et adjoindre les points de surveillance pour s’assurer de sa bonne santé.
Tous les apports du service mesh sont donc bien sûr conservés…
Synaltic a fait le choix d’Apache Camel il y a bien des années et apprécie clairement l’orientation cloud prise par ce projet.
Découvrez le témoignage de nos clients
SOURCES :
https://www.infoq.com/fr/articles/service-mesh-ultimate-guide/
https://www.infoq.com/fr/articles/microservices-post-kubernetes/
[…] Intégration Agile, une formalisation des pratiques […]