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.

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).

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.