Intégration D'applications Pour Les Architectures Microservices : Un Service Mesh N'est Pas Un ESB

L'intégration des API, des services, des données et des systèmes a longtemps été l'une des exigences les plus difficiles mais les plus essentielles dans le contexte du développement d'applications logicielles d'entreprise.

Nous avions l'habitude d'intégrer toutes ces applications disparates dans un style point à point, qui a ensuite été remplacé par des Enterprise Service Bus (ESB) aux côtés d'une architecture orientée services (SOA).

Cependant, dans les microservices modernes et l'architecture cloud native, nous ne parlons plus de l'intégration d'applications. Cela ne signifie pas que toutes ces architectures modernes ont résolu tous les défis de l'intégration d'applications d'entreprise.

Les problèmes d'intégration d'applications sont restés à peu près les mêmes, mais leur façon de les résoudre a changé.

De l'ESB aux smart endpoints et aux dump pipes

La plupart des entreprises qui ont adopté SOA ont utilisé un ESB en tant que bus central pour connecter et intégrer tous les API, services, données et systèmes disparates.

Si un cas d'utilisation donné nécessitait une conversation avec différentes entités de l'organisation, il incombait à l'ESB de relier toutes ces entités et de créer des fonctionnalités composites.

Par conséquent, les solutions ESB constituent généralement le concentré de toutes les fonctionnalités d'intégration fournies, telles que les connecteurs de systèmes et d'API disparates, le routage des messages, la transformation, la communication résiliente, la persistance et les transactions.

[Cliquez sur l'image pour l'agrandir]

Figure 1: Utilisation d'un ESB pour l'intégration

Cependant, l'architecture Microservices choisit de remplacer l'ESB par la construction de smart endpoints et de dumb pipes, ce qui signifie que vos microservices doivent prendre en charge toute l'intégration d'applications.

Le compromis évident de la décentralisation de l'ESB intelligent est que la complexité du code de vos microservices augmentera considérablement, car ils doivent prendre en charge ces intégrations d'applications en plus de la logique métier du service. Par exemple, la figure 2 illustre plusieurs microservices (B, F et G) qui agissent en tant que smart points, qui contiennent à la fois la logique de la structure de communication entre plusieurs autres services et la logique métier.

[Cliquez sur l'image pour l'agrandir]

Figure 2: Communication et composition interservices des microservices

L’un des autres défis de l’architecture Microservices est de savoir comment créer des fonctionnalités de base ne faisant pas partie de la logique métier du service, telles que la communication résiliente, la sécurité au niveau du transport, la publication de statistiques, le suivi des données vers un outil d’observabilité, etc. Ces services eux-mêmes doivent prendre en charge ces fonctionnalités de base dans le cadre de la logique du service. Il est extrêmement complexe de mettre en œuvre tous ces éléments dans chaque microservice, et l'effort requis pourrait augmenter considérablement si nos microservices sont écrits dans plusieurs langues (polyglottes). Un service Mesh peut résoudre ce problème.

[Cliquez sur l'image pour l'agrandir]

Figure 3: Un service Mesh en action

L'idée principale d'un service Mesh est de conserver l'intégralité du code de la logique métier dans le service tout en déchargeant la logique de communication réseau vers l'infrastructure de communication interservices. Lors de l'utilisation d'un service Mesh, un microservice donné ne communiquera pas directement avec les autres microservices. Au lieu de cela, toutes les communications de service à service se feront via un composant logiciel supplémentaire, fonctionnant à l’écart de processus, appelé proxy service-mesh ou proxy sidecar. Un processus side-car est colocalisé avec le service dans la même machine virtuelle (VM) ou le même pod (Kubernetes). La couche sidecar-proxy est appelée data plane. Tous ces serveurs proxy secondaires sont contrôlés via le control plane. C’est là que toutes les configurations liées aux communications interservices sont appliquées.

Un service Mesh n'est pas destiné à l'intégration d'applications

Dans la mesure où un service Mesh offre certaines des fonctionnalités des ESB, il existe une idée fausse qu'il s'agit d'un ESB distribué qui prend également en charge l'intégration d'applications. Ce n'est pas correct. Un service Mesh est uniquement destiné à être utilisé comme infrastructure pour la communication entre services, et nous ne devrions créer aucune logique métier à l'intérieur de celui-ci. Supposons que vous disposiez de trois microservices appelés X, Y et Z, qui communiquent dans un style requête / réponse, X parlant à la fois avec Y et Z afin de mettre en œuvre ses fonctionnalités commerciales (voir la figure 4). La logique métier de composition doit faire partie du code de microservice X, et le service mesh sidecar ne doit contenir aucun élément lié à cette logique de composition.

[Cliquez sur l'image pour l'agrandir]

Figure 4: Logique de composition de service vs service Mesh

