Asanka AbeysingheVice President de l’architecture des solutions chez WSO2 nous présente, dans cet article, une approche pratique de l’Architecture Microservice, et propose un focus sur les principales fonctions requises pour un middleware au sein de cette dernière.

Introduction

 

Aujourd’hui, beaucoup de sociétés ont créé différents types de systèmes, disposent d’un patrimoine de bases de données intégrées dans leurs logiciels, et ont surtout mis en place des programmes, comme des « web apps » (applications web), applications mobiles, et autres ressources liées aux clients et consommateurs.

Ce scénario -typique- apporte certaines complications relativement freinantes pour les entreprises. Ces complications poussent la plupart des organisations à adopter une Architecture Orientée Service (SOA).

Les architectes-développeurs de logiciels font maintenant face à un défi majeur, car le concept de microservices devient de plus en plus prépondérant au sein de la SOA (Architecture Orientée Service). Ce n’est pas un concept totalement nouveau, en effet, il y a déjà quelques années, certaines entreprises ont commencé à adopter ce principe en faisant tourner un nouvel environnement pour chaque système, au lieu de coupler ensemble plusieurs systèmes déjà implémentés. La non-interdépendance des systèmes permettait une maintenance optimisée.

Microservices et évolutions technologiques

De façon très imagée, les microservices sont comme un lien entre les technologies de deux générations. Le concept a déjà été expliqué de différentes, et nombreuses façons. Un couplage précis prévalait en « pré-SOA« , ou à l’ère de la Plateforme 1.0 – (l’ère de l’Architecture Centralisée, pour Asanka Abeysinghe). Des complications en résultaient. La progression vers la Plateforme 2.0 (ou l’ère du Calcul Distribué, pour A.Abeysinghe) a observé beaucoup moins d’interdépendances entre les différents services. Elle incluait la messagerie, les débuts de l’Architecture Orientée Services traditionnelle, l’EDA (Event Driven Architecture, ou Architecture Orientée Evénements), l’Architecture Orientée Objets 

Le concept de calcul distribué s’est vu propulsé à un autre niveau, via la Plateforme 3.0 (l’ère du Cloud Computing, pour A.Abeysinghe), qui contient essentiellement les meilleures fonctionnalités venant de la Plateforme 2.0, et l‘incorporation de middlewares (intergiciels) de nouvelle génération. Avec les évolutions technologiques, l’Architecture Microservice (MSA) offre un découplage complet, assurant ainsi une agilité de livraison, et une flexibilité de déploiement.

(Images: PWC – United States)

Il ne s’agit pas d’un concept complètement étranger. En gros, on rassemble les meilleures pratiques en terme d’Architecture Orientée Microservice (SOA), pour les lier à des champs d’applications et de développement modernes (nous pouvons relever les exemples des logiciels « Docker » et « Kubernetes« , et « Puppet«  ou « Chef » pour effectuer les automatisations).

Une fausse mauvaise idée chez les architectes-développeurs de logiciels, au sujet des microservices, est que tout est une question de taille, Cependant, lorsqu’ils conçoivent des services, ils devraient plutôt considérer comment ils pourraient les étendre, et éventuellement en faire un judicieux ensemble de microservices.

Cette image illustre une Architecture Microservice typique de référence. Beaucoup d’architectes logiciels se concentrent sur l’architecture interne (Inner Architecture), où doivent s’écrire et se déployer les microservices, mais il faut également considérer l' »extérieur » de cette architecture (Outer Architecture). Elle comprend la façon dont sont invoqués les services, leur hiérarchie, la façon dont ils communiquent  … L’architecture intérieure se réfère à l’exécution pour héberger des microservices (par exemple le composant des services); l’architecture extérieure concerne les temps d’exécution supplémentaires du middleware qui étendent les microservices dans un modèle d’architecture d’entreprise.

L’Architecture Microservice : fondamentaux

