zapp2photo - Fotolia

Pourquoi et comment gérer les microservices sans passerelles API

Gérer des microservices sans passerelle API est peu courant, mais pas inédit. Examinez les avantages, les inconvénients et les outils auxiliaires disponibles avant d’adopter une autre approche.

Les passerelles API sont aux microservices ce que la noix de muscade est à la purée de pommes de terre : elles vont souvent de pair.

Si les développeurs et les architectes s’appuient généralement sur des API Gateway pour réguler l’activité, celles-ci ne sont pas strictement nécessaires pour gérer les microservices. Tout comme il est possible de déguster de la purée sans noix de muscade, une application propulsée par des microservices peut fonctionner sans une passerelle API – et dans certains cas, c’est même préférable.

Sur le terrain, les entreprises déploient des microservices et des passerelles API conjointement. Dans quels scénarios est-il judicieux d’utiliser ce type d’architecture sans passerelle API ?

Microservices et passerelles API : les bases

Les microservices sont les éléments principaux d’une architecture logicielle qui divise les fonctionnalités d’une application en services distincts. Plutôt que d’exécuter les opérations dans un monolithe, les microservices permettent une approche plus modulaire et plus flexible, chaque service administrant un type de tâche différent.

Quant à une passerelle API, c’est un middleware qui facilite et rationalise la communication en servant d’intermédiaire entre les services d’application et les clients. Les API Gateway peuvent également contribuer à d’importants processus de gestion des performances et de sécurité, tels que l’équilibrage des charges entre plusieurs instances de service et le blocage des requêtes malveillantes.

Un diagramme montrant le modèle distribué ave une passerelle API.
La passerelle API réside entre les services applicatifs et les clients dans une architecture de microservices.

Comment les microservices et les passerelles API fonctionnent de concert

Une passerelle API peut simplifier les interactions entre les clients et l’application. Sur un site d’achat en ligne qui utilise des microservices, par exemple, un microservice peut afficher un inventaire des produits, un autre permet aux clients de placer des articles dans un panier et un troisième représente le service de paiement.

Un module front end qui sert à mettre un article dans un panier n’a pas besoin de se connecter directement au microservice du panier. Au lieu de cela, le module envoie une requête à la passerelle API pour indiquer que le client souhaite régler. La gateway interprète la demande et l’achemine vers le microservice qui peut l’exécuter.

Plutôt que d’exiger des microservices de décoder et de communiquer immédiatement la requête dans l’application, la passerelle API joue le rôle d’intermédiaire. Elle reçoit et transmet les requêtes, puis renvoie les résultats au client pour terminer l’échange.

Comment les passerelles API aident à gérer les microservices

Les passerelles API permettent d’organiser et de sécuriser les demandes, ce qui est bénéfique à deux égards :

  • La simplification de la conception et de la logique de l’application. Les développeurs n’ont pas besoin d’écrire la logique dans leurs applications pour accorder aux microservices la réception et l’acheminement des requêtes. La mise en œuvre de certains types de microservices peut même être totalement évitée. Par exemple, si les identités des clients peuvent être validées au sein d’une passerelle API, il n’est pas nécessaire de créer un composant dédié à cette fin.
  • La rationalisation de l’expérience client. Les passerelles API profitent aux clients en simplifiant les requêtes API, en particulier pour les systèmes qui comportent plusieurs microservices orientés clients. Au lieu d’exiger des clients qu’ils émettent des demandes API distinctes pour chaque service, une passerelle API expose une API centralisée et combinée. Avec cette approche, les clients peuvent formuler une requête et laisser la gateway sous-jacente déterminer la manière dont elle est satisfaite. Les front-ends n’ont pas nécessairement besoin d’être programmés en fonction des back-ends.

Les passerelles API peuvent fournir des fonctionnalités supplémentaires – telles que l’équilibrage de charge, l’observabilité et la limitation du débit – qui aident les équipes à administrer efficacement les applications de microservices. Ces fonctionnalités peuvent être mises en œuvre à l’aide d’outils autres que les passerelles API, mais la possibilité de répondre à divers besoins par un middleware en fait une option de gestion polyvalente au sein d’une architecture orientée microservices.

Les inconvénients des passerelles API