De même, pour tout service utilisant une communication pilotée par les événements, le code de service doit gérer tous les détails de la logique métier (il est également intéressant de noter que les implémentations de services Mesh ne prennent pas encore totalement en charge une architecture pilotée par des événements). Ainsi, même si nous exécutons nos microservices ou nos applications could-native par dessus un services Mesh, l’intégration de ces services ou applications reste essentielle. L’intégration des applications est l’une des exigences les plus critiques et les plus largement dissimulées de l’ère moderne des microservices et de l’architecture cloud-native.

Intégration dans les microservices et les applications cloud-native

Dans le contexte des microservices et des applications cloud-native, l'intégration d'applications ou la création de smart endpoints repose sur l'intégration de microservices, d'API, de données et de systèmes. Ces exigences d’intégration vont de l’intégration de plusieurs microservices à l’intégration de sous-systèmes monolithiques afin de créer des couches anti-corruption. Un examen plus approfondi des exigences d'intégration d'applications dans les microservices et les applications cloud-native révèle les fonctionnalités clés suivantes dont nous avons besoin dans un framework d'intégration d'applications :

• Le processus d’intégration doit être cloud-native, pouvoir s’exécuter dans Docker / Kubernetes et permettre une intégration transparente avec l’écosystème cloud native.
• Il a besoin d'orchestrations de services / de compositions actives pour qu'un service donné contienne la logique qui appelle plusieurs autres services pour composer une fonctionnalité métier.
• Il a besoin de service de compositions de chorégraphie/réactives afin que la communication interservices s'effectue via une communication synchrone événementielle et qu'aucun service central ne contienne la logique d'interaction de services.
• Il doit avoir des abstractions intégrées pour une large gamme de protocoles de communication (HTTP, gRPC, GraphQL, Kafka, NATS, AMQP, FTP, SFTP, WebSockets, TCP).
• Il doit prendre en charge le dédoublement (forking), la jonction (joining), le fractionnement (splitting), le looping et l'agrégation de messages ou les appels de service.
• Il a besoin de stocker et de transférer une livraison persistante et des techniques d'échanges de messages idempotentes.
• Il doit avoir un mapping par type de message et des transformations.
• Il doit s'intégrer aux systèmes SaaS (par exemple, Salesforce), propriétaires (par exemple, SAP) et historique existants (legacy).
• Il devrait exister un routage des messages orienté logique métier.
• Il doit prendre en charge les transactions distribuées avec mécanismes de compensations.
• Il doit avoir des workflows de longue durée.
• Les couches anti-corruption doivent relier les microservices et les sous-systèmes monolithiques.

Toutes ces fonctionnalités sont communes à tous les microservices ou applications cloud-natives, mais leur création à partir de zéro peut être une tâche ardue. C'est pourquoi il est vraiment important d'analyser attentivement ces capacités d'intégration lors de la création de microservices ou d'applications cloud-natives, et de choisir la technologie ou le framework appropriée en fonction des exigences d'intégration. Par exemple, si nous devons créer un service avec une logique d’orchestration complexe, nous devons sélectionner le framework d’intégration ou la technologie facilitant l’écriture de ce type de compositions. Si nous voulons créer un service qui dure longtemps et qui dispose de fonctionnalités de compensation, nous devons sélectionner un framework qui prend en charge les workflows et les compensations (dans l'article InfoQ "Events, Flows and Long-Running Services: A Modern Approach to Workflow Automation ", Martin Schimak et Bernd Rücker fournissent une analyse approfondie de l’état actuel des technologies de workflows pour les architectures cloud-natives).

Bien que l’intégration d’applications ait été largement négligée par la plupart des experts en microservices, des auteurs tels que Christian Posta (ancien architecte en chef de Red Hat et CTO de Solo.io) ont souligné l’importance de l’intégration d’applications, comme dans le blog de Posta " Application Safety and Correctness Cannot Be Offloaded to Istio or Any Service Mesh". Bilgin Ibryam a expliqué comment l'architecture d'intégration d'applications avait évolué d'une architecture SOA à une architecture cloud-native, dans son article InfoQ intitulé " Microservices in a Post-Kubernetes Era ", dans lequel il souligne la décentralisation de l'intégration d'applications avec l'architecture cloud-native et comment l'intégration des applications est construite en utilisant des services Mesh.

Développement et intégration dans l'écosystème du CNCF

La CNCF (Cloud Native Computing Foundation) est à l’avant-garde de la création de microservices et d’applications cloud-natives. Elle vise à créer des écosystèmes durables et à créer une communauté autour d’une constellation de projets de grande qualité qui orchestrent des conteneurs dans une architecture Microservices. Le CNCF héberge des projets composés de technologies et de frameworks open source pouvant implémenter différents aspects de l'architecture Microservices ou cloud-native. Il est intéressant de voir où ces technologies d'intégration d'applications s'intègrent dans leur pile technologique.