L’Architecture Microservice dispose de nombreuses fonctionnalités, qui se centrent sur divers aspects. Néanmoins, les suivants (tels qu’expliqués dans un blog de James Lewis et Martin Fowler) peuvent être identifiés comme les principales fonctions à retenir de cette dernière :

  • Fractionnement des composants de services – il s’agit essentiellement de diviser de « grands services » en petits ensembles de services qui, théoriquement, doivent communiquer entre eux indépendamment, sans passer par une couche de messagerie commune.
  • L’organisation en fonction des capacités des entreprises – au fur et à mesure, le concept de construction de systèmes au sein des différentes unités des entreprises a changé pour répondre aux exigences actuelles; De nos jours, les organisations fonctionnent sous forme de cellules; chaque unité utilisant ses propres capacités techniques pour créer des applications qui peuvent fournir des fonctionnalités à ses propres consommateurs.
    (Image: « Connected Company » – Dave Gray)
  • Endpoints intelligents et pipelines muettes – ce concept s’appuie légèrement sur une connexion de bout en bout; cependant, compte-tenu des complications potentielles qui pourraient survenir lors de la connexion des services, une couche de messagerie peut être ajoutée.
  • Gestion décentralisée – il s’agit de l’exemption de pratiques et de politiques communes, pour résoudre des besoins variés et en évolution permanente, liés aux business, en répondant aux demandes spécifiques des parties prenantes aux entreprises.
  • Gestion décentralisée des données – il s’agit d’amonceler tous types de données dans différents lieux de stockage, au lieu d’avoir une solution de stockage centralisée. Cependant, le défi reste de pouvoir retrouver des ensembles de données communes, bien qu’elles ne soient pas toutes stockées au(x) même(s) endroit(s).
    (Image: Blog de Martin Fowler)
  • L’automatisation de l’infrastructure – c’est une fonctionnalité principale et prépondérante dans l’Architecture Microservice. Elle s’appuie sur le fait que l’on puisse construire des solutions, en partant du dev. (développement), tout en poursuivant en phases de tests, pour éventuellement les passer en production. La rapidité d’implémentation de nouvelles instances est également décisive.
  • Gestion de l’échec et du bug – ce n’est pas un nouveau concept, et il est possible de coder en utilisant uniquement ce principe. Cependant, du point de vue technique de la plateforme, il faut de grandes agilité et aisance en termes de DevOps pour générer de nouvelles instances, dans le cas où une de ces dernières crasherait. Quant aux données et analyses statistiques (analytics), elles sont également importantes pour pouvoir surveiller, monitorer, anticiper, et prendre les mesures nécessaires.
  • Conception évolutive – cette idée se concentre sur le fait d’éviter de construire une solution lourde, et plutôt sur la mise en place d’un MVP (Produit Minimum Viable, Minimum Viable Product) , et son amélioration de manière itérative (qui consiste en « la mise en œuvre des séquences d’instructions répétées plusieurs fois »).

Le rôle du Middleware d’entreprise

Compte-tenu des principales caractéristiques de l’Architecture Microservice vues ci-dessus, la prochaine étape consisterait à déterminer ce qui est requis, en termes de middleware.

En ce qui concerne le fractionnement des composantes, le middleware se devra de fonctionner en hautes performances, ainsi que supporter différents types de standards de services conformes aux normes « RESTful » (un style d’architecture permettant de construire des applications Web, Intranet …) (comme « JAX-RS »). Il doit également être léger, et utiliser un minimum de ressources de l’infrastructure, fournissant ainsi un temps d’exécution rapide et performant, nécessaire pour un déploiement dynamique des services.

Du point de vue d’une adapatation aux capacités des entreprises, le middleware devra inclure une plateforme pour les différents départements d’une entreprise, qui leur permette de développer des services. Cela permet à des petites instances de développer indépendamment, grâce à des standards de développement implémentés par le middleware.

Cette deuxième illustration nous montre un exemple type d’architecture de référence à laquelle on pourrait se fier pour une transformation digitale.

Le diagramme indique les différentes capacités du middleware, comme l’API (Application Programming Interface), l’intégration, les analyses statistiques (Analytics), le middleware management, etc. qui sont fournies comme plateformes, et comment les différents départements d’une entreprise et unités d’exploitation peuvent les utiliser. Il faut savoir que certaines entreprises peuvent opter pour un déploiement où la même plateforme peut être dupliquée et exécutée pour différents départements. Mais, ce qui est important, c’est que la plateforme doit répondre à un ensemble de normes uniques, utilisées respectivement par les différents départements.

