Dans le cadre des applications utilisant une architecture microservices, il est possible de faire communiquer directement clients et microservices. Pourtant, ce fonctionnement est préférable et plus adapté dans le cadre d’application au domaine fonctionnel restreint. Plus le nombre de microservices mis à disposition sera important plus il sera compliqué de savoir quel microservice devra être appelé ; et ce d’autant plus que, souvent, un client devra appeler plusieurs microservices pour collecter l’ensemble des données nécessaire au fonctionnement de l’application.
Pour optimiser le fonctionnement de l’application, il faudra se poser plusieurs questions incluant celles-ci : comment limiter le nombre de requêtes envoyées au backend ? comment gérer des problèmes tels que la sécurité, les transformations de données ou encore l’utilisation de protocoles non compatibles internet ?
Pour gérer ces différentes problématiques on peut faire usage d’une passerelle d’API ou API Gateway.

Dans cet article, nous verrons:

1. Qu’est-ce qu’une API Gateway ?
2. Pourquoi utiliser une Passerelle d’API plutôt qu’une communication directe de client à API ?
3. Pourquoi utiliser une API Gateway dans une architecture microservices ?
4. Les limites de l’API Gateway dans une architecture Microservices
5. Mise en place de la passerelle d’API

Qu’est-ce qu’une API Gateway ou passerelle d’API ?

Une API Gateway est une passerelle entre les API exposées par des microservices (ou une application) et un front consommant ces API

Elle peut potentiellement avoir plusieurs rôles :

• Agréger ou désagréger différentes API
• Réaliser la transformation de protocoles ou de données, l’utilisation de protocoles non compatibles internet, la distribution de données sur différentes API mais aussi la mise en cache et l’orchestration des différentes API.
• Centraliser l’implémentation de la sécurité évitant ainsi de le faire au niveau des API du serveur applicatif,
• Participer à la disponibilité et l’évolutivité de l’application
• Contribuer à la simplicité de la consommation des API par les consommateurs

Pourquoi utiliser une API Gateway plutôt qu’une communication directe de client à API

Plus le nombre d’API mises à disposition est important plus il est compliqué de savoir quelle API devra être appelée ; et ce d’autant plus que, souvent, un client appelle plusieurs API pour collecter l’ensemble des données nécessaire au fonctionnement de l’application

Sans passerelle d’API, les applications clients envoient les requêtes directement aux API avec les incidences suivantes :

• Les applications doivent connaître précisément tous les services pour pouvoir les appeler.
• Cela augmente potentiellement la latence réseau en obligeant la multiplication des aller-retours entre l’application cliente et le backend.
• Garantir la sécurité des données est également plus compliqué puisque tous les services se retrouvent exposés publiquement, augmentant ainsi le risque d’attaque : Pour pallier ce risque, il est nécessaire d’implémenter certaines fonctionnalités qui viendront s’assurer que la sécurité est bien prise en compte, avec un risque de complexification de l’implémentation et de maintenabilité sur le long terme.

En outre, dans la mesure où l’API Gateway fait abstraction de l’implémentation réelle du ou des services, elle permet de potentiellement présenter aux consommateurs uniquement les infos nécessaires, et aussi de gérer plus simplement le versioning des API

Pourquoi utiliser une API Gateway dans une architecture microservices ?

Le rôle de la passerelle API est multiple. Elle permet d’agréger différents microservices mais également de réaliser la transformation de protocoles ou de données ou encore de distribuer ces données sur différents microservices.

Sans API Gateway, les applications doivent connaître précisément tous les services pour pouvoir les appeler. Cela augmente potentiellement la latence réseau en obligeant la multiplication des aller-retours entre l’application cliente et le backend. Garantir la sécurité des données est également plus compliqué puisque tous les microservices se retrouvent exposés publiquement, augmentant ainsi le risque d’attaque. Pour palier à ce risque, il est nécessaire d’implémenter certaines fonctionnalités qui viendront s’assurer que la sécurité est bien prise en compte. Comme ces fonctionnalités doivent être prévues pour tous les microservices, cela complexifie fortement l’implémentation et la maintenabilité sur le long terme.

