agsandrew - stock.adobe.com
Microservices : comment choisir le bon middleware
Choisir un middleware pour les microservices nécessite une compréhension globale des objectifs. Cet article vous accompagne dans leur définition et dans la mise en œuvre.
Les micro-services reposent en quelque sorte sur un concept recyclé. Ils sont nombreux, experts développeurs ou architectes, à reconnaître dans les microservices les caractéristiques et les même objectifs que ceux données à la SOA (Architectures Orientée Services – Service Oriented Architecture). C'est également vrai pour les outils. Par conséquent, si l’on souhaite choisir, il est important de bien comprendre l’objectif premier et l’outillage des microservices et de prendre en compte les éléments spécifiques qui les rendent différents de la SOA.
L'une des principales différences entre les microservices et l'architecture SOA réside dans le fait que l'architecture SOA intègre toutes les fonctions de découverte, de sécurité et de planification. Grâce à ces fonctionnalités de base, la SOA s'adapte naturellement à un modèle unique que les développeurs peuvent déployer, sécuriser et administrer. En revanche, dans les microservices, les fonctions de découverte, de sécurité et de gouvernance font partie d'un ensemble d'outils middleware.
Les microservices ont deux objectifs principaux. L'un d’eux est de les présenter comme des composants métier liés à des processus en front-end, tels que le support des applications mobiles et les frontaux Web. Ce modèle considère davantage les microservices comme des composants SOA traditionnels. L'autre objectif, cependant, vise à utiliser les microservices comme de petits éléments fonctionnels à partager entre de nombreuses applications différentes.
Les microservices en tant que composants métier
Dans le premier cas , les microservices fonctionnent un peu comme des mini-workflow. Il est peu probable que le code soit stateless, donc il existe une file d’attente pour chaque microservice. Il est toutefois possible de retirer cette gestion du workflow du microservice et de s'appuyer sur un bus de service (ESB), qui est une partie traditionnelle d'une implémentation SOA.
Pour y remédier, vous pouvez soit rechercher des ESB qui prennent en charge les API de microservices, soit des outils de messaging et de broker d'API qui prennent en charge l'accès aux microservices. Une méthode globale centrée sur le bus doit contribuer à renforcer la sécurité et la gouvernance. Cette approche est familière à la plupart des développeurs SOA.
Si vous choisissez d'omettre le bus de messaging, le modèle de conception de microservices est peut-être pour vous. Ce modèle identifie toutes les composantes clés des microservices et assure que chaque pièce s'intègre dans une implémentation. La composante de messaging de ce modèle est particulièrement utile parce qu'elle facilite les flux de messages découplés et asynchrones entre les utilisateurs et les microservices - ou entre microservices lorsque plusieurs services sont nécessaires.
Microservices comme petits éléments fonctionnels
Le deuxième objectif des microservices porte sur les composants, l’évolutivité et la distribution. Ces microservices sont souvent beaucoup plus petits et susceptibles de représenter des tâches horizontales plutôt que des fonctions métier ou verticales. De plus, ce type de microservices nécessite probablement un fonctionnement de type stateless.
Le modèle MVC (Modèle-vue-contrôleur) est une réponse claire aux défis posés par ce deuxième objectif. MVC crée un modèle de données ou de processus et une série de vues construites par le contrôleur qui représentent les différentes utilisations. Cela peut s'appliquer facilement aux microservices.
Il est également possible de créer des applications de microservices en utilisant des outils spécifiques de contrôle d’état. Les outils cloud, comme les fonctions AWS Step Functions et Azure Logic Apps, permettent le séquençage et le contrôle d'état. Les outils middleware, comme la mise en cache des données / états de Redis, offrent quant à eux des capacités similaires pour les applications sur site et les applications cloud.
Le dimensionnement des microservices est lié au contrôle d'état. Il est important de maintenir le contexte de transaction sur plusieurs messages. Si votre entreprise applique la logique de contrôle d'état, il n'est pas difficile d'étendre cela à plusieurs instances d'un même microservice – avec du load balancing toutefois. Ceux-ci peuvent se présenter sous la forme de composants indépendants pouvant être hébergés dans le cloud.
Pour les front-end hébergés dans les clouds publics, tout d'abord, il convient de considérer les caractéristiques de la technologie propre au fournisseur de cloud. Si cela ne convient pas ou si votre entreprise prévoit un déploiement multi-cloud, un outil hébergé dans le cloud est préférable. Ce n'est pas une bonne idée de mélanger différents types de load balancers au sein d'une application, alors assurez-vous de choisir une stratégie globale.
Faire le bon choix de middleware
Une fois l’objectif défini, il y a plusieurs principes à garder à l'esprit dans le choix du middleware. Le premier principe est de choisir un middleware qui s'adapte à l'ensemble de votre déploiement de microservices.
Le deuxième principe est d'essayer de garder les fonctions d'état et de bus ou de file d'attente hors des microservices. Placez-les dans la logique principale qui invoque le microservice. Il faut enfin s’attendre à ce que les microservices évoluent vers une forme stateless. Le besoin de réutilisation de composants est ici clé.
