Acteurs de la passerelle distribuée : Gestion des API en évolution
Table des matières
F5 Avis du Bureau du CTO
L’équipe du bureau CTO de F5 explore le domaine technologique lié aux API depuis plus d’un an maintenant. Ce dernier livre blanc s’inscrit dans la continuité de nos efforts pour comprendre l’écosystème des API en constante évolution.
Les défis que nous avons détaillés dans la gestion de la prolifération des API entraîneront des défis liés à la prolifération des passerelles API, et les approches traditionnelles pour relever ces défis ne seront pas suffisantes. Bien que les technologies graphiques telles que GraphQL soient très prometteuses pour maîtriser la complexité associée aux API, elles ne constituent qu’une partie de la solution, car les défis vont au-delà de la connectivité, de la sécurité et du routage. La bonne approche, basée sur près de trente ans d’expertise en matière de mise à l’échelle de systèmes et d’applications, repose sur une architecture distribuée, et non fédérée, qui utilise GraphQL mais ne s’appuie pas uniquement sur lui.
Cet article explore une approche architecturale distribuée pour relever les défis de la prolifération des passerelles API.
Abstrait
L’économie numérique sera alimentée par les API, ce qui nous donnera une économie pilotée par les API . Suite au livre blanc sur la prolifération des API , notre objectif était de comprendre comment éliminer ou atténuer l’impact de la prolifération des API. Bien que GraphQL semble prometteur pour réduire les ramifications de la prolifération des API, il tend à imposer aux développeurs la responsabilité de réécrire une grande partie de leur base de code API. Cependant, un point de vue émergent autour de GraphQL est sa capacité à être utilisé comme un acteur de passerelle efficace. L'acteur passerelle est une fonction ou un processus créé à proximité du client qui initie une demande d'API. Cet acteur de passerelle agit comme passerelle API initiale mettant fin à la demande d'API. Il peut également être éphémère, de sorte qu'il peut être détruit après avoir traité la demande.
Outre le fait que les développeurs et les équipes d'exploitation donnent la priorité à la gestion des API par rapport aux passerelles API, nous avons également découvert le problème de la prolifération des passerelles API en raison de la prolifération des API. Du point de vue du développeur, la principale préoccupation est de garantir que l'API fonctionne correctement et en temps opportun. D’autre part, l’équipe d’exploitation se concentre davantage sur des aspects tels que la découverte, la sécurité, la convivialité et les contrôles d’accès. Les passerelles API étant aujourd’hui un élément essentiel de l’infrastructure API, il est devenu évident que la prolifération des API augmente le déploiement des passerelles API, ce qui conduit à la prolifération des passerelles API.
L’avenir de l’architecture des API doit évoluer pour accepter la prolifération des API tout en simplifiant le déploiement et les opérations. L'architecture proposée constitue la prochaine évolution des modèles de conception de passerelle API. Bien que GraphQL ne soit pas au cœur de l’architecture, ni une nécessité, il a la capacité d’améliorer le modèle d’acteur de passerelle.
Résumé
L’écosystème de gestion des API doit s’éloigner de la gestion des monolithes de passerelles API pour adopter une approche de conception de système plus contemporaine. Cela se traduira par un écosystème de gestion des API plus agile et plus efficace.
API Gateway Sprawl – Gestion des monolithes distribués
La prolifération des API, déjà un défi au sein de l'économie des API, entraîne également la prolifération des passerelles API , une situation dans laquelle la gestion des API est devenue incontrôlable en raison de la diversité des technologies des fournisseurs de passerelles API et des équipes opiniâtres qui gèrent les passerelles API. Nous nous trouvons à un point d’inflexion dans les architectures API, car la passerelle API héritée (API-GW) – une couche logicielle dédiée qui sert de point d’entrée pour les appels API – n’est plus suffisante pour gérer l’échelle et la complexité de l’écosystème API émergent.
La figure 1 illustre comment nous sommes passés de la gestion de la prolifération des API à la gestion de la prolifération des passerelles API.
Le modèle de conception ci-dessus fait allusion à un plan de contrôle centralisé, avec les passerelles API formant le plan de données distribué comme illustré dans la figure 2.
Les passerelles API sont un composant essentiel des architectures logicielles modernes, fournissant un point central de contrôle et de sécurité pour les API. Cependant, à mesure que le nombre de fonctionnalités offertes par les passerelles API a augmenté, elles sont devenues de plus en plus complexes et difficiles à gérer. Dans de nombreux cas, ces passerelles ont évolué vers des systèmes monolithiques, avec une large gamme de fonctionnalités regroupées dans un seul package.
Même si la gestion de plusieurs passerelles peut sembler être une conception distribuée, la réalité est qu’elle n’atteint pas une véritable distribution. Cela est dû au fait que les passerelles sont toujours étroitement couplées, partageant des ressources et des configurations difficiles à séparer. En conséquence, de nombreuses entreprises finissent par gérer des monolithes distribués et tous les défis que cela crée.
Architectures de passerelles API héritées
La figure 3 montre l’architecture des passerelles API existantes. Les requêtes API provenant du client sont d'abord transmises via un réseau partagé ou dédié, en passant par un pare-feu avant d'atteindre la passerelle API. La passerelle API, qui agit comme un proxy inverse, transmet ensuite le trafic à la charge de travail de l'API.
L'API-GW héritée devient un point d'étranglement de gestion des API lorsque les passerelles API sont déployées dans toute l'entreprise ou lorsque les charges de travail des API se déplacent de manière opérationnelle entre des régions, des zones, plusieurs clouds ou vers la périphérie tout en luttant contre la prolifération des API. Plusieurs API-GW sont créées par différentes équipes sans point unique de gestion et de contrôle d'entreprise. Si un individu ou un groupe de services API se déplace vers une infrastructure différente (cloud ou autre), l'équipe d'exploitation doit disposer d'une méthode pour migrer tous les aspects de la gestion des API : enregistrement, découverte, authentification, mise en réseau, sécurité et politiques de gouvernance, de risque et de conformité (GRC).
L’architecture représentée dans la Figure 3 n’est donc pas évolutive ni pratique à long terme, car au fil du temps, elle conduit à la gestion de monolithes distribués (Figure 2).
Il y a deux problèmes à l'origine du goulot d'étranglement de la passerelle API : (1) Prolifération des fournisseurs de passerelles API et (2) évolutivité au fur et à mesure lorsqu'une entreprise a plus d'applications exécutées dans plus d'endroits.
- Prolifération des fournisseurs de passerelles API : Gérer la prolifération des fournisseurs de passerelles API est un défi humain, car il peut être difficile de convaincre toutes les équipes d'adopter un seul fournisseur de passerelle API, et la migration vers un nouveau fournisseur peut être une tâche fastidieuse. Par conséquent, les organisations finissent par consacrer du temps et des ressources à la gestion de plusieurs fournisseurs de passerelles. Bien que ce problème puisse être résolu, il n’est peut-être pas entièrement réalisable dans la réalité.
- Mise à l'échelle de l'application : La mise à l'échelle des applications constitue un problème lorsque l'application doit prendre en charge davantage d'utilisateurs dans un seul emplacement ou doit être déployée sur plusieurs emplacements. Cela nécessite que l'application soit mise à l'échelle horizontalement ou verticalement. Cependant, à mesure que l'application évolue, les passerelles API doivent également évoluer et, dans certains cas, elles doivent être déployées à plusieurs emplacements pour prendre en charge la mise à l'échelle en fonction des modèles d'architecture actuels. Cela peut rendre la gestion des passerelles API complexe sur le plan opérationnel.
Solution: Un modèle d'acteur de passerelle distribuée
La figure 4 illustre un modèle d’acteurs de passerelle distribuée pour lutter contre la prolifération des passerelles API. Bien que le modèle distribué lui-même ne soit pas nouveau, cet article le formalise dans le contexte des passerelles API. Les clients initient la demande d’API. Les acteurs de passerelle distribués sont éphémères et instanciés à la demande au plus près du client. Il incombe à la couche de transport API d’envoyer la demande API de l’acteur de passerelle à la passerelle API simplifiée, qui achemine ensuite la demande vers la charge de travail API appropriée. Bien que l’utilisation du support GraphQL dans les acteurs distribués soit davantage un détail qu’une exigence pour que ce modèle fonctionne, il permet de prendre en charge des fonctionnalités telles que l’orchestration de services. Ainsi, au lieu de créer une nouvelle couche d’orchestration de services, GraphQL pourrait fournir ce support.
Pour clarifier, le sens de circulation est de droite à gauche. Autrement dit, les clients sont à droite et les requêtes API sont initiées par le client comme indiqué dans la Figure 5.
Il existe un modèle de déploiement émergent utilisant des acteurs de passerelle pour remplacer ou réduire la dépendance excessive aux passerelles API pour la gestion des API au sein et entre une entreprise. Bien que GraphQL ne soit pas nécessaire à l’architecture, son introduction est opportune car l’acteur passerelle est le bon véhicule pour prendre en charge GraphQL.
Pour acquérir une compréhension plus approfondie de l’acteur passerelle en tant que solution potentielle, il est nécessaire d’examiner de près l’état actuel des infrastructures API, en particulier des passerelles API. Cela est dû au fait que nous avons identifié l’étalement des passerelles comme un facteur important contribuant aux défis liés à l’exploitation et à la mise à l’échelle des infrastructures API.
Pour mieux comprendre les passerelles API, il est important d’examiner d’abord les différents composants de l’infrastructure de gestion des API moderne.
La figure 6 offre une représentation visuelle complète des différentes fonctionnalités et composants qui font partie intégrante de la gestion des API. Outre les passerelles API, nécessaires au routage et à la gestion du trafic vers les services back-end, il existe plusieurs autres composants d'infrastructure importants. Il peut s’agir notamment de solutions d’authentification, de limitation de débit, de mise en cache et de maillage de services. En intégrant ces fonctionnalités, les organisations peuvent contrôler leurs API, améliorer la sécurité et optimiser les performances.
Examinons les fonctionnalités communément reconnues et familières des passerelles API :
- Routage : Achemine les requêtes vers le service backend approprié en fonction du chemin ou du contenu de la requête.
- Authentification et autorisation : Authentifie et autorise les demandes en tant que point d'entrée unique, garantissant que seuls les clients autorisés peuvent accéder aux services back-end.
- Limitation de débit : Limite la vitesse à laquelle les clients peuvent effectuer des requêtes aux API sous-jacentes, évitant ainsi la surutilisation et protégeant les services back-end contre la surcharge.
- Mise en cache : Met en cache les réponses des API sous-jacentes, réduisant ainsi le nombre de requêtes à effectuer auprès des services back-end et améliorant les performances.
- Traduction du protocole : Traduit entre différents protocoles, tels que HTTP et WebSockets, permettant aux clients d'accéder aux API sous-jacentes à l'aide de différents protocoles.
- Équilibrage de charge : Distribue les requêtes à plusieurs services back-end, améliorant ainsi l'évolutivité et la fiabilité.
- Sécurité: Gère les tâches de sécurité, telles que le cryptage et le décryptage, pour garantir que les données sont transmises en toute sécurité.
- Analyse et surveillance : Suivi et rapport des mesures d'utilisation et des informations sur les erreurs, offrant une visibilité sur la manière dont le système est utilisé et aidant à identifier les goulots d'étranglement et les erreurs de performances.
- Versionnage : Gère le versionnage des API sous-jacentes, permettant aux clients d'accéder à différentes versions de l'API en fonction de leurs besoins.
- Découverte de services : Découvre les services back-end disponibles et achemine dynamiquement les demandes vers eux, permettant une découverte de services plus dynamique et plus flexible.
Après avoir analysé les fonctionnalités de l'infrastructure de gestion des API, nous avons identifié la nécessité de mieux comprendre le rôle des passerelles API et d'explorer des alternatives à la conception actuelle de la passerelle API monolithique.
Alors que la croissance du nombre d’API entraîne déjà une prolifération des API et des passerelles API, un nombre croissant de clients deviennent mobiles ou hautement distribués, et l’infrastructure de calcul est devenue disponible partout, y compris en périphérie. Nous avons donc besoin d’une approche capable d’améliorer l’agilité, la flexibilité, l’évolutivité, les performances et la sécurité de l’écosystème API.
Cette nouvelle approche nécessite une conception simplifiée capable d’exploiter pleinement les avantages d’une architecture véritablement distribuée.
Nous analysons plus en détail la fonctionnalité et la portée d'une passerelle API pour en faire ressortir les nuances et les limites.
Une passerelle API est un composant essentiel de l’infrastructure de gestion des API d’aujourd’hui. À la base, la passerelle API est un proxy inverse ; elle agit comme un intermédiaire entre les clients et les services back-end tout en effectuant diverses tâches sur la demande entrante. Par exemple, la passerelle peut authentifier, limiter le débit, demander un itinéraire, appliquer des politiques de sécurité, surveiller et appliquer le contrôle de version avant de transmettre la demande à un service back-end approprié. Une fois que le service backend a traité la demande et renvoyé une réponse, la passerelle API peut effectuer des tâches telles que la mise en cache, la traduction du protocole et la gestion des réponses avant de renvoyer la réponse au client.
À mesure que le nombre d’API a augmenté, les passerelles API ont évolué pour inclure une variété de nouvelles fonctionnalités au-delà du routage de base, devenant ainsi des systèmes monolithiques. Ces passerelles gèrent désormais des tâches telles que l’authentification et la limitation du débit pour améliorer les performances et réduire la charge sur les services back-end. Cependant, même avec ces fonctionnalités améliorées, les passerelles API restent un point d’accès unique au service backend, ce qui peut présenter des défis dans les environnements hautement distribués.
En particulier, l’essor du cloud, du multicloud hybride et des infrastructures de périphérie a rendu plus difficile le maintien de l’agilité, de la sécurité et de la facilité de gestion avec une approche de passerelle API. Les clients, les appareils et les charges de travail des applications étant potentiellement répartis sur un large éventail d’emplacements, une passerelle API peut ne pas être bien adaptée pour fournir le niveau nécessaire d’architecture conviviale.
Étant donné qu’elles gèrent un large éventail de tâches et doivent s’intégrer à plusieurs systèmes, les passerelles API sont généralement difficiles à déployer et à gérer. Bien que la gestion des passerelles API puisse être complexe, elle n'en demeure pas moins une tâche essentielle pour garantir la disponibilité, la sécurité et l'évolutivité d'une API. Les entreprises ont tendance à utiliser des outils spécialisés, tels que des plateformes de gestion d'API, pour gérer et surveiller plus efficacement leurs passerelles API.
La liste ci-dessous n'est pas exhaustive, mais certains des éléments contribuant à la complexité de la passerelle API incluent :
- Gestion de la configuration : Les passerelles API disposent souvent d'une large gamme d'options de configuration et de paramètres qui doivent être gérés et maintenus, tels que les règles de routage, la limitation de débit et les paramètres de sécurité. La gestion de ces paramètres peut être complexe et prendre du temps, en particulier lorsque le nombre d’API et de clients sous-jacents augmente.
- Intégration avec d’autres systèmes : Les passerelles doivent s’intégrer à un large éventail d’autres systèmes, tels que les systèmes d’authentification et d’autorisation, les équilibreurs de charge et les bases de données. Cela peut être complexe, en particulier lorsque les systèmes sous-jacents ne sont pas bien intégrés ou lorsque la passerelle API doit gérer plusieurs protocoles ou formats de données. Cela devient plus problématique lorsqu’une entreprise dispose de plusieurs déploiements de passerelles API provenant de plusieurs fournisseurs.
- Évolutivité et disponibilité : Les passerelles API doivent être capables de gérer un grand nombre de requêtes et de garantir une haute disponibilité, ce qui peut être complexe à gérer, en particulier lorsqu'il s'agit d'un grand nombre de services et de clients back-end.
- Sécurité : En tant que composant de sécurité API critique, les passerelles API de sécurité doivent être configurées et gérées pour garantir la protection des données sensibles et le contrôle de l'accès. Cela peut être complexe et nécessite une surveillance et une gestion continues.
- Versionnage : À mesure que le nombre d'API et de clients sous-jacents augmente, il peut devenir de plus en plus difficile de gérer différentes versions de l'API et de garantir que les clients accèdent à la bonne version.
- Surveillance et dépannage : Les passerelles API peuvent collecter et générer de grandes quantités de données. Dans une grande entreprise, les passerelles peuvent être réparties sur de nombreux sites, ce qui rend difficile la corrélation des événements affectant la santé globale de l'application et la résolution des problèmes.
Prolifération des passerelles API
La prolifération des passerelles API fait référence à la prolifération de plusieurs passerelles API indépendantes au sein d'une organisation. Différentes équipes ou unités commerciales créent souvent leurs propres API, ce qui peut conduire à la création de plusieurs passerelles API indépendantes pour gérer ces différentes API. Différentes équipes peuvent également utiliser des passerelles API de différents fournisseurs ou solutions pour gérer différents types d’API.
Cela conduit au déploiement de plusieurs passerelles API, toutes dotées de différents ensembles de capacités.
La prolifération des passerelles API crée plusieurs défis supplémentaires :
- Gestion de la passerelle API de mise à l'échelle : Le fait de disposer de plusieurs passerelles API indépendantes peut rendre difficile la gestion et la maintenance des passerelles, en particulier lorsque le nombre d'API et de clients sous-jacents augmente.
- Inefficacités dans le trafic est-ouest : Plusieurs passerelles peuvent entraîner la nécessité pour les requêtes de passer par lesdites passerelles multiples, ce qui ajoute de la latence et réduit les performances.
- Uniformité des politiques de sécurité : La gestion de plusieurs passerelles peut s'avérer difficile et peut conduire à des politiques de sécurité incohérentes, ce qui rend plus difficile de garantir la protection des données sensibles et le contrôle de l'accès.
- Gouvernance standardisée : Avec plusieurs passerelles, il peut être difficile de garantir que toutes les API sont correctement régies et conformes aux normes et aux meilleures pratiques.
- Coût accru : Avoir plusieurs passerelles peut entraîner des coûts plus élevés en termes d’infrastructure, de ressources de développement et de maintenance.
- Défis d’intégration amplifiés : Le fait d’avoir plusieurs passerelles rend plus difficile l’intégration avec d’autres systèmes et technologies, tels que d’autres bases de données, entrepôts de données et outils d’analyse de données.
Les entreprises doivent s’efforcer de centraliser leur gestion et leur gouvernance des API et d’utiliser un seul type de passerelle API. Même si cela permettra d’atténuer les défis susmentionnés liés à la prolifération des passerelles API, une stratégie homogénéisée pour les passerelles API est tout sauf simple.
Les défis de la normalisation des passerelles API dans une entreprise
À mesure que les entreprises se développent de manière organique ou par le biais d'acquisitions, les équipes internes alignées sur des unités commerciales (BU) spécifiques seront en désaccord les unes avec les autres lors de la sélection d'une technologie ou d'un fournisseur de passerelle API. Voici quelques raisons à cela :
- Technologie : Différentes équipes ou unités commerciales disposent de piles technologiques différentes ou préfèrent différentes solutions de passerelle API, ce qui rend difficile la standardisation sur un seul type de passerelle.
- Systèmes hérités : Certaines équipes disposent de systèmes existants qui ont été créés à l’aide d’un type différent de passerelle API, et il serait difficile de remplacer ces systèmes par une nouvelle passerelle, surtout s’ils sont toujours utilisés.
- Personnalisation : Certaines équipes personnaliseront leurs passerelles API existantes pour répondre à des exigences spécifiques et auront du mal à reproduire ces personnalisations sur une nouvelle passerelle.
- Coût de remplacement : Le remplacement des passerelles API existantes par une nouvelle passerelle standardisée peut être coûteux, tant en termes de développement que de maintenance.
- Formation des développeurs : Les équipes varient dans leurs niveaux d’expertise et peuvent avoir besoin de se familiariser avec une nouvelle technologie de passerelle d’un autre fournisseur ou de suivre une formation sur celle-ci, un processus qui peut être à la fois long et coûteux.
- Ressources limitées : Les organisations disposent de ressources limitées en termes de développeurs, de budget et de temps pour effectuer le changement, ce qui rend difficile la mise en œuvre d’une nouvelle passerelle.
- Dépendances de l'application : Différentes équipes ou unités commerciales ont des dépendances différentes sur leurs passerelles existantes, comme l'intégration à des systèmes spécifiques ou d'autres intégrations personnalisées, ce qui rend difficile le passage à une nouvelle passerelle.
- Solutions tierces : Les équipes utilisant des solutions tierces qui s’intègrent à la passerelle auront du mal à migrer vers une nouvelle solution qui ne prend pas en charge ces solutions tierces.
Ainsi, si une application existante dispose d’une équipe bien établie et avisée, l’équipe ne voudra pas pivoter vers un modèle de déploiement différent afin de ne pas perturber son service.
Nous pouvons donc conclure qu’il est nécessaire d’adopter une nouvelle approche qui prenne en compte les multiples limitations de l’infrastructure API existante tout en soulignant la prolifération des passerelles API comme l’une des considérations les plus importantes.
Considérations relatives à la conception
La liste suivante n’est pas exhaustive, mais résume certaines des considérations de conception de haut niveau qui, selon nous, devraient être intégrées lors de la création de la solution :
- Coexister avec les déploiements actuels : Alors que les organisations s’efforcent de suivre l’évolution constante du paysage technologique, il est courant que les entreprises disposent d’une gamme diversifiée de déploiements de passerelles API. Il n’est pas possible de déplacer l’infrastructure API existante, car cela peut perturber les opérations commerciales critiques. Ainsi, tout nouveau déploiement doit être conçu de manière à pouvoir coexister avec l’architecture actuellement déployée.
- Standardiser les fonctions de passerelle API : L’objectif principal de la stratégie API d’une entreprise doit être de standardiser les fonctionnalités de sa passerelle API, ce qui peut être une tâche difficile en raison de la diversité des API et des besoins variés des différentes unités commerciales. Néanmoins, cette standardisation est cruciale pour créer une infrastructure stable et sécurisée capable de soutenir la transformation numérique de l’organisation.
- Tirez parti des déploiements Edge : L’infrastructure de périphérie a non seulement le potentiel d’augmenter de manière exponentielle le nombre d’API, mais offre également aux entreprises la possibilité de rapprocher leurs acteurs de passerelle de la périphérie. Cela est possible car la même infrastructure utilisée pour créer des API peut également être utilisée pour créer des acteurs de passerelle distribués. Par conséquent, la solution doit exploiter pleinement la proximité de l’infrastructure de périphérie avec les clients qui initient la demande d’API.
- Transport agnostique : Une considération importante pour la mise en œuvre de l’architecture des acteurs de passerelle distribuée est qu’elle ne doit pas dépendre d’un mécanisme de transport spécifique. Qu'une entreprise souhaite utiliser des réseaux IP traditionnels, des réseaux superposés, des VPN ou une infrastructure de messagerie à faible latence, la solution doit être indépendante du mécanisme de transport. Cela permet une plus grande flexibilité et permet aux entreprises de choisir le mécanisme de transport qui correspond le mieux à leurs besoins et exigences spécifiques.
- Prise en charge de GraphQL : GraphQL devient un choix de plus en plus populaire pour le développement d'API en raison de ses nombreux avantages par rapport aux API REST traditionnelles. L’un de ses principaux avantages est sa capacité à fournir un accès précis aux données, permettant aux clients de spécifier exactement les données dont ils ont besoin dans une seule demande. De plus, GraphQL peut simplifier le processus d’agrégation de données provenant de plusieurs services, ce qui en fait l’architecture idéale pour la composabilité et l’orchestration des services. Cela peut réduire la surcharge du réseau et améliorer les performances, en particulier dans un système distribué où plusieurs services API sont utilisés pour répondre à une seule demande. Enfin, avec son schéma fortement typé et son langage de requête, GraphQL peut améliorer la découvrabilité des API et permettre un développement client plus facile.
- La sécurité est un enjeu majeur : L’objectif primordial de la conception est qu’elle s’ajoute à la posture de sécurité des API de l’entreprise. La solution pourrait intégrer certaines fonctionnalités, comme la possibilité d’authentifier et d’autoriser les requêtes API, de mettre en œuvre des contrôles d’accès et de se protéger contre les menaces de sécurité courantes telles que les attaques de script intersite (XSS) et d’injection SQL. En aucun cas, la nouvelle solution ne doit compromettre le modèle de menace existant ou le modifier de manière si importante que la surface d’attaque change. En donnant la priorité à la sécurité comme objectif de conception, l’architecture doit fournir un environnement plus sécurisé pour la communication API, réduisant ainsi le risque de violations de données et d’autres incidents de sécurité.
Des exigences spécifiques peuvent être dérivées de ces considérations de conception, que nous avons intégrées dans notre solution d'acteurs de passerelle distribuée (DGA).
Acteurs de la passerelle distribuée
Après avoir maintenant pleinement exploré les passerelles API, nous pouvons expliquer la solution d’acteur de passerelle distribuée.
Conception des acteurs de la passerelle distribuée
Le modèle de conception des acteurs de passerelle distribuée (DGA) s'inspire de l'informatique de pointe et de l'informatique disponible à proximité d'un client. L’essentiel de l’idée réside dans l’hyper-distribution de chaque acteur de passerelle aussi près que possible du client et dans le fait que l’acteur de passerelle n’existe que pendant la durée de la transaction avant qu’elle ne soit compensée à la fin.
Hypothèses
Voici quelques-unes des hypothèses sous-jacentes à cette solution.
Le calcul en périphérie est devenu plus répandu et nous pouvons désormais trouver un type de calcul géographiquement disponible plus près du client. Les acteurs de la passerelle peuvent être instanciés sur ces nœuds de calcul de périphérie. L’objectif est d’avoir une implémentation où le DGA est très léger et éphémère afin qu’il puisse être instancié sur n’importe quel calcul de périphérie.
Le transport API est un élément crucial de l’infrastructure car il implique l’établissement d’un réseau entre les acteurs de la passerelle et la passerelle API. Le type d’infrastructure requis dépend du fournisseur ou de l’entreprise et peut varier. Par exemple, un grand cloud public peut utiliser sa propre dorsale pour exécuter le transport d’API. Une autre implémentation pourrait être un bus de messagerie à faible latence superposé sur un réseau existant à bande passante élevée et à faible latence au sein d’un centre de données d’entreprise.
Fonctions de la passerelle API
Pour réitérer, la passerelle API est essentiellement un proxy inverse dont la fonction principale est d’acheminer le trafic HTTP vers les charges de travail API appropriées. Cette approche est logique lorsque toutes les API sont regroupées, comme au sein d’un réseau local sur site ou au sein d’un cloud privé virtuel (VPC) à l’intérieur d’une zone de disponibilité. Mais à mesure que le nombre d'API augmente, se déplace sur une infrastructure hybride ou devient simplement mobile, cette approche de conception de passerelle API devient inefficace, complexe à exploiter et coûteuse.
Bien qu’il puisse y avoir des points de vue différents sur la manière de classer toutes les fonctionnalités décrites dans la figure 6, nous pouvons convenir que l’infrastructure de gestion des API est devenue un déploiement complexe de nombreux composants qui doivent être soigneusement orchestrés.
La figure 7 illustre les différentes fonctionnalités et fonctions de la gestion des API de la figure 6 à l’architecture des acteurs de la passerelle distribuée. Cette cartographie illustre visuellement comment chaque fonctionnalité et fonction est alignée sur l'approche DGA, mettant en évidence l'intégration transparente des composants de gestion des API au sein de l'architecture.
Fonctions centralisées
La plupart des fonctionnalités répertoriées ci-dessus ont un composant de gestion qui peut être centralisé de manière logique. Notre objectif n’est pas de réarchitecturer le plan de gestion mais, si possible, de supprimer certaines fonctions.
Fonctions principales de la passerelle API
Il s’agit de fonctions de plan de données et donc mieux implémentées dans l’API et colocalisées avec les charges de travail de l’application. Les passerelles API sont un composant essentiel de l’architecture de microservices moderne qui sert de point d’entrée pour tout le trafic externe. Nous avons catégorisé ses fonctions principales pour inclure le routage, l'équilibrage de charge, le routage dynamique, la vérification de l'état, les nouvelles tentatives et les replis.
Une passerelle API dirige les requêtes entrantes vers le microservice approprié, répartit le trafic sur plusieurs instances, prend en charge le routage dynamique, surveille l'état des microservices et de leurs instances, réessaye les requêtes ayant échoué et fournit des réponses de secours lorsqu'un microservice n'est pas disponible ou a échoué. D'autres fonctions telles que l'authentification, l'autorisation, la limitation du débit, la mise en cache et la journalisation peuvent être distribuées aux fonctions périphériques ou centralisées en fonction des exigences spécifiques du système.
Cette approche modulaire permet une architecture plus flexible et optimisée et est au cœur de notre recommandation pour simplifier, moderniser et faire évoluer l’infrastructure API de l’entreprise.
Confondus
La passerelle API et la gestion des API sont souvent confondues à tort par les fournisseurs comme faisant partie de la fonction de passerelle API, mais il s'agit en fait de deux fonctions distinctes qui doivent être traitées séparément. Une passerelle API est chargée d'acheminer les demandes des clients vers les services back-end, tandis que la gestion des API englobe un ensemble plus large de fonctionnalités telles que le contrôle d'accès, la limitation du débit, l'analyse et la gestion du portail des développeurs.
Bien que certains fournisseurs puissent proposer à la fois des fonctions de passerelle API et de gestion des API dans le cadre d'un seul produit, il est important de comprendre les différences entre ces fonctions et de les évaluer séparément en fonction de leurs besoins spécifiques. La combinaison de ces fonctions peut entraîner une confusion et potentiellement limiter la flexibilité et l'évolutivité de l'infrastructure API d'une organisation. Ceci est également essentiel pour comprendre notre position sur la distribution de la fonctionnalité de passerelle API.
Gateway Actor – Fonctionnalités en ligne
Les fonctionnalités répertoriées ici sont des fonctions principales qui doivent être intégrées au chemin de données. Dans un modèle de passerelle distribuée, certaines des fonctions en ligne de la passerelle API deviennent également distribuées. Ces fonctions incluent le contrôle d'accès, la limitation du débit, la validation des demandes, l'analyse des API, les rapports d'utilisation, la surveillance du taux d'erreur, les alertes et les événements, l'intégration de l'authentification, l'intégration de tiers, l'intégration de la surveillance et de la journalisation, la mise en cache de périphérie et la compression.
Le déplacement de ces fonctions vers le modèle de passerelle distribuée présente les avantages suivants :
- Charge réduite sur la passerelle API : Aidez à réduire la charge sur la passerelle API centralisée et à améliorer les performances et l'évolutivité du système.
- Activer des temps de réponse plus rapides : Activez des temps de réponse plus rapides et une latence réduite en déployant ces fonctions plus près des clients. En tirant parti de la mise en cache des données et de la fonction, les passerelles API hébergées en périphérie peuvent répondre rapidement aux demandes entrantes.
Par exemple, le contrôle d’accès, la limitation du débit et la validation des demandes peuvent être gérés par un acteur de passerelle de périphérie, qui est déployé plus près des clients. Cela peut aider à réduire le nombre de requêtes devant être traitées par la passerelle API centralisée, améliorant ainsi ses performances et son évolutivité. De même, les analyses d’API, les rapports d’utilisation, la surveillance du taux d’erreur, les alertes et les événements, ainsi que l’intégration de la surveillance et de la journalisation peuvent être gérés par des passerelles périphériques, qui peuvent collecter et agréger des données à partir de plusieurs microservices.
Acteurs de la passerelle – Candidats GraphQL
Aujourd’hui, une capacité importante prise en charge par les passerelles API est la composition et l’orchestration des services. Bien que cela puisse devenir assez complexe, cela deviendrait un problème si cette fonctionnalité n’était pas prise en charge par la passerelle API simplifiée. Nous pensons que GraphQL peut être une approche intéressante pour la composition de services, agissant comme une sorte de middleware pour les API existantes.
En raison de sa visibilité sur toutes les API, la passerelle API devient un endroit logique pour effectuer la composition de services, permettant aux développeurs de combiner les API derrière la passerelle pour améliorer la logique métier sans avoir besoin d'écrire de nouveaux services qui peuvent être plus facilement combinés dans une couche de composition de services.
La composition de services dans GraphQL est rendue possible grâce à l'utilisation d'un schéma fortement typé, qui définit la forme des données disponibles pour les clients. Les clients peuvent utiliser ce schéma pour construire des requêtes qui spécifient les données exactes dont ils ont besoin, quels que soient les services ou les sources qui les fournissent. Les résolveurs, qui sont des fonctions qui mappent les requêtes aux sources de données, sont utilisés pour récupérer les données du service ou de la source appropriée. Cependant, même si GraphQL promet une meilleure sécurité, celle-ci n’est efficace que si le développeur qui écrit le code est bon.
Autres fonctionnalités et fonctions
Il reste encore quelques fonctionnalités non mises en évidence dans la figure 6 : Fonctionnalités de gestion et d'infrastructure des API . Ces fonctionnalités et fonctions restantes sont des candidats qui peuvent être déplacés vers des fonctions de gestion et d'exploitation individuelles ou vers des fonctions de plan de données.
Nous choisissons délibérément d’utiliser le terme « acteur » pour éviter de suggérer une implémentation ou une technologie de fournisseur spécifique. L’implémentation de l’acteur de passerelle peut être basée sur des méthodes, des fonctions, des travailleurs, des threads et des processus, implémentés à l’aide d’infrastructures basées sur des machines virtuelles, des conteneurs, sans serveur ou d’autres approches spécifiques à un fournisseur.
Caractéristiques et comportement du composant
L’approche adoptée avec l’architecture des acteurs de passerelle distribuée (DGA) simplifie les fonctions de passerelle API et déplace d’autres fonctionnalités en ligne soit vers la périphérie, soit vers le plan de contrôle.
Plan de contrôle
Outre les fonctionnalités de la passerelle API, l’architecture DGA recommande également d’identifier les fonctions qui pourraient être mieux servies dans le plan de contrôle en tant que composant logiquement centralisé plutôt qu’implémentées dans une passerelle API monolithique. La gestion et le contrôle de l’infrastructure API déjà existante peuvent être étendus et développés pour inclure cette fonctionnalité supplémentaire.
Passerelle API simplifiée
La simplification de la passerelle API devient ainsi un exercice visant à dériver un ensemble standard de fonctions de base que tous les fournisseurs de passerelles API peuvent gérer via un ensemble commun de paramètres de configuration.
Une entreprise souhaitant réaliser cette transformation pourrait déployer l’architecture DGA une application à la fois, sans perturber les déploiements existants et sans avoir recours à une opération de manutention.
Acteurs de la passerelle distribuée
Un aspect important du DGA est que chaque acteur de passerelle est éphémère, étant instancié uniquement pour la durée d'une session API (c'est-à-dire, un client effectuant un appel API).
Un acteur de passerelle distribué peut être plus flexible, évolutif et rentable que la passerelle API traditionnelle. Plutôt que de s'appuyer sur plusieurs passerelles API monolithiques de différents fournisseurs pour agréger et gérer le trafic API, l'acteur de passerelle permet aux développeurs de spécifier et de déployer des instances de passerelle individuelles pour chaque API plus proche de la périphérie du réseau. Les API elles-mêmes pourraient offrir un meilleur contrôle et une meilleure personnalisation pour répondre à leurs besoins spécifiques.
Cette nouvelle approche permet également une plus grande évolutivité, car les développeurs peuvent facilement faire tourner les instances d’acteur de passerelle selon les besoins pour gérer l’augmentation du trafic sans se soucier des frais généraux liés à la gestion d’une passerelle centralisée de grande taille.
Outre ses avantages techniques, l'acteur de passerelle offre également des économies de coûts par rapport à la passerelle API traditionnelle, en permettant aux entreprises de ne payer que pour les instances d'acteur de passerelle éphémères qu'elles utilisent. Ce modèle de déploiement peut ouvrir des opportunités pour des modèles de revenus supplémentaires.
Placement des acteurs de la passerelle
En exploitant une couche de transport API, les DGA découplent essentiellement l’emplacement d’entrée de l’API de la passerelle API. Les DGA peuvent être déplacés vers la périphérie, c'est-à-dire plus près du client effectuant l'appel d'API. Les API peuvent se terminer dans les DGA et être ensuite transportées par n'importe quel moyen. Ceci est différent de la figure 3 : Architectures de passerelle API héritées où le trafic client entre topologiquement à côté des passerelles API.
Conclusion
Notre intention a donc été de proposer une approche indépendante du fournisseur et du déploiement, car différents fournisseurs peuvent avoir leur propre propriété intellectuelle pour créer ces composants afin d'atteindre des objectifs similaires à ceux décrits.
Dans cet article, nous avons résumé nos apprentissages issus de plusieurs études sur la prolifération des API , les architectures Edge 2.0 , l’ économie des API et les enquêtes sur GraphQL. Bien que le jury n’ait pas encore rendu son verdict concernant l’infrastructure API existante, nous pensons qu’une nouvelle approche est nécessaire.
La simple promesse de débloquer de la valeur au sein de chaque appareil ou entité individuelle à l’échelle mondiale constitue une raison suffisante pour explorer une nouvelle approche. Nous devons aujourd’hui nous éloigner de l’infrastructure API héritée, car même si elle semble distribuée, elle est monolithique sous le capot.
Nous proposons l'approche d'acteur de passerelle distribuée basée sur GraphQL comme un moyen indépendant du fournisseur pour libérer tout le potentiel de l'économie émergente des API.