Afin de fournir un produit à l’utilisateur final, l’entreprise devra faire appel à différents types de fonctionnalités techniques. Le middleware doit alors proposer ces fonctionnalités de bout en bout, comme nous le montre cette troisième illustration :

L’entreprise doit faire appel à différentes techniques pour mener à bien diverses missions. Du SSoR (Source System Of Record), au SOR (System Of Record), tous les stockages seront accessibles, comme les données qu’ils renferment, d’où un éventuel besoin en virtualisation de données (data virtualization).

Puis, suivent alors les composants relatifs à l’Architecture Orientée Services (SOA), et l’API. Toutes les APIs et applications développées pour les consommateurs viennent ensuite. Ainsi, une unité commerciale peut créer une application et l’utiliser, si elle possède la plupart de ces fonctionnalités dans une plateforme middleware. En effet, elle permettra d’écrire facilement un code, de créer des applications, et de les fournir aux consommateurs.

Dans le cas où l’on implémente des Endpoints intelligents et pipelines muettes, le middleware doit supporter l’architecture des bus. Les schémas d’intégration d’entreprise sont utiles également, en dehors des microservices. Les systèmes existants doivent donc s’interconnecter. Les fonctionnalités d’un middleware, comme l’ESB (Enterprise Service Bus) et un agent de messages (Message Broker) jouent toujours un rôle primordial dans la prise en compte de la connectivité d’une Architecture Microservice (MSA).

Les concepts de développement API-Driven et développement multilangage dans la Plateforme 3.0 aident à résoudre les problèmes liés à une gestion décentralisée. Il existe, de nos jours, une nouvelle forme de développement, à laquelle beaucoup d’entreprises essaient de s’adapter. Il s’agit d’une innovation en matière d’informatique, conçue sur l’utilisation des appareils mobiles, les services cloud, les technologies et interactions sociales, les analyses Big Data, et l’IoT (Internet Of Things). Lorsqu’une entreprise met une API à disposition, elle offre également la liberté aux développeurs d’écrire des applications.

Même si ces développeurs utilisent des fonctionnalités avancées via l’API,  les risques sont limités, car les API sont correctement sécurisées, et leur utilisation est régie.

D’un autre côté, pour décentraliser la gestion des données, le middleware doit fournir, ou, du moins, supporter, l’Architecture Orientée Evènements (EDA=Event Driven Architecture). Par exemple, dans le cas de mises à jour de données, ou quand un ensemble différent de données doivent être actualisées, une Architecture Orientée Evènements permet d’appeler ces événements et de s’assurer que toutes les instances qui sont liées aux événements disposeront d’une correcte propagation des mises à jour. Ainsi, les fonctionnalités liées aux données, comme la sécurité de ces dernières, par exemple, peuvent être mises en œuvre dans ce type d’architecture.

Dans le cas de l’automatisation de l’infrastructure, la plateforme middleware se doit d’être conviviale, DevOps friendly, et permettre des fonctionnalités telles que les tests d’automatisation, l’intégration continue, le déploiement dans des conteneurs (containers) logiciels … .

Le déploiement du middleware se doit d’être compatible avec une disponibilité, et une évolutivité accrues. Une exécution indépendante et légère est la clé dans la mise en place rapide d’une nouvelle instance, qui doit pouvoir se lancer rapidement, et s’intégrer à un cluster existant, déjà en cours d’exécution.

Comme vu plus tôt, les analyses big data sont primordiales dans le but d’anticiper et de développer en tenant compte de potentiels bugs. Pour répondre à cette exigence, le middleware doit disposer d’une solution conviviale, et complète, et termes d’analyse de données, tout en conservant une architecture itérative et et une conception pouvant être évolutive. Pour ce faire, le middleware doit pouvoir se « brancher », et être versatile en fonction des besoins, sans affecter l’exécution de processes.

L’avantage WSO2

Pour répondre à toutes les exigences précédemment citées, les entreprises ont besoin d’une couche middleware complète, pouvant supporter différentes plateformes :

