Qu’est-ce qu’une passerelle fédérée ?

Dans les systèmes centralisés, une seule passerelle (connectée à plusieurs API et responsable de leur gestion) traite toutes les requêtes client. La fédération de passerelles, quant à elle, permet aux entreprises d’utiliser un réseau distribué de passerelles d’API, chacune responsable d’un ensemble de services.

Dans un système de passerelles fédérées, les équipes peuvent ajouter des services selon les besoins sans affecter l’ensemble du système, ce qui permet une utilisation des ressources et une gestion du trafic toutes deux efficaces. En outre, les différents services peuvent utiliser des protocoles différents pour gérer leurs passerelles respectives. Le cadre donne aux équipes toute latitude pour gérer leurs propres API, ce qui améliore la flexibilité, la résilience et plus encore.

Cette approche permet également d’éviter les goulots d’étranglement du trafic et d’autres problèmes associés aux passerelle d’API centralisées, et d’améliorer la performance en déployant les fonctions de passerelle plus près des utilisateurs finaux. Les stratégies de fédération de passerelles peuvent être appliquées à divers types d’architecture et protocoles d’API, notamment REST, gRPC et SOAP, chacun présentant des avantages et des inconvénients.

D’un point de vue informatique, les passerelles fédérées sont avantageuses car elles permettent aux équipes DevOps de développer et de déployer leurs propres API tout en respectant les politiques de gestion, de gouvernance et de sécurité des plateformes d’API à l’échelle de l’entreprise. Indépendantes, les équipes peuvent rapidement mener à bien leurs projets respectifs (facilitant l’innovation et accélérant la mise sur le marché), tout en se conformant aux normes de l’entreprise. Cette approche permet donc de concilier autonomie des équipes et supervision centralisée.

La fédération GraphQL est une autre approche architecturale, qui permet de créer des API GraphQL unifiées. Elle est basée sur GraphQL, un langage de requête qui cible avec précision les ressources de plusieurs services à l’aide d’une seule requête API.

La fédération GraphQL connecte différents services (appelés « subgraphs », chacun ayant son propre schéma qui définit les données qu’il gère) à un schéma unifié appelé « supergraph ». Une passerelle unique expose ce schéma supergraph aux applications clientes, regroupe plusieurs services et champs sous-jacents, et achemine toutes les requêtes API. La fédération de passerelles, quant à elle, relie plusieurs passerelles d’API grâce à un plan de contrôle central, chaque passerelle traitant ses propres requêtes.

La fédération est une approche générale de la gestion des systèmes, qui consiste à relier des composants autonomes à l’aide d’un plan de contrôle commun.

Dans un système de passerelle centralisée, toutes les requêtes client passent par une seule et même passerelle qui gère des fonctions telles que le routage, l’authentification, l’autorisation et la surveillance. Contrairement aux architectures fédérées, ces responsabilités ne sont pas réparties entre plusieurs instances.

Cette approche permet de rationaliser la journalisation, la gestion du trafic, l’application des règles de sécurité et d’autres tâches, puisque chacun de ces processus passe par la passerelle. Les entreprises peuvent également lancer des déploiements à partir d’un point unique pour ne plus avoir à mettre à jour les versions sur plusieurs passerelles et services.

Toutefois, les entreprises dotées de cadres centralisés sont plus susceptibles de rencontrer des goulets d’étranglement, en particulier lorsqu’elles intensifient leurs opérations. En tant que point de passage unique du système, la passerelle peut facilement être encombrée. En outre, elle présente un point de défaillance unique ; en cas d’erreur, c’est l’ensemble du système qui affecté.

Contrairement aux systèmes centralisés, les architectures de passerelles fédérées sont composées de plusieurs passerelles, chacune responsable d’un ensemble distinct de services et d’API associées. Les passerelles fonctionnent de manière indépendante, bien qu’elles soient gérées par un plan de contrôle central.

Les systèmes fédérés favorisent la flexibilité et l’autonomie, puisqu’elle donnent aux équipes de développement plus de contrôle sur leurs domaines respectifs que les cadres centralisés. Cette structure décentralisée rend également les systèmes fédérés plus résilients en cas de panne ou de défaillance du système.

