Table des matières
L’avis du bureau du CTO F5
Le bureau du 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 évoqués concernant la gestion de la multiplication des API entraînent d’autres défis, liés à la prolifération des passerelles API, et les approches traditionnelles pour les relever ne sont 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 sont qu’une partie de la solution, car les problèmes dépassent le cadre de la connectivité, de la sécurité et du routage. La bonne approche, basée sur près de trente ans d’expertise dans la mise à l’échelle des systèmes et des applications, repose sur une architecture distribuée – et non fédérée – qui utilise GraphQL mais n’en dépend pas uniquement.
Cet article explore une approche architecturale distribuée pour relever les défis de la prolifération des passerelles API.
Résumé
L’économie numérique sera alimentée par des API. Suite au livre blanc sur la multiplication des API, notre objectif était de comprendre comment éliminer ou atténuer l’impact de la prolifération des API. Si GraphQL semblait promettre de réduire les ramifications de l’étalement de l’API, il a tendance à imposer aux développeurs de réécrire une grande partie de leur base de code API. Cependant, un autre point de vue émerge autour de GraphQL, concernant sa capacité à être utilisé comme acteur de passerelle efficace. L’acteur de passerelle est une fonction ou un processus créé près du client qui initie une demande d’API. Cet acteur de passerelle agit comme la passerelle API initiale en mettant fin à la demande d’API. Il peut également être éphémère, de sorte qu’il peut être détruit une fois la requête traitée.
Outre le fait que les développeurs et les équipes opérationnelles privilégient la gestion des API par rapport aux passerelles API, nous avons également découvert le problème de la prolifération des passerelles API, effet direct de la multiplication des API. Du point de vue du développeur, la principale préoccupation est de s’assurer que l’API fonctionne correctement et en temps voulu. D’autre part, l’équipe des opérations se concentre davantage sur des aspects tels que la découverte, la sécurité, la convivialité et les contrôles d’accès. Étant donné que les passerelles d’API forment aujourd’hui un composant essentiel de l’infrastructure d’API, il est devenu évident que la prolifération des API accélère le déploiement des passerelles d’API – et donc leur étalement.
L’architecture API doit évoluer pour prendre en compte la prolifération des API tout en simplifiant le déploiement et les opérations. L’architecture proposée est la prochaine évolution que doivent viser les modèles de conception de passerelle API. Même si GraphQL ne joue pas un rôle central dans l’architecture – et même s’il n’est pas indispensable – 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 passerelles API monolithiques pour adopter une approche de conception plus contemporaine. Cela se traduira par un écosystème de gestion des API plus agile et plus efficace.
La prolifération des passerelles API – Gestion des monolithes distribués
La multiplication des API, déjà un défi dans l’économie des API, entraîne également une expansion de la passerelle API, une situation où la gestion des API est devenue incontrôlable en raison de la multiplicité des technologies des fournisseurs de passerelles API et des équipes inflexibles qui gèrent les passerelles API. Nous sommes à un point d’inflexion dans les architectures d’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 d’API – n’est plus suffisante pour gérer l’échelle et la complexité de l’écosystème d’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é, les passerelles API formant le plan de données distribué, comme le montre la figure 2.
Les passerelles API forment un composant essentiel des architectures logicielles modernes, fournissant un point de contrôle et de sécurité central pour les API. Cependant, avec l’augmentation du nombre de fonctionnalités offertes par les passerelles API, celles-ci 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 un large éventail de fonctionnalités regroupées dans un seul package.
Bien que la gestion de plusieurs passerelles puisse avoir l’apparence d’une conception distribuée, la réalité dit autre chose. En effet, 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, avec tous les défis qui en découlent.
Architectures de passerelle API héritées
La figure 3 montre l’architecture des passerelles API actuelles. Les requêtes d’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 en tant que proxy inverse, transmet ensuite le trafic à la charge de travail de l’API.
La passerelle API traditionnelle devient un point d’étranglement de la gestion des API lorsque les passerelles API sont déployées dans l’entreprise ou lorsque les charges de travail de l’API se déplacent de manière opérationnelle entre différentes régions et zones, entre plusieurs clouds ou vers la périphérie. Différentes équipes créent de multiples passerelles API sans point unique de gestion ni de contrôle de l’entreprise. Si un service ou un groupe de services API se déplace vers une autre infrastructure (cloud ou autre), l’équipe opérationnelle 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 à 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).
Deux problèmes créent le point d’étranglement de la passerelle API : (1) la prolifération des fournisseurs de passerelles API et (2) la mise à l’échelle progressive, à mesure qu’une entreprise exécute davantage d’applications dans davantage d’endroits différents.
- Prolifération des fournisseurs de passerelles API : faire face à l’étalement 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 passerelles API, et la migration vers un nouveau fournisseur peut être une tâche fastidieuse. Pour ces raisons, les entreprises finissent par perdre du temps et des ressources à gérer plusieurs fournisseurs de passerelles. Même si ce problème peut être résolu, cela reste parfois difficile à concrétiser.
- Mise à l’échelle des applications : la mise à l’échelle d’une application est un problème lorsqu’elle doit prendre en charge plus d’utilisateurs sur un seul site ou doit être déployée sur plusieurs sites. L’application doit évoluer horizontalement ou verticalement. Cependant, les passerelles API doivent également évoluer en parallèle et, dans certains cas, elles doivent être déployées à plusieurs endroits, d’après les 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é
La figure 4 représente l’utilisation d’un modèle d’acteurs de passerelle distribuée pour traiter 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ée sont éphémères et instanciés à la demande au plus près du client. Il incombe ensuite à la couche de transport API d’envoyer la demande d’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 la prise en charge de GraphQL dans les acteurs distribués soit plus un détail qu’une exigence pour que ce modèle fonctionne, elle rend possibles des fonctionnalités telles que l’orchestration de services. Ainsi, au lieu de créer une nouvelle couche d’orchestration de services, GraphQL peut assumer cette fonction.
Pour clarifier, le schéma de circulation va de droite à gauche. Autrement dit, les clients sont à droite et les requêtes d’API sont initiées par le client comme le montre la figure 5.
Il existe un modèle de déploiement émergent qui utilise des acteurs de passerelle pour remplacer ou réduire la dépendance excessive vis-à-vis des passerelles d’API pour la gestion des API au sein d’une entreprise. Bien que GraphQL ne soit pas indispensable à l’architecture, son introduction arrive à point nommé, car l’acteur de passerelle est le bon véhicule pour prendre en charge GraphQL.
Pour mieux comprendre en quoi l’acteur de passerelle peut être une solution potentielle, il faut examiner de près l’état actuel des infrastructures d’API, en particulier des passerelles d’API. En effet, nous avons identifié la prolifération des passerelles comme un facteur important dans les défis de l’exploitation et de la mise à l’échelle des infrastructures API.
Pour mieux comprendre les passerelles API, il est important d’examiner en premier lieu les différents composants de l’infrastructure moderne de gestion des API.
La figure 6 offre une représentation visuelle complète des différentes fonctionnalités et composants qui composent la gestion des API. En plus des passerelles API, qui sont nécessaires pour le routage et la gestion du trafic vers les services back-end, il existe plusieurs autres composants d’infrastructure importants. Ceux-ci peuvent inclure des solutions d’authentification, de limitation de débit, de mise en cache et de maillage de service, entre autres. 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 admises des passerelles API :
- Routage : achemine les requêtes vers le service back-end 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 du débit : limite le rythme auquel les clients peuvent faire des requêtes aux API sous-jacentes, empêchant la surutilisation et protégeant les services back-end de la surcharge.
- Mise en cache : met en cache les réponses des API sous-jacentes, réduisant ainsi le nombre de requêtes à adresser aux services back-end afin d’améliorer les performances.
- Traduction de protocole : effectue des traductions entre différents protocoles, tels que HTTP et WebSockets, pour permettre aux clients d’accéder aux API sous-jacentes en utilisant différents protocoles.
- Équilibrage de charge : distribue les requêtes à plusieurs services dorsaux, améliorant ainsi l’évolutivité et la fiabilité.
- Sécurité : gère les tâches de sécurité, comme le chiffrement et le déchiffrement, pour sécuriser la transmission des données.
- Analyse et surveillance : suit et rapporte les indicateurs d’utilisation et les informations sur les erreurs, offrant ainsi une visibilité sur la façon dont le système est utilisé et aidant à identifier les goulots d’étranglement et les erreurs de performance.
- Gestion des versions : assure la gestion de version 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 dorsaux disponibles et y achemine dynamiquement les demandes, ce qui permet 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 compris qu’il était nécessaire de mieux comprendre le rôle des passerelles API et d’explorer des alternatives à la conception actuelle de passerelles API monolithiques.
L’augmentation du nombre d’API alimente déjà leur prolifération et celle des passerelles API. De plus en plus de clients misent sur la mobilité et des environnements hautement distribués, et l’infrastructure de calcul est aujourd’hui disponible partout, y compris en périphérie. Nous avons donc besoin d’une approche qui peut améliorer l’agilité, la flexibilité, l’évolutivité, la performance et la sécurité de l’écosystème API.
Cette nouvelle approche nécessite une conception rationalisée, capable de tirer pleinement profit des avantages d’une architecture véritablement distribuée.
Nous analysons dans le détail la fonctionnalité et la portée d’une passerelle API pour en dégager les nuances et les limites.
La passerelle API est un élément 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 une variété de 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 au service principal approprié. Une fois que le service principal 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 le traitement de la réponse avant de la renvoyer au client.
Avec l’augmentation progressive du nombre d’API, les passerelles d’API ont évolué pour inclure une variété de nouvelles fonctionnalités au-delà du routage de base, pour devenir de véritables systèmes monolithiques. Ces passerelles gèrent désormais des tâches telles que l’authentification et la limitation des débits pour améliorer les performances et réduire la charge sur les services back-end. Toutefois, même avec cette fonctionnalité améliorée, les passerelles API restent le point d’accès unique au service back-end, ce qui peut être source de défis dans les environnements hautement distribués.
En particulier, la montée en puissance des infrastructures cloud, multicloud, hybride et de périphérie complique la tâche de ceux qui doivent maintenir l’agilité, la sécurité et les capacités de gestion avec une approche de passerelle API. Quand les clients, les appareils et les charges de travail applicatives peuvent être répartis sur un large éventail d’emplacements, une passerelle API n’est pas forcément adaptée pour fournir le niveau nécessaire d’architecture en périphérie.
Comme 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. Si la gestion des passerelles API peut être complexe, cela reste une tâche essentielle pour assurer la disponibilité, la sécurité et l’évolutivité d’une API. Les entreprises ont tendance à utiliser des outils spécialisés tels que les plateformes de gestion des API pour faciliter la gestion et la supervision de leurs passerelles API.
La liste ci-dessous n’est pas exhaustive, mais voici quelques facteurs qui contribuent à la complexité des passerelles API :
- Gestion de la configuration : les passerelles API offrent souvent un large éventail d’options et de paramètres de configuration qui doivent être gérés et maintenus : règles de routage, limitation du débit et paramètres de sécurité. La gestion de ces paramètres peut être longue et complexe, surtout avec l’augmentation du nombre d’API et de clients sous-jacents.
- Intégration avec d’autres systèmes : les passerelles doivent s’intégrer à un large éventail d’autres systèmes – systèmes d’authentification et d’autorisation, équilibreurs de charge et 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 différents protocoles ou formats de données. Les problèmes émergent lorsqu’une entreprise a plusieurs déploiements de passerelle API provenant de fournisseurs différents.
- Évolutivité et disponibilité : les passerelles API doivent pouvoir gérer un grand nombre de demandes et assurer une haute disponibilité, ce qui peut être complexe, en particulier lorsqu’il faut traiter un grand nombre de services back-end et de clients.
- 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 de manière à garantir la protection des données sensibles et le contrôle des accès. Cette tâche complexe nécessite un suivi et une gestion en continu.
- Gestion de version : avec l’augmentation du nombre d’API et de clients sous-jacents, il peut devenir de plus en plus difficile de gérer les différentes versions de l’API et de s’assurer 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, elles peuvent être réparties sur de nombreux sites, entravant la corrélation des événements qui affectent l’état global de l’application et la résolution des problèmes.
Prolifération des passerelles API
La prolifération des passerelles API désigne la multiplication de passerelles API indépendantes au sein d’une même organisation. Différentes équipes ou unités commerciales créent souvent leurs propres API, ce qui peut entraîner la création de nombreuses passerelles indépendantes. Les équipes peuvent également faire appel à différents fournisseurs ou solutions pour gérer divers types d’API.
Le résultat : une pluralité de passerelles API déployées, toutes dotées de différentes fonctionnalités.
La prolifération des passerelles API génère plusieurs défis supplémentaires :
- Mise à l’échelle de la gestion des passerelles API : le fait d’avoir plusieurs passerelles d’API indépendantes peut compliquer leur gestion et leur maintenance, en particulier si le nombre d’API et de clients sous-jacents augmente.
- Inefficacité du trafic est-ouest : la multiplication des passerelles peut obliger les requêtes à en parcourir plusieurs, ce qui ajoute de la latence et réduit les performances.
- Uniformité des politiques de sécurité : la gestion de plusieurs passerelles peut être difficile et créer des incohérences dans les politiques de sécurité. Il devient alors plus difficile de protéger les données sensibles et de contrôler les accès.
- Gouvernance standardisée : avec plusieurs passerelles, il peut être difficile de vérifier que toutes les API sont correctement régies et conformes aux normes et aux bonnes pratiques.
- Augmentation des coûts : la multiplication des 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 : avoir plusieurs passerelles rend plus difficile l’intégration avec d’autres systèmes et technologies – bases de données, entrepôts de données et outils d’analyse.
Les entreprises doivent s’efforcer de centraliser la gestion et la gouvernance de leurs API et utiliser un seul type de passerelle API. Certes, cela permettra d’atténuer les défis posés par la prolifération des passerelles API, mais la mise en œuvre d’une stratégie homogénéisée pour les passerelles API n’a rien de simple.
Défis liés à la normalisation des passerelles API dans une entreprise
Au fil du développement d’une entreprise, qu’il se fasse de manière organique ou par le biais d’acquisitions, les équipes internes alignées sur des unités commerciales (BU) spécifiques auront du mal à s’accorder sur le choix d’une technologie ou d’un fournisseur de passerelle API. Il y a plusieurs raisons à cela :
- Technologie : chaque équipe ou unité commerciale a sa propre pile technologique ou des préférences particulières concernant les solutions de passerelle API, ce qui rend difficile la standardisation sur un seul type de passerelle.
- Systèmes hérités : certaines équipes sont dotées de systèmes existants qui reposent sur un type de passerelle API spécifique, et il serait difficile de remplacer ces systèmes par une nouvelle passerelle, surtout s’ils sont toujours utilisés.
- Personnalisation : certaines équipes personnalisent leurs passerelles API pour répondre à des exigences spécifiques, et elles auront du mal à répliquer 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 ont divers niveaux d’expertise et peuvent avoir besoin de se familiariser ou de se former à une nouvelle technologie de passerelle provenant d’un fournisseur différent – un processus qui peut être à la fois long et coûteux.
- Ressources limitées : les organisations ont des ressources limitées en termes de développeurs, de budget et de temps pour mettre en œuvre les changements, ce qui rend difficile l’implémentation d’une nouvelle passerelle.
- Dépendances des applications : différentes équipes ou unités commerciales ont des dépendances différentes sur leurs passerelles existantes ; elles peuvent être intégrées à des systèmes spécifiques ou à d’autres intégrations personnalisées, ce qui rend difficile le passage à une nouvelle approche.
- Solutions tierces : les équipes qui utilisent des solutions tierces intégrées à la passerelle auront du mal à migrer vers une nouvelle solution qui ne prend pas en charge ces outils tiers.
Ainsi, si une application est utilisée par une équipe bien établie et déterminée, celle-ci ne voudra pas basculer vers un modèle de déploiement différent et risquer de 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 que la prolifération des passerelles API est l’une des problématiques les plus importantes.
Considérations de conception
Ce qui suit n’est pas une liste exhaustive, mais résume certaines considérations de conception de haut niveau qui, selon nous, doivent être prises en compte dans l’élaboration de la solution :
- Coexister avec les déploiements actuels : les organisations s’efforcent de suivre le paysage technologique en constante évolution, et elles ont bien souvent acquis une diversité de déploiements de passerelles API. Il n’est pas possible de déplacer l’ensemble de l’infrastructure API existante, car cela peut perturber des opérations commerciales stratégiques. Autrement dit, tout nouveau déploiement doit être conçu de manière à pouvoir coexister avec l’architecture actuellement déployée.
- Normaliser les fonctions de passerelle d’API : l’objectif principal de la stratégie d’API d’une entreprise doit être de normaliser la fonctionnalité de ses passerelles d’API, ce qui peut être une tâche difficile en raison de la diversité des API et des besoins 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.
- Tirer parti des déploiements en périphérie : l’infrastructure en périphérie n’a pas seulement le potentiel d’augmenter le nombre d’API de manière exponentielle, elle offre également aux entreprises la possibilité de rapprocher leurs acteurs de passerelle de la périphérie. En effet, l’infrastructure utilisée pour créer des API peut également servir à créer des acteurs de passerelle distribués. Par conséquent, la solution doit tirer pleinement parti de la proximité de l’infrastructure périphérique pour les clients qui initient la demande d’API.
- Transport agnostique : une considération essentielle pour la mise en œuvre de l’architecture des acteurs de passerelle distribuée : elle ne doit pas dépendre d’un mécanisme de transport spécifique. Que l’entreprise veuille 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 lui permet de choisir le mécanisme de transport qui convient le mieux à ses 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 avantages clés réside dans sa capacité à fournir un accès fin aux données, ce qui permet aux clients de spécifier exactement les données dont ils ont besoin dans une seule requête. De plus, GraphQL simplifie le processus d’agrégation des données à partir de plusieurs services, ce qui en fait une architecture de choix pour assurer la composabilité et l’orchestration des services. Cette approche peut réduire la charge 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 requête. Enfin, avec son schéma fortement typé et son langage de requête, GraphQL peut améliorer la découvrabilité des API et faciliter le développement client.
- La sécurité est un enjeu majeur : l’objectif primordial de la conception est qu’elle ajoute à la posture de sécurité de l’API de l’entreprise. La solution pourrait englober certaines fonctionnalités, comme la possibilité d’authentifier et d’autoriser les requêtes d’API, de mettre en œuvre des contrôles d’accès et de se protéger contre les menaces de sécurité courantes, à commencer par les scripts intersites (XSS) et les attaques par injection SQL. En aucun cas la nouvelle solution ne doit compromettre le modèle de menace existant ou le modifier au point d’altérer la surface d’attaque. En faisant de la sécurité un objectif de conception prioritaire, l’architecture doit fournir un environnement plus sécurisé pour la communication des API, réduisant ainsi le risque de violation de données et d’autres incidents de sécurité.
Il est possible de dériver des exigences spécifiques de ces considérations de conception, et nous les avons intégrées dans notre solution d’acteurs de passerelle distribués (DGA).
Acteurs de passerelle distribués
Maintenant que nous avons exploré dans le détail les passerelles API, expliquons la solution basée sur des acteurs de passerelle distribués.
Conception des acteurs de passerelle distribués
Le modèle de conception des acteurs de passerelle distribués (DGA) s’inspire de l’edge computing et du calcul à proximité du client. Le cœur de l’idée réside dans l’hyperdistribution de chaque acteur de passerelle au plus près du client, et dans le fait que l’acteur de passerelle n’existe que pendant la durée de la transaction – il est supprimé une fois la transaction achevée.
Hypothèses
Voici quelques-unes des hypothèses qui sous-tendent cette solution.
Le calcul en périphérie est de plus en plus répandu, et nous trouvons désormais un type de calcul disponible plus près du client géographiquement. Les acteurs de passerelle peuvent être instanciés sur ces nœuds de calcul périphériques. 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 type de calcul en périphérie.
Le transport d’API est un élément crucial de l’infrastructure, car il implique l’établissement d’un réseau entre les acteurs de 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 va sans doute utiliser sa propre dorsale pour exécuter le transport d’API. Autre possibilité d’implémentation : un bus de messagerie à faible latence, superposé à un réseau existant à large bande passante et à faible latence dans un centre de données d’entreprise.
Fonctions des passerelles API
Rappelons-le : 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 colocalisées, comme dans un réseau local sur site ou dans un cloud privé virtuel (VPC), à l’intérieur d’une zone de disponibilité. Mais quand le nombre d’API évolue, qu’elles se déplacent au sein d’une infrastructure hybride ou qu’elles deviennent mobiles, tout simplement, cette approche de conception perd son efficacité et devient à la fois complexe et coûteuse à exploiter.
On peut avoir différents avis sur la classification des fonctionnalités décrites dans la figure 6, mais nous pouvons convenir que l’infrastructure de gestion des API est devenue un déploiement complexe, englobant de nombreux composants qui doivent être soigneusement orchestrés.
La figure 7 fait le lien entre les différentes caractéristiques et fonctions de la gestion d’API présentée à la figure 6 et l’architecture des acteurs de passerelle distribués. Ce rapprochement 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 de l’API au sein de l’architecture.
Fonctions centralisées
La plupart des fonctionnalités énumérées ci-dessus ont une composante de gestion qui peut être logiquement centralisée. Notre objectif n’est pas de refondre l’architecture du plan de gestion mais, si possible, de supprimer certaines fonctions.
Fonctions essentielles de la passerelle API
Ce sont des fonctions de plan de données, et il est donc préférable qu’elles soient implémentées dans l’API et colocalisées avec les charges de travail applicatives. Les passerelles API sont un élément crucial de l’architecture moderne des microservices, parce qu’elles servent de point d’entrée pour tout le trafic externe. Nous avons catégorisé ses fonctions de base : routage, équilibrage de charge, routage dynamique, vérification de l’état, nouvelles tentatives et basculements.
Une passerelle API achemine les demandes entrantes vers le microservice approprié, distribue le trafic sur plusieurs instances, prend en charge le routage dynamique, surveille l’état des microservices et de leurs instances, renouvelle les requêtes en cas d’échec et fournit des réponses de repli en cas d’indisponibilité ou d’échec du microservices. D’autres fonctions – authentification, autorisation, limitation du débit, mise en cache et journalisation – peuvent être distribuées aux fonctions périphériques ou bien centralisées, en fonction des exigences spécifiques du système.
Cette approche modulaire rend possible une architecture plus flexible et optimisée, et elle est au cœur de notre recommandation de simplification, de modernisation et de mise à l’échelle de l’infrastructure API d’entreprise.
Fusion
La passerelle API et la gestion des API sont souvent réunies à tort par les fournisseurs au sein de la fonction de passerelle API, mais il s’agit en réalité de deux fonctions distinctes qui doivent être traitées séparément. La passerelle API est responsable de l’acheminement des requêtes des clients vers les services back-end, tandis que la gestion des API englobe un ensemble plus large de fonctionnalités, comme 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 offrir à la fois des fonctions de passerelle et de gestion d’API dans un même produit, il est important de comprendre les différences entre ces fonctions et de les évaluer séparément en fonction de leurs exigences spécifiques. La combinaison de ces fonctions peut créer de la confusion et potentiellement limiter la flexibilité et l’évolutivité de l’infrastructure API d’une organisation. Cet aspect est également essentiel pour comprendre notre position sur la distribution de la fonctionnalité de passerelle API.
Acteur de passerelle – Fonctionnalités en ligne
Les fonctionnalités répertoriées ici sont des fonctions de base qui doivent être alignées sur le chemin des données. Dans un modèle de passerelle distribuée, certaines fonctions en ligne de la passerelle API sont également distribuées. Il s’agit notamment du contrôle d’accès, de la limitation du débit, de la validation des requêtes, de l’analyse des API, des rapports d’utilisation, de la surveillance du taux d’erreur, de la création d’alertes et d’événements, de l’intégration de l’authentification, de l’intégration de tiers, de la surveillance et l’intégration de la journalisation, de la mise en cache en périphérie et de 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 : contribue à réduire la charge sur la passerelle API centralisée et à améliorer les performances et l’évolutivité du système.
- Réduction des temps de réponse : en déployant ces fonctions plus près des clients, on réduit les temps de réponse et la latence. Avec 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 requêtes 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 périphérique, déployé plus près des clients. Cela peut réduire le nombre de requêtes à traiter par la passerelle API centralisée, et donc améliorer 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 passerelle – Candidats GraphQL
Aujourd’hui, les passerelles API prennent en charge une fonctionnalité essentielle : la composition et l’orchestration des services. Bien que cela puisse devenir assez complexe, il pourrait être gênant que cette fonctionnalité ne soit pas prise en charge par la passerelle API simplifiée. Nous pensons que GraphQL peut être une approche intéressante de la composition de services, en agissant comme une sorte de middleware pour les API existantes.
En raison de sa visibilité sur toutes les API, la passerelle API devient le lieu de choix pour effectuer la composition de services ; cela permet aux développeurs de combiner les API derrière la passerelle pour améliorer la logique métier sans avoir à écrire de nouveaux services, et cette combinaison peut être plus simple dans une couche de composition de services.
La composition des services dans GraphQL est rendue possible par 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 élaborer des requêtes qui spécifient exactement les données nécessaires, quels que soient les services ou les sources qui les fournissent. Les résolveurs, dont la fonction est de rapprocher les requêtes des sources de données, sont utilisés pour récupérer les données du service ou de la source appropriée. Cependant, si GraphQL promet une meilleure sécurité, sa performance dépend directement de la qualité du code.
Autres caractéristiques et fonctions
Il reste encore quelques fonctionnalités de la Figure 6 : Fonctionnalités de gestion des API et d’infrastructure que nous n’avons pas encore traitées. Ces dernières fonctionnalités et fonctions sont de bonnes candidates au déplacement vers des fonctions de gestion et d’exploitation individuelles ou 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 la technologie d’un fournisseur spécifique. La mise en œuvre de l’acteur de passerelle peut reposer sur des méthodes, des fonctions, des travailleurs, des threads et des processus, mis en œuvre à l’aide d’infrastructures basées sur des machines virtuelles, des conteneurs, du serverless ou d’autres approches spécifiques à un fournisseur.
Caractéristiques et comportement du composant
L’approche adoptée avec l’architecture d’acteurs de passerelle distribués (DGA) simplifie les fonctions de la 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 seraient mieux prises en charge dans le plan de contrôle en tant que composant logiquement centralisé, plutôt que mises en œuvre dans une passerelle API monolithique. La gestion et le contrôle de l’infrastructure API existante peuvent être étendus et élargis 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, gérables par tous les fournisseurs de passerelle API à l’aide d’un ensemble commun de paramètres de configuration.
Une entreprise souhaitant effectuer cette transformation pourrait déployer l’architecture DGA application par application, sans perturber les déploiements existants et sans opération majeure de déplacement.
Acteurs de passerelle distribués
L’approche DGA a une particularité essentielle : chaque acteur de passerelle est éphémère, il n’est instancié que pour la durée d’une session API (un appel API émis par un client).
Un acteur de passerelle distribué peut être plus flexible, évolutif et rentable que la passerelle API traditionnelle. Plutôt que de s’appuyer sur les multiples 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 près de la périphérie du réseau. Les API elles-mêmes pourraient fournir davantage de contrôle et de grande personnalisation pour répondre à leurs besoins spécifiques.
Cette nouvelle approche permet également une plus grande évolutivité, car les développeurs peuvent facilement créer les instances des acteurs de passerelle selon les besoins du trafic, sans se soucier de la charge liée à la gestion d’une grande passerelle centralisée.
En plus de ses avantages techniques, l’acteur de passerelle permet également des économies de coûts par rapport à la passerelle API traditionnelle. Les entreprises ne payent en effet que les instances éphémères d’acteur qu’elles utilisent. Ce modèle de déploiement peut créer des opportunités de modèles de revenus supplémentaires.
Positionnement de l’acteur de passerelle
En tirant parti d’une couche de transport API, les DGA ont essentiellement pour effet de découpler l’emplacement d’entrée 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 qui émet l’appel. Les API peuvent aboutir aux DGA puis être transportées par n’importe quel moyen. Cette approche est différente du schéma de la Figure 3 : Architectures de passerelle API héritées où le trafic client pénètre topologiquement à côté des passerelles API.
Conclusion
Notre intention était donc de proposer une approche indépendante du fournisseur et du déploiement, car chaque fournisseur est susceptible de miser sur une propriété intellectuelle spécifique pour le développement de ces composants, afin d’atteindre des objectifs similaires comme indiqué.
Dans cet article, nous avons résumé les enseignements tirés de plusieurs trimestres de recherche sur la prolifération des API, les architectures de périphérie 2.0, l’économie des API et GraphQL. Si le jury n’a toujours pas rendu son verdict en ce qui concerne l’infrastructure API existante, nous pensons qu’il est nécessaire d’adopter une nouvelle approche.
La simple perspective de libérer de la valeur au sein de chaque appareil ou entité à l’échelle mondiale constitue une raison suffisante d’explorer une nouvelle approche. Nous devons abandonner l’infrastructure API héritée dès aujourd’hui, car même si elle semble distribuée, elle reste intrinsèquement monolithique.
Nous proposons l’approche d’acteur de passerelle distribué reposant sur GraphQL comme moyen agnostique de libérer tout le potentiel de l’économie émergente des API.