Les passerelles API facilitent l’interface entre les microservices back-end et les clients front-end, mais elles peuvent également réduire les performances en multipliant la complexité architecturale et opérationnelle. Il est important de prendre en compte les inconvénients possibles des passerelles API :

  • Augmentation des frais généraux. Les passerelles API ajoutent une couche supplémentaire à la pile d’hébergement d’une application, ce qui décuple la quantité de ressources d’infrastructure nécessaires pour exécuter les logiciels.
  • Complexité accrue. Les passerelles API ajoutent aussi de la complexité aux stacks d’hébergement, car elles constituent un outil supplémentaire qui doit être configuré et supervisé.
  • Problèmes de latence. Le fait de devoir transmettre les requêtes par des passerelles API peut augmenter la latence, en particulier si les gateway API sont mal paramétrées ou ne disposent pas de ressources suffisantes pour acheminer les demandes de manière efficace.
  • Risque de défaillance. Les passerelles API fonctionnent comme des centres de gestion pour les interactions entre les microservices et les clients, et une défaillance de la passerelle API peut rendre les applications inaccessibles.

Devriez-vous exécuter des microservices sans passerelle API ?

Il est juste de dire que la majorité des architectures orientées microservices d’aujourd’hui devraient être accompagnées d’une ou plusieurs passerelles API. Mais la question de savoir si les inconvénients éventuels de ces middlewares l’emportent sur leurs avantages est un sujet que chaque équipe de développement d’applications doit aborder, au cas par cas.

Pour les applications composées de quelques microservices ou qui ne doivent traiter qu’une gamme limitée de requêtes API, une passerelle peut s’avérer superflue. Les passerelles API peuvent également ne pas fonctionner correctement pour des types spécialisés de déploiements d’applications, tels que les microservices exécutés sur des équipements IoT, souvent limités en puissance de calcul ainsi qu’en espace de stockage et de mémoire. Cela dit, les frais généraux des passerelles API peuvent varier considérablement en fonction de la manière dont elles sont implémentées. Les passerelles API conteneurisées peuvent être très légères, par exemple.

Une passerelle API n’est pas nécessaire si votre application n’a pas de services orientés client, mais cela est rare pour les applications modernes dans le monde API-first d’aujourd’hui.

Les manières d’exécuter des applications microservices sans passerelles API

Dans les scénarios pour lesquels une application n’a pas suffisamment de microservices afin de justifier la surcharge et la complexité d’une passerelle API, deux approches alternatives peuvent fournir certaines des capacités de gestion des performances et de sécurité offerte par les passerelles API.

La première consiste à exécuter une application sans intermédiaire entre les clients et les microservices. Il faut pour cela s’assurer que les microservices de l’application peuvent accepter, transmettre et traiter les requêtes de manière autonome. Ce qui peut nécessiter la mise en œuvre de liens logiques plus étroits entre des microservices, voire le développement de microservices supplémentaires qui ne seraient pas nécessaires dans d’autres circonstances.

L’autre approche consiste à utiliser des outils qui ne sont pas des substituts directs des passerelles API, mais qui offrent certaines fonctionnalités équivalentes, telles que :

  • Répartiteur de charge. Déployez un équilibreur de charge entre les clients et une application pour faciliter l’acheminement du trafic. Les équilibreurs de charge ne peuvent pas interpréter et administrer les requêtes, ils ne fournissent donc pas au sens strict une gestion d’API, mais ils peuvent aider à partager le trafic de façon optimale dans une application distribuée.
  • Switch réseau/pare-feu. Il peut être possible de mettre en œuvre une limitation de débit par l’intermédiaire d’un commutateur réseau ou d’un pare-feu. Mais dans ce cas, les taux de requêtes doivent généralement être régis au niveau du protocole, au lieu de restreindre des types spécifiques de requêtes API.
  • Proxy d’API. Les proxys d’API peuvent effectuer des demandes de transfert pour des API individuelles et protéger les services back-end des requêtes directes sur les clients front-end, mais ils ne constituent pas une alternative à part entière aux passerelles API.
  • Service Mesh. Un maillage de services peut gérer les communications basées sur les API entre les microservices au sein d’une application, mais les passerelles API gèrent principalement les demandes des clients externes, tandis que les maillages de services gèrent le trafic interne.

Pour approfondir sur Architectures logicielles et SOA

Close