Cependant, les systèmes fédérés sont plus complexes sur le plan opérationnel, ce qui peut entraîner des problèmes de gouvernance et de communication entre les équipes. Le déploiement peut prendre plus de temps, et la maintenance peut être plus coûteuse car chaque passerelle doit être gérée et mise à jour séparément.

Les entreprises peuvent opter pour un système de passerelle fédérée pour plusieurs raisons.

D’une part, la fédération de passerelles est couramment utilisée dans les cas des fusions-acquisitions, lorsque les entreprises héritent des piles technologiques et systèmes de gestion des API des entités qu’elles acquièrent. Au lieu de gérer individuellement plusieurs architectures distinctes (chacune avec ses propres protocoles de sécurité, normes techniques et structures de gouvernance) ou de tenter d’adapter les systèmes acquis aux systèmes existants, les entreprises se tournent vers la fédération de passerelles. Cette approche leur permet d’intégrer les passerelles d’API existantes, ainsi que leurs systèmes sous-jacents, dans la structure globale fournie par le plan de contrôle central.

De même, plusieurs passerelles sont souvent utilisées dans les environnements comportant de nombreux microservices créés par différentes équipes et disséminés. Les entreprises peuvent également se tourner vers un système fédéré pour ses avantages en matière de performance.

Prenons l’exemple d’une entreprise logistique qui compte plusieurs bureaux dans le monde entier, chacun desservant une région particulière. En plaçant les passerelles, les serveurs, les services et d’autres ressources plus près des clients qui les utilisent, l’entreprise améliore la latence et les facteurs de performance associés.

Dans la fédération de passerelles, le plan de contrôle central assure la gestion, la surveillance et la gouvernance, mais est généralement inaccessible aux clients. Les consommateurs d’API interagissent directement avec les passerelles qui composent le système fédéré (en interrogeant le point de terminaison responsable des services concernés), sans interroger le plan de contrôle. Ce dernier reçoit les métadonnées et les journaux une fois l’appel d’API effectué.

Si cette approche implique une certaine complexité opérationnelle, elle favorise également l’indépendance. Par exemple, elle permet aux équipes chargées de la plateforme de configurer leurs propres passerelles et services selon leurs besoins spécifiques, de choisir leurs propres protocoles et de procéder elles-mêmes aux déploiements progressifs. Les architectures fédérées sont également plus résilientes face aux problèmes de configuration et aux violations de sécurité. En effet, les erreurs sont isolées de la passerelle dont elles proviennent et ne risquent pas de se propager à d’autres passerelles du réseau.

Quant à la fédération GraphQL, les schémas de plusieurs services indépendants (subgraphs) sont regroupés pour former un schéma de supergraph unifié. Une passerelle (ou routeur) unique permet de disposer d’un point d’entrée unique pour les requêtes client et d’offrir une expérience API unifiée.  

Le routeur divise intelligemment les requêtes en sous-requêtes. Il récupère les informations pertinentes à partir de plusieurs subgraphs et les compile pour fournir une réponse cohérente aux clients.

Prenons l’exemple d’une plateforme de santé qui propose des services distincts :

• Patients : gestion de leurs informations, coordonnées et antécédents médicaux
  
  
• Rendez-vous : planification et suivi des visites
  
  
• Facturation : gestion des factures et notifications associées

Au lieu d’interroger chacun de ces points de terminaison avec un appel d’API distinct, la fédération GraphQL présente une interface unifiée qui permet aux clients (dans notre cas, une application ou un tableau de bord destiné aux médecins ou aux patients) de consulter les antécédents médicaux du patient, de connaître son prochain rendez-vous, ainsi que le montant dû, le tout par le biais d’un seul appel d’API, et non de trois requêtes distinctes.

La fédération GraphQL permet de construire des API GraphQL évolutives dans un environnement distribué. Le cadre permet un développement et un déploiement indépendants, tout en fournissant une interface unifiée pour les requêtes client. Cependant, la fédération GraphQL peut poser des défis : coût, complexité, vulnérabilités, congestion et redondances.