La plateforme middleware doit répondre à toutes les exigences d’intégration, et d’écriture de services, de gestion d’API, d’analyses, et de sécurité. Elle doit aussi répondre aux besoins pour des mobiles, pour l’IoT, pour les tableaux de bord (dashboards)… . De plus, elle doit pouvoir s’intégrer à divers systèmes –orientés Cloud-, par exemple.

Cette dernière illustration cartographie les capacités du middleware de WSO2, dans le même exemple d’Architecture Microservice de référence que nous avons vu plus haut. Elle nous montre comment WSO2 a créé des microservices, et des Architectures Orientées Microservices. WSO2 dispose d’un modèle de développement léger et rapideWSO2 Microservices Framework for Java, qui s’avère être la meilleure option pour créer des microservices orientés Java, dans une idée de future mise en conteneur logicielWSO2 Message Broker est utilisé pour de la messagerie et WSO2 Governance Registry sert pour le service de gestion/management des APIs. Pour utiliser toutes ces solutions comme passerelles, WSO2 API Manager est la solution pour la maintenance du composant API. Pour ce qui est de la sécurité, WSO2 dispose de WSO2 Identity Server, et, quant à la gestion de l’analyse de données, elle peut être prise en charge par le WSO2 Data Analytics Server.

Dans l’idée de connecter « l’ancien monde » au « nouveau monde » 😉, WSO2 dispose de l’ESB traditionnel (Enterprise Service Bus), qui permet l’utilisation de technologies qui viennent de « Docker« , « Kubernetes« , et « Puppet« .

WSO2 Gateway fournit également une passerelle de messagerie haute performance, légère, et dont la configuration reste basée sur des modèles de passerelles standards.

Conclusion

Dans un souci d’innovation ainsi qu’un développement rapide d’applications, une entreprise doit créer une architecture API-Driven, de plus en plus axée sur le consommateur. Elle peut, ensuite, utiliser son infrastructure et intervenir de manière dynamique sur cette dernière, en fonction de divers événements liés à l’exécution; Tout fonctionne en fonction du temps d’exécution pendant lequel les événements vont se dérouler.

Alors qu’une Architecture Orientée Microservices va devenir la voie à privilégier, les entreprises vont devoir trouver un équilibre, en intégrant certaines données dans une architecture existante. Il est important de ne pas perdre les applications existantes ainsi que certains principes clés de l’Architecture Orientée Service. Les fonctionnalités d’un middleware, comme les moteurs d’intégration, ou les différents conteneurs devront se voir inclus dans une Architecture Orientée Microservices.

Quelques rappels :

Un middleware (intergiciel) est un logiciel tiers qui crée un réseau d’échange d’informations entre différentes applications informatiques.

Une API  (Interface de Programmation Applicative, ou Application Programming Interface) peut se référer à une solution informatique qui permet à des applications de communiquer entre elles et de s’échanger mutuellement des services. Il s’agit d’un ensemble de fonctions qui facilitent, via un langage de programmation, l’accès aux services d’une application.

L’Architecture Orientée Services (SOA, ou Service Oriented Architecture) est une forme d’architecture de médiation (en flots de données) qui est un modèle d’interaction applicative qui met en œuvre différents services (composants logiciels).

Une Architecture Microservices est un style d’architecture logicielle à partir duquel un ensemble complexe d’applications est décomposé en plusieurs processus indépendants et faiblement couplés, souvent spécialisés dans une seule tâche. Les processus indépendants communiquent les uns avec les autres en utilisant des API.

Les articles que nous rédigeons sont le fruit 🍏 de plusieurs heures de dur labeur. Ainsi, nous vous serions reconnaissants de pas plagier nos travaux qui sont protégés par le droit d’auteur 📜. Toutefois, vous êtes libres de les partager ou de nous faire part de vos remarques.

Si vous avez trouvé une erreur sur cette page, vous pouvez nous en informer en sélectionnant le texte en question, et en appuyant sur Ctrl + Entrée. Merci 🙂 !

Une approche pratique de l’Architecture Orientée Microservice
5 (100%) 1 vote

Rapport de faute d’orthographe

Le texte suivant sera envoyé à nos rédacteurs :