Utiliser une Passerelle d’API permettra de simplifier les évolutions d’architecture ou d’application puisqu’elle fait abstraction de l’implémentation réelle du ou des microservices. En faisant abstraction de l’implémentation réelle du(des) microservice(s) voir en appelant des anciennes applications dans des architectures de types monolithique par exemple, elle peut permettre de standardiser le message de retour tout en permettant d’appeler différents types de services, API, SOAP, REST et d’autres outils ou protocoles non ouverts sur le web.

L’agrégation des requêtes sera faite directement au travers de l’API Gateway, cela permet de réduire la charge réseau et la multiplication des appels ce qui peut s’avérer important dans certaines applications comme par exemple les applications mobiles ou encore les SPA (Single Page Application).

Les limites de l’API Gateway dans une architecture Microservices

Il est nécessaire :

1. De définir au préalable comment les API seront exposées à divers acteurs comme les développeurs internes, partenaires et tiers et de prévoir une documentation pour faciliter l’adoption et l’utilisation
2. De répliquer et « Load Balancer » l’API Gateway pour éviter de devenir le « Single Point Of Failure » de l’application. Ainsi, elle ne doit pas non plus devenir monolithique et regrouper l’ensemble des appels vers les services.
3. De séparer les API par domaine fonctionnel et par utilisation, voire par plateforme (desktop, web, mobile) pour équilibrer la charge et avoir les justes données à fournir au client et éviter ainsi un éventuel goulot d’étranglement

Une passerelle d’API nécessite des coûts de développement supplémentaires et une maintenance ultérieure si elle inclut une logique personnalisée et effectue une agrégation des données.

A contrario, si la passerelle d’API applique simplement la sécurité, la journalisation et la gestion des versions (comme quand vous utilisez Gestion des API Azure), ces coûts de développement supplémentaires peuvent ne pas s’appliquer

Une passerelle d’API peut introduire des temps de réponse accrus en raison de l’appel réseau supplémentaire. Cependant, cet appel supplémentaire a généralement moins d’impact qu’un client de l’interface qui émet trop de communications en appelant directement les services internes.

Mise en place de la passerelle d’API :

L’API Gateway se doit d’être indépendante et se place entre le client et le backend. En tant que couche d’abstraction des microservices, elle agit comme un proxy inversé en redistribuant les requêtes vers les différents microservices correspondants. Elle devient donc un point d’entrée à l’application. Il est possible d’implémenter, dans cette couche, des fonctionnalités supplémentaires comme l’authentification, le cache ou encore la sécurité (SSL par exemple).

L’API Gateway se doit également d’être répliquée et « Load Balancée » pour éviter de devenir le « Single Point Of Failure » de l’application. Ainsi, elle ne doit pas non plus devenir monolithique et regrouper l’ensemble des appels vers les microservices. Les API Gateway pourront être séparées par domaine fonctionnel et par utilisation, voire par plateforme (desktop, web, mobile). Cela permettra d’équilibrer la charge et d’avoir les justes données à fournir au client.

Les implémentations d’authentification ou de cache peuvent être déléguées à la Gateway évitant par la même occasion une implémentations propre à chaque microservice ce qui améliore les délais d’implémentation en réduisant la charge, facilite l’écriture et la lecture du code des microservices en externalisant certaines portions, facilite l’évolutivité puisque ces implémentations sont « centralisées » donc plus faciles à faire évoluer et les microservices s’abstenant de ces implémentations sont eux aussi plus faciles à maintenir et à faire évoluer.

L’API Gateway, si correctement implémentée, produit de nombreux avantages. Il existe malgré tout des risques tels que devenir un point de défaillance centralisé (Single Point Of Failure), l’API Gateway peut aussi devenir un goulot d’étranglement de l’application.

Il existe des solutions spécifiquement dédiées aux environnement Microsoft telles qu’Azure API Management pour Azure ou encore Ocelot pour .Net Core.