Lancée en 2019, la fédération Apollo est une approche unique de la fédération GraphQL qui s’appuie sur des directives spéciales (telles que @key ou @extends) dans le langage de définition de schéma GraphQL pour définir les relations entre différents types à travers les subgraphs.

Bien que courante, Apollo n’est pas la seule option de fédération GraphQL disponible. Les alternatives les plus courantes sont Hive, Mesh, Indigo et WunderGraph Cosmo, qui offrent différents niveaux de personnalisation. 

Si moins de 5 % des entreprises disposaient d’un système GraphQL fédéré en 2024, leur proportion devrait atteindre 30 % d’ici 2027, selon le cabinet d’études Gartner. Les principaux fournisseurs de cloud comme Amazon Web Services (AWS) et Microsoft Azure, ainsi que les référentiels de code comme GitHub, prennent également en charge les API GraphQL avec des outils d’observabilité et de validation intégrés.

La fédération GraphQL présente plusieurs avantages, notamment en raison de sa capacité à rationaliser l’accès client aux API. Les équipes peuvent conserver une certaine indépendance en déployant, en gérant et en dimensionnant leurs propres subgraphs.

Mais en tant que cadre centralisé, la fédération GraphQL est plus vulnérable aux failles de sécurité, ainsi qu’au risques de congestion et d’inefficacité. Elle est également tributaire des schémas GraphQL, tandis que la fédération de passerelles d’API est compatible avec plusieurs protocoles.

Pour élaborer leur stratégie d’API, les entreprises doivent décider si adopter un cadre ou utiliser un autre type d’architecture, comme REST.

Pour assurer une bonne gestion des fonctions, elles peuvent finir par choisir d’intégrer la fédération GraphQL, ainsi que d’autres styles architecturaux à leur système. Une configuration courante consiste à utiliser GraphQL en interne (avec des garde-fous stricts pour limiter les problèmes de sécurité, de coût ou de complexité), et un autre type d’architecture, comme REST (qui offre un niveau de contrôle plus élevé et facilite l’adoption) pour les API externes. Dans ce scénario, une passerelle d’API fédérée peut également être utilisée pour unifier ces types d’architecture disparates grâce au plan de contrôle central.

Dans les configurations standard, une seule passerelle d’API gère le trafic utilisateur, le routage et l’analyse. Si cette approche permet de rationaliser les configurations les plus simples, elle peut rapidement entraîner des goulets d’étranglement dans les environnements plus complexes.

Les passerelles fédérées, quant à elles, s’appuient sur un ensemble de passerelles d’API. Chaque passerelle est utilisée pour gérer les appels d’API vers certains services, et reliée au plan de contrôle, qui assure la gestion et la gouvernance.

Les maillages de services, quant à eux, sont considérés comme des configurations est-ouest, car ils gèrent les connexions entre les microservices sans interagir avec les utilisateurs. Les maillages de services facilitent principalement la communication et l’observabilité au sein d’un seul et même environnement ou cluster. Cependant, les variantes connues sous le nom de maillages de cloud hybride sont optimisées pour exécuter des fonctions telles que le chiffrement, l’équilibrage de charge et l’authentification sur plusieurs clusters et environnements (notamment les environnements multicloud, cloud hybride et sur site). 

Les entreprises peuvent mettre en œuvre diverses stratégies pour profiter de l’architecture distribuée des passerelles fédérées, tout en réduisant la complexité opérationnelle et les coûts de maintenance associés aux systèmes fédérés. Ces pratiques permettent de préserver l’autonomie des équipes tout en assurant des lignes de communication ouvertes, ainsi qu’une supervision unifiée.

Les entreprises doivent clairement définir le rôle des équipes et les services que chacune est chargée de créer et d’entretenir. Cette pratique favorise la responsabilisation et évite aux équipes de faire double emploi ou de mal configurer le travail de leurs collègues. Cette approche stimule donc la productivité, puisque les équipes connaissent bien leurs objectifs et leurs responsabilités (et sont libres d’agir en conséquence).