Le CNCF dans ces recommandations relatives à l'écosystème cloud natif comporte une section Définition et développement d'applications, mais pas de catégorie dédiée au développement ou à l'intégration d'applications. Compte tenu de l'importance de l'intégration des applications, nous pourrions toutefois le voir entrer dans le paysage du CNCF à l'avenir. La figure 5 présente les technologies d'intégration d'applications dans la section Définition et développement d'applications.  

[Cliquez sur l'image pour l'agrandir]

Figure 5: Intégration d'applications dans un futur paysage CNCF

Technologies d'intégration d'applications

Bien que de nombreuses technologies d'intégration pour applications monolithiques soient disponibles, la plupart ne conviennent pas aux architectures cloud-natives ou aux microservices. Seuls quelques fournisseurs d’intégration existants ont implémenté des variantes cloud-natives de leurs produits et outils.

Il existe des frameworks d'intégration dédiés qui facilitent tous les patterns d'intégration courants dans l'espace d'intégration d'applications. Généralement, la plupart de ces technologies sont héritées de l'intégration classique basée sur ESB, mais elles ont été modifiées et intégrées de manière native dans des architectures cloud-natives :

• Apache Camel / Camel-K est l’un des frameworks d’intégration open-source populaires et le projet Camel-K offre une prise en charge transparente de l’écosystème Kubernetes en plus du moteur d’exécution Camel.
• WSO2 Micro Integrator est une variante cloud-native de la plate-forme open source WSO2 Enterprise Integrator. Micro Integrator offre un environnement d’intégration léger qui fonctionne de manière native dans l’écosystème Kubernetes.
• Bien que Spring Integration ne dispose pas d'un environnement d'exécution dédié pour travailler sur Kubernetes, cela fonctionne bien pour la construction d'intégrations d'applications dans une architecture cloud-native.

Certains des frameworks de développement d'applications répondent également aux exigences d'intégration d'applications :

• Spring Boot n'est pas une infrastructure d'intégration en soi, mais il possède de nombreuses capacités substantielles requises pour l'intégration d'applications.
• Vert.x est une boîte à outils permettant de créer des applications cloud-natives réactives, qui peuvent également être utilisées pour l'intégration d'applications.
• Micronaut est framework moderne, reposant sur une machine virtuelle Java, qui permet de créer des applications modulaires et facilement testables de type serverless ou microservice. Quelques abstractions d'intégration sont intégrées au framework, ce qui évite les complexités des frameworks classiques tels que Spring.
• Les langages de programmation tels que Go, JavaScript / Node.js , etc., intègrent certaines fonctionnalités d'intégration d'applications ou sont disponibles en tant que bibliothèques. De nouveaux langages émergents tels que Ballerina proposent des abstractions d'intégration dans le langage.
• Quarkus est une nouvelle stack Java native pour Kubernetes qui a été conçue pour GraalVM et HotSpot d'OpenJDK, assemblée à partir des meilleures bibliothèques et normes Java. C'est une combinaison de plusieurs bibliothèques de développement d'applications telles que RESTeasy, Camel, Netty, etc.

Conclusion

Avec la séparation des applications monolithiques en microservices et en applications cloud-natives, le besoin de connecter ces applications devient de plus en plus challenging. Les services et les applications sont dispersés sur le réseau et connectés via des structures de communication disparates. Réaliser un cas d'utilisation métier nécessite l'intégration des microservices, ce qui doit être fait dans le cadre de la logique d'implémentation du service. De ce fait, l’intégration d’applications cloud-natives est l’une des exigences les plus critiques et pourtant largement dissimulées de l’ère moderne des microservices et de l’architecture cloud-native.

Le pattern service Mesh surmonte certains des problèmes liés à l'intégration de microservices mais n'offre que les fonctionnalités de base de la communication interservices, qui sont indépendantes de la logique métier du service. Par conséquent, toute logique d'intégration d'application liée au cas d'utilisation métier doit toujours être mis en œuvre au niveau de chaque service. Par conséquent, il est important de sélectionner la technologie de développement la plus appropriée pour créer des services compatibles avec l'intégration et minimiser le temps de développement nécessaire pour associer des services. Plusieurs frameworks et technologies émergent pour répondre à ces besoins d'intégration d'applications dans le paysage cloud-native, qu'il convient d'évaluer en fonction de chaque cas d'utilisation spécifique.

A propos de l'auteur

Kasun Indrasiri est directeur Integration Architecture chez WSO2 et auteur / évangéliste sur l'architecture Microservices et l'architecture d'intégration d'entreprise. Il a écrit les livres Microservices for Enterprise (Apress) et Beginning WSO2 ESB (Apress). Il est committer Apache et a travaillé en tant que chef de produit et architecte de WSO2 Enterprise Integrator. Il a été speaker lors de la conférence O'Reilly Software Architecture, GOTO Chicago 2019 et pour la plupart des conférences WSO2. Il assiste à la plupart des meetups sur les microservices dans la région de la baie de San Francisco. Il a fondé le Silicon Valley Microservice, API et Integration Meetup, un meetups sur les microservices indépendant des fournisseurs dans la région de la baie de San Francisco.