Les applications cloud natives sont composées de dizaines, de centaines, voire de milliers d’API qui relient les microservices entre eux. Ensemble, ces services et ces API offrent la résilience, l’évolutivité et la flexibilité qui sont au cœur des applications cloud natives.
Aujourd’hui, ces API et microservices sous-jacents sont souvent développés par des équipes réparties dans le monde entier, qui doivent disposer d’un certain degré d’autonomie et d’indépendance afin de commercialiser rapidement de nouvelles fonctionnalités.
Dans le même temps, Platform Ops sont chargées de garantir la fiabilité et la sécurité globales des applications et de l’infrastructure de l’entreprise, y compris des API sous-jacentes. Elles doivent disposer d’une visibilité sur le trafic des API et pouvoir définir des garde-fous globaux afin d’assurer une sécurité et une conformité uniformes, tout en offrant une excellente expérience aux développeurs d’API.
Bien que les intérêts de ces deux groupes puissent être contradictoires, nous ne pensons pas que cela soit inévitable. Nous avons conçu API Connectivity Manager dans le cadre de F5 NGINX Management Suite afin de permettre à la fois aux équipes Platform Ops de garantir la sécurité et le bon fonctionnement des systèmes, et aux développeurs d’API de créer et de déployer facilement de nouvelles fonctionnalités.
Créer une architecture pour prendre en charge la connectivité des API
En tant que plan de gestion de nouvelle génération, API Connectivity Manager est conçu pour exploiter et étendre la puissance de NGINX Plus en tant que passerelle d’API. Si vous avez déjà utilisé NGINX, vous connaissez son évolutivité, sa fiabilité, sa flexibilité et ses performances en tant que passerelle d’API.
Lors de la conception d’API Connectivity Manager, nous avons développé une nouvelle architecture afin de permettre aux équipes chargées des opérations de la plateforme et aux développeurs de mieux collaborer. Elle utilise les termes standard suivants du secteur pour désigner ses composants (dont certains diffèrent des noms familiers aux utilisateurs expérimentés de NGINX) :
- Espace de travail – Un ensemble isolé d’infrastructures destiné à la gestion et à l’utilisation exclusives d’une unité opérationnelle ou d’une équipe ; il comprend généralement plusieurs environnements
- Environnement – Un ensemble logique d’instances NGINX Plus (clusters) faisant office de passerelles API ou de portails pour développeurs pour une phase spécifique du cycle de vie de l’application, telle que le développement, les tests ou la production
- Cluster de proxys de passerelle API – Une représentation logique de la passerelle API NGINX qui regroupe les instances NGINX Plus et synchronise leur état
- Proxy d’API – Représentation d’une instance publiée d’une API, comprenant le routage, la gestion des versions et d’autres stratégies
- Politiques – Une abstraction globale ou locale permettant de définir des fonctions spécifiques du proxy d’API, telles que la résilience du trafic, la sécurité ou la qualité de service
Le schéma suivant illustre la manière dont les composants sont imbriqués dans un espace de travail :
Cette hiérarchie logique permet de répondre à de nombreux cas d’usage importants en matière de connectivité des API à l’échelle de l’entreprise. Par exemple, les espaces de travail peuvent intégrer plusieurs types d’infrastructures (notamment le cloud public et les infrastructures sur site), ce qui permet aux équipes d’accéder aux deux et aux responsables de l’infrastructure de bénéficier d’une visibilité sur le trafic des API dans ces deux environnements.
Nous examinerons plus en détail les composants architecturaux dans de prochains articles. Pour l’heure, voyons comment API Connectivity Manager répond aux besoins des différents profils qui contribuent au développement et à la mise à disposition des API.
API Connectivity Manager pour les opérations de plateforme
L’équipe Platform Ops est chargée de mettre en place et de gérer le cycle de vie de l’infrastructure de chaque organisation. Elle fournit la plateforme sur laquelle les développeurs créent des applications et des services destinés aux clients et aux partenaires. Les équipes de développement sont souvent décentralisées, travaillent dans plusieurs environnements et dépendent de différentes branches d’activité. Répondre aux besoins de ces groupes et environnements dispersés tout en maintenant des normes à l’échelle de l’entreprise constitue aujourd’hui l’un des principaux défis auxquels sont confrontées les équipes Platform Ops.
API Connectivity Manager propose des moyens innovants de séparer les équipes et leurs opérations en utilisant les espaces de travail comme frontières logiques. Il permet également aux équipes chargées des opérations de la plateforme de gérer le cycle de vie de l’infrastructure sans interférer avec les équipes qui développent et déploient les API. API Connectivity Manager intègre un ensemble de stratégies globales par défaut qui assurent la sécurité et la configuration de base des passerelles d’API NGINX Plus et des portails pour développeurs. Les équipes chargées des opérations de la plateforme peuvent ensuite configurer des stratégies globales supplémentaires afin d’imposer éventuellement le protocole mTLS, de définir les formats de journaux ou de normaliser les en-têtes de proxy.
La stratégie globale impose une uniformité et garantit la cohérence des API déployées dans le cluster de passerelles API partagé. API Connectivity Manager permet également aux organisations d’exécuter des clusters de plan de données décentralisés afin de séparer physiquement les environnements dans lesquels chaque équipe ou secteur d’activité déploie ses API.
Dans un prochain article de blog, nous verrons comment les équipes Platform Ops peuvent utiliser API Connectivity Manager pour garantir la sécurité et la gouvernance des API, tout en favorisant la réussite des développeurs d’API.
API Connectivity Manager pour les développeurs
Les équipes des différents secteurs d’activité possèdent et exploitent leurs propres ensembles d’API. Elles doivent garder le contrôle de leurs produits d’API afin de commercialiser leurs applications et services dans les délais impartis. Elles ne peuvent donc pas se permettre d’attendre l’approbation d’autres équipes pour utiliser une infrastructure partagée. Dans le même temps, des « garde-fous » doivent être mis en place pour éviter que les équipes ne se gênent mutuellement.
À l’instar du profil Platform Ops, les développeurs propriétaires d’API disposent de leurs propres espaces de travail, qui isolent leurs API de celles des autres équipes. API Connectivity Manager fournit des stratégies au niveau du proxy d’API afin que les propriétaires d’API puissent configurer des paramètres propres au service, tels que la limitation du débit et des exigences de sécurité supplémentaires.
Dans un prochain article de blog, nous verrons comment les développeurs peuvent utiliser API Connectivity Manager pour simplifier la gestion du cycle de vie des API.
Commencer
Commencez un essai gratuit de 30 jours de NGINX Management Suite, qui comprend API Connectivity Manager et Instance Manager.
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.