Une mise en œuvre incohérente des protocoles et normes de sécurité et de conformité entre passerelles et API peut faire peser des risques sur la sécurité, avoir des conséquences juridiques et nuire à la réputation. Mettre en place des normes pour la journalisation, le chiffrement, l’authentification et d’autres mesures de sécurité des passerelles doit être une priorité dans les systèmes distribués. Le plan de gestion central permettra ainsi de répondre efficacement aux incidents, de réaliser des audits complets et de prévenir les attaques, quelle que soit la provenance des menaces.

Les lacunes d’observabilité peuvent entraîner des risques pour la sécurité des systèmes distribués et affecter leur performance. Il est essentiel que le plan de gestion central offre la visibilité nécessaire aux équipes pour connaître l’état et la performance du système. Cette fonctionnalité permet une résolution rapide en cas de problème, ainsi qu’une amélioration proactive en fonction des indicateurs de sécurité et de performance.

Les portails de développement unifiés font office de plaque tournante permettant aux développeurs d’accéder aux différentes API du système pour en savoir plus, quels que soient l’endroit où elle sont hébergées et la manière dont elles sont structurées. Ils sont particulièrement importants dans le cas des systèmes fédérés, car ils fournissent lignes directrices, documentation et exemples de code pour encadrer la création, le déploiement et l’entretien des API par les équipes DevOps.

Ces normes universelles, associées aux clés d’API et à d’autres contrôles d’accès, permettent aux développeurs de facilement ajouter des API au système et gérer leurs propres passerelles tout en garantissant sécurité et cohérence.

Parce que chaque équipe jouit d’un certain degré d’autonomie, une communication ouverte est essentielle pour partager les bonnes pratiques et assurer la durabilité du réseau. Les tableaux de bord et autres outils collaboratifs aident les équipes à se synchroniser autour des objectifs et procédures qu’elles partagent, en particulier lorsque les changements opérés dans un domaine sont susceptibles d’affecter les services connexes.

Un mécanisme de reporting complet permettra aux équipes DevOps de détecter et de résoudre promptement des problèmes comme la latence, les interruptions de service et d’autres anomalies, afin d’offrir une expérience utilisateur plus fluide. Les indicateurs de performance permettent eux aussi d’améliorer l’efficacité à grande échelle, en identifiant les parties performantes du système, et celles qui le sont moins.

Les approches DevOps modernes, telles que l’infrastructure en tant que code (utilisation du code pour automatiser les processus informatiques qui nécessiteraient autrement une surveillance et un provisionnement manuels) et l’AIOps (utilisation de l’IA pour rationaliser les opérations informatiques), optimisent le fonctionnement des passerelles fédérées. Les techniques d’automatisation contribuent également à rendre les réseaux plus résilients, puisqu’elles réduisent le risque d’erreur et permettent aux équipes informatiques de se concentrer sur les problèmes plus complexes.

Parce que la fédération de passerelles combine la flexibilité et la personnalisation des architectures décentralisées avec une structure de gouvernance centralisée, elle s’avère plus avantageuse que les architectures traditionnelles.

La fédération donne aux équipes le contrôle de leurs propres passerelles. En effet, elles peuvent ajuster les configurations d’exécution, gérer les mises à jour et personnaliser les environnements de codage pour répondre au mieux aux besoins de leurs clients et de leurs services. Par exemple, pour ajuster la limite de débit d’une API dans un système centralisé, les équipes devaient envoyer une requête par le biais de l’unique passerelle de l’entreprise. Grâce aux systèmes fédérés, elles peuvent désormais procéder aux ajustements de manière indépendante et en temps réel, sans affecter les autres passerelles du réseau.

Le plan central permet de s’assurer que les différentes passerelles, bien qu’ayant chacune ses propres configurations, respectent les normes de compatibilité et de sécurité communes. Les équipes ont la flexibilité d’ajuster les paramètres de manière autonome, tout en tirant parti de la supervision externe assurée par le plan de contrôle.

Les équipes de développement savent généralement mieux que quiconque comment améliorer et gérer les aspects dont elles sont chargées, et les approches fédérées en tiennent compte. Les équipes ont l’autonomie nécessaire pour ajuster leurs API ou leurs services dès qu’elles voient un problème émerger, ce qui améliore l’adaptabilité et l’agilité. 

Les équipes peuvent même travailler dans différents langages de programmation, tout en conservant la relation de leur service avec le plan de contrôle central. Enfin, les services peuvent déployer les mises à jour progressivement, selon les besoins, au lieu de s’en remettre à une autorité centrale pour approuver les modifications. Cela permet d’accélérer la mise sur le marché des nouvelles fonctionnalités et de rationaliser les workflows.

Les systèmes fédérés favorisent un provisionnement plus efficace des ressources en permettant aux équipes de surveiller leur propre performance et d’ajuster les limites de débit et la répartition du trafic en conséquence. Les entreprises sont en mesure d’intensifier uniquement les services et les fonctions qui nécessitent une capacité supplémentaire, en redirigeant les ressources vers les services ou les régions qui connaissent une demande importante.

En outre, comme les passerelles d’API sont indépendantes, les vulnérabilités risquent moins de passer d’une passerelle à l’autre. Par conséquent, les systèmes fédérés sont généralement plus résistants aux attaques et aux pannes, car les défaillances affectent généralement une seule passerelle, et non l’ensemble du système.

Dans le cas des systèmes fédérés, les équipes DevOps se chargent d’exploiter et d’entretenir leurs propres passerelles. Avec moins de responsabilités à assumer, l’équipe centrale peut se concentrer sur les problèmes plus complexes tels que la mise en conformité, la mise en place d’une communication interfonctionnelle et l’affinement des architectures système.

Le risque de se retrouver avec des silos de données est beaucoup moins probable, car les passerelles fédérées analysent la performance et appliquent des garde-fous dans chaque domaine. Les indicateurs transversaux fournissent une vision plus globale de l’impact que chaque service a sur les produits et services connexes.

La propriété décentralisée et la flexibilité peuvent poser plusieurs défis, surtout en cas de défaillance des dispositifs de gouvernance et d’observabilité. Les défis liés aux passerelles fédérées sont les suivants :

Si l’autonomie des équipes favorise l’innovation, elle augmente également la complexité architecturale du système et, implicitement, les coûts d’infrastructure et de calcul. En outre, les systèmes fédérés requièrent généralement plus de ressources de maintenance et de sécurité en raison de leur structure décentralisée.

Parce que les indicateurs et les journaux sont répartis sur plusieurs passerelles d’API, s’offrir une vision coordonnée de la performance globales de leur système peut s’avérer plus difficile. Les sources de données peuvent finir par être fragmentées et déconnectées du réseau, ce qui complique l’identification et la correction des erreurs de configuration. Pour relever ce défi, les entreprises peuvent adopter des protocoles et des principes de normalisation solides, ainsi que des outils d’observabilité.

Bien que chaque équipe procède aux mises à jour à sa guise, le déploiement progressif à l’échelle de l'entreprise peut prendre plus de temps que dans un environnement centralisé. Au lieu de mettre à jour un code base unique et central, les passerelles fédérées répartissent les mises à jour sur plusieurs domaines, chaque équipe étant chargée d’approuver et d’intégrer ces modifications de manière indépendante.

Assurer la cohérence des configurations et des politiques sur les passerelles distribuées peut constituer un défi. Si les équipes adoptent des protocoles, des calendriers de déploiement et des formats de données qui s’écartent des normes de gouvernance de l’entreprise, des incompatibilités et des vulnérabilités peuvent apparaître. Au contraire, des normes et des politiques de gouvernance trop strictes risquent d’entraver l’expérimentation et de freiner l’innovation. Dans un système fédéré, l’équilibre est crucial.

Au fur et à mesure que les entreprises se développent et évoluent au sein d’un système fédéré, elles risquent d’être confrontées à de nouvelles inefficacités telles que la prolifération des API (plusieurs équipes développent involontairement des API redondantes). Si ce problème s’aggrave, les passerelles peuvent devenir ingérables et le plan central n’est plus en mesure de suivre les changements. Ce problème peut être évité grâce à une gouvernance efficace.