BLOG | NGINX

La gouvernance adaptative offre aux développeurs d'API l'autonomie dont ils ont besoin

NGINX-Partie-de-F5-horiz-black-type-RGB
Andrew Stiefel Miniature
André Stiefel
Publié le 10 novembre 2022

L’entreprise d’aujourd’hui est souvent constituée d’équipes réparties dans le monde entier qui créent et déploient des API et des microservices, généralement dans plusieurs environnements de déploiement. Selon le rapport State of Application Strategy de F5, 81 % des organisations opèrent dans trois environnements ou plus, répartis entre le cloud public, le cloud privé, les locaux et la périphérie.

Assurer la fiabilité et la sécurité de ces architectures multicloud complexes constitue un enjeu majeur pour les équipes Platform Ops chargées de leur maintenance. Selon les responsables de l’ingénierie logicielle interrogés dans le rapport F5, la visibilité (45 %) et la sécurité cohérente (44 %) arrivent en tête de liste des défis multicloud auxquels sont confrontées les équipes Platform Ops .

Avec le nombre croissant d’API et de microservices aujourd’hui, la gouvernance des API devient rapidement l’un des sujets les plus importants pour la planification et la mise en œuvre d’une stratégie API à l’échelle de l’entreprise. Mais qu’est-ce que la gouvernance des API et pourquoi est-elle si importante pour votre stratégie API ?

Qu'est-ce que la gouvernance des API ?

Au niveau le plus élémentaire, la gouvernance des API implique la création de politiques et l’exécution de contrôles et de validations pour garantir que les API sont détectables, fiables, observables et sécurisées. Il offre une visibilité sur l’état des systèmes complexes et des processus métier qui alimentent vos applications modernes, que vous pouvez utiliser pour guider l’évolution de votre infrastructure API au fil du temps.

Pourquoi avez-vous besoin d’une gouvernance API ?

L’importance stratégique de la gouvernance des API ne peut pas être surestimée : c’est le moyen par lequel vous réalisez la stratégie API globale de votre organisation. Sans une gouvernance appropriée, vous ne pourrez jamais parvenir à une cohérence dans la conception, le fonctionnement et la production de vos API.

Lorsqu’elle est mal réalisée, la gouvernance impose souvent des exigences contraignantes qui ralentissent les équipes. Cependant, si elle est bien réalisée, la gouvernance des API réduit le travail, rationalise les approbations et permet aux différentes équipes de votre organisation de fonctionner de manière indépendante tout en atteignant les objectifs généraux de votre stratégie API.

Quels types d’API devez-vous gouverner ?

L'élaboration d'un plan de gouvernance API efficace dans le cadre de votre stratégie API commence par l'identification des types d'API dont vous disposez en production, ainsi que des outils, des politiques et des conseils dont vous avez besoin pour les gérer. Aujourd’hui, la plupart des équipes d’entreprise travaillent avec quatre principaux types d’API :

  • API externes – Fournies aux consommateurs et développeurs externes pour permettre des intégrations en libre-service avec des données et des capacités
  • API internes – Utilisées pour connecter des applications internes et des microservices et uniquement disponibles pour les développeurs de votre organisation
  • API partenaires – Facilitez les relations commerciales stratégiques en partageant l'accès à vos données ou applications avec les développeurs d'organisations partenaires
  • API tierces – Consommée auprès de fournisseurs tiers en tant que service, souvent pour gérer les paiements ou permettre l’accès aux données ou aux applications

Chaque type d’API dans l’entreprise doit être régi pour garantir qu’il est sécurisé, fiable et accessible aux équipes et aux utilisateurs qui doivent y accéder.

Quels modèles de gouvernance d’API pouvez-vous utiliser ?

Il existe de nombreuses façons de définir et d’appliquer la gouvernance des API. Chez NGINX, nous voyons généralement les clients appliquer l'un des deux modèles :

  • Centralisé – Une équipe centrale examine et approuve les modifications ; selon l’ampleur des opérations, cette équipe peut devenir un goulot d’étranglement qui ralentit les progrès
  • Décentralisé – Les équipes individuelles ont l’autonomie nécessaire pour créer et gérer les API ; cela augmente le délai de mise sur le marché mais sacrifie la sécurité et la fiabilité globales

Cependant, à mesure que les entreprises progressent dans leur parcours API-first, les deux modèles commencent à s’effondrer à mesure que le nombre d’API en production augmente. Les modèles centralisés tentent souvent de mettre en œuvre une approche unique qui nécessite plusieurs examens et approbations en cours de route. Cela ralentit les équipes de développement et crée des frictions : dans leur frustration, les développeurs trouvent parfois même des moyens de contourner les exigences (le redoutable « shadow IT »).

L’autre modèle – la gouvernance décentralisée – fonctionne bien pour les développeurs d’API au début, mais avec le temps, la complexité augmente. À moins que les différentes équipes déployant des API communiquent fréquemment, l’expérience globale devient incohérente entre les API : chacune est conçue et fonctionne différemment, les changements de version entraînent des pannes entre les services et la sécurité est appliquée de manière incohérente entre les équipes et les services. Pour les équipes qui créent des API, le travail supplémentaire et la complexité finissent par ralentir considérablement le développement, tout comme le modèle centralisé.

Les applications cloud natives s’appuient sur des API permettant aux microservices individuels de communiquer entre eux et de renvoyer des réponses à la source de la demande. Alors que les entreprises continuent d’adopter les microservices pour leur flexibilité et leur agilité, la prolifération des API ne va pas disparaître . Au lieu de cela, vous avez besoin d’une approche différente pour gouverner les API dans ces environnements complexes et en constante évolution.

Utilisez la gouvernance adaptative pour donner plus de pouvoir aux développeurs d'API

Heureusement, il existe une meilleure solution. La gouvernance adaptative offre un modèle alternatif qui donne plus de pouvoir aux développeurs d’API tout en donnant aux équipes Platform Ops le contrôle dont elles ont besoin pour garantir la fiabilité et la sécurité des API dans toute l’entreprise.

Au cœur de la gouvernance adaptative se trouve l’équilibre entre le contrôle (le besoin de cohérence) et l’autonomie (la capacité de prendre des décisions locales) pour permettre l’agilité dans toute l’entreprise. En pratique, le modèle de gouvernance adaptative décompose et distribue la prise de décision entre les équipes.

Les équipes Platform Ops gèrent l'infrastructure partagée (passerelles API et portails de développeurs) et définissent des politiques globales pour garantir la cohérence entre les API. Les équipes qui créent des API agissent cependant en tant qu’experts en la matière pour leurs services ou leur secteur d’activité. Ils sont habilités à définir et à appliquer des politiques locales pour leurs API (contrôle d’accès basé sur les rôles (RBAC), limitation du débit de leur service, etc.) afin de répondre aux exigences de leurs contextes commerciaux individuels.

La gouvernance adaptative permet à chaque équipe ou secteur d’activité de définir ses flux de travail et d’équilibrer le niveau de contrôle requis, tout en utilisant l’infrastructure partagée de l’organisation.

Implémentez une gouvernance adaptative pour vos API avec NGINX

Lorsque vous commencez à planifier et à mettre en œuvre votre stratégie API, suivez ces bonnes pratiques pour mettre en œuvre une gouvernance adaptative dans votre organisation :

Voyons comment vous pouvez réaliser ces cas d’utilisation avec API Connectivity Manager , qui fait partie de F5 NGINX Management Suite.

Fournir une infrastructure partagée

Les équipes de votre organisation créent des API et doivent inclure des fonctionnalités similaires dans leurs microservices : authentification et autorisation, cryptage mTLS, etc. Ils doivent également mettre la documentation et les versions à la disposition de leurs consommateurs d'API, qu'il s'agisse d'équipes internes, de partenaires commerciaux ou de développeurs externes.

Plutôt que de demander aux équipes de créer leurs propres solutions, les équipes Platform Ops peuvent fournir un accès à une infrastructure partagée. Comme pour toutes les actions dans API Connectivity Manager, vous pouvez configurer cela en quelques minutes à l'aide de l'interface utilisateur ou de l'API REST entièrement déclarative, qui vous permet d'intégrer API Connectivity Manager dans vos pipelines CI/CD. Dans cet article, nous utilisons l’interface utilisateur pour illustrer certains flux de travail courants.

API Connectivity Manager prend en charge deux types d’espaces de travail : infrastructure et services. Les espaces de travail d'infrastructure sont utilisés par les équipes Platform Ops pour intégrer et gérer l'infrastructure partagée sous la forme de clusters de passerelle API et de clusters de portail de développeur. Les espaces de travail de services sont utilisés par les développeurs d'API pour publier et gérer les API et la documentation.

Pour configurer une infrastructure partagée, ajoutez d’abord un espace de travail d’infrastructure. Cliquez sur Infrastructure dans la colonne de navigation de gauche, puis sur le bouton + Ajouter dans le coin supérieur droit de l’onglet. Donnez un nom à votre espace de travail (ici, c'est team-sentence – une équipe imaginaire créant un simple « Hello, World ! ») (API).

Capture d'écran de la page Espaces de travail dans l'onglet Infrastructure de l'interface utilisateur d'API Connectivity Manager
Figure 1 : Ajouter des espaces de travail d'infrastructure

Ensuite, ajoutez un environnement à l’espace de travail. Les environnements contiennent des clusters de passerelle API et des clusters de portail de développeur. Cliquez sur le nom de votre espace de travail, puis sur l’icône dans la colonne Actions ; sélectionnez Ajouter dans le menu déroulant.

Le panneau Créer un environnement s’ouvre comme indiqué dans la Figure 2. Remplissez le champ Nom (et éventuellement Description ), sélectionnez le type d’environnement (production ou non-production) et cliquez sur le bouton + Ajouter pour l’infrastructure que vous souhaitez ajouter (clusters API Gateway, clusters Developer Portal ou les deux). Cliquez sur le bouton Créer pour terminer la configuration de votre environnement. Pour obtenir des instructions complètes, consultez la documentation d'API Connectivity Manager .

Capture d'écran du panneau Créer un environnement dans l'interface utilisateur d'API Connectivity Manager
Figure 2 : Créer un environnement et une infrastructure embarquée

Donnez de l'autonomie aux équipes

Il est logique de fournir une séparation logique aux équipes par secteur d’activité, région géographique ou autre limite logique, si cela ne les prive pas de l’accès aux outils dont elles ont besoin pour réussir. L’accès à une infrastructure partagée ne doit pas signifier que les équipes doivent se soucier des activités au niveau mondial. Au lieu de cela, vous souhaitez qu’ils se concentrent sur la définition de leurs propres exigences, l’élaboration d’une feuille de route et la création de leurs microservices.

Pour aider les équipes à s'organiser, les équipes Platform Ops peuvent fournir des services d'espaces de travail permettant aux équipes d'organiser et d'exploiter leurs services et leur documentation. Ils créent des limites logiques et donnent accès à différents environnements (développement, test et production, par exemple) pour développer des services. Le processus est similaire à la création de l’espace de travail d’infrastructure que nous avons créé dans la section précédente .

Tout d’abord, cliquez sur Services dans la colonne de navigation de gauche, puis sur le bouton + Ajouter dans le coin supérieur droit de l’onglet. Donnez et donnez un nom à votre espace de travail (ici, phrase API pour notre service « Hello, World »), et fournissez éventuellement une description et des coordonnées.

Capture d'écran de la page Espaces de travail dans l'onglet Services de l'interface utilisateur d'API Connectivity Manager
Figure 3 : Créer un espace de travail de services

À ce stade, vous pouvez inviter les développeurs d’API à commencer à publier des proxys et de la documentation dans l’espace de travail que vous avez créé pour eux. Pour obtenir des instructions complètes sur la publication de proxys API et la documentation, consultez la documentation d'API Connectivity Manager .

Équilibrer les politiques mondiales et le contrôle local

La gouvernance adaptative nécessite un équilibre entre l’application de politiques mondiales et l’autonomisation des équipes pour prendre des décisions qui stimulent l’agilité. Vous devez établir une séparation claire des responsabilités en définissant les paramètres globaux appliqués par Platform Ops et en définissant des « garde-fous » qui définissent les outils utilisés par les développeurs d’API et les décisions qu’ils peuvent prendre.

API Connectivity Manager fournit un mélange de politiques globales (appliquées à l'infrastructure partagée) et de contrôles granulaires gérés au niveau du proxy API.

Les politiques globales disponibles dans API Connectivity Manager incluent :

  • Format de réponse d'erreur – Personnalisez le code d'erreur et la structure de réponse de la passerelle API
  • Format du journal – Activez la journalisation des accès et personnalisez le format des entrées du journal
  • OpenID Connect – Accès sécurisé aux API avec une politique OpenID Connect
  • En-têtes de réponse – Inclure ou exclure les en-têtes dans la réponse
  • Taille du corps de la requête – Limitez la taille des charges utiles API entrantes
  • TLS entrant – Définir la politique pour les connexions TLS avec les clients API
  • Backend TLS – Sécurisez la connexion aux services backend avec TLS

Les stratégies de proxy API disponibles dans API Connectivity Manager incluent :

  • Méthodes HTTP autorisées – Définissez les méthodes de requête qui peuvent être utilisées ( GET , POST , PUT , etc.)
  • Contrôle d'accès – Accès sécurisé aux API à l'aide de différentes techniques d'authentification et d'autorisation (clés API, authentification de base HTTP, jetons Web JSON)
  • Contrôles de santé du back-end – Exécutez des contrôles de santé continus pour éviter les échecs de requêtes aux services back-end
  • CORS – Activer l’accès contrôlé aux ressources par les clients de domaines externes
  • Mise en cache – Améliorez les performances du proxy API avec les politiques de mise en cache
  • En-têtes de requête proxy – Transmettez les en-têtes sélectionnés aux services backend
  • Limitation du débit – Limitez les requêtes entrantes et sécurisez les charges de travail des API

Dans l’exemple suivant, nous utilisons l’interface utilisateur pour définir une politique qui sécurise la communication entre un proxy de passerelle API et les services back-end.

Cliquez sur Infrastructure dans la colonne de navigation de gauche. Après avoir cliqué sur le nom de l’environnement contenant le cluster de passerelle API que vous souhaitez modifier, l’onglet affiche les clusters de passerelle API et les clusters du portail des développeurs dans cet environnement.

Capture d'écran de la page Environnement dans l'onglet Infrastructure de l'interface utilisateur d'API Connectivity Manager
Figure 4 : Configurer les politiques globales pour les clusters API Gateway et les clusters Developer Portal

Dans la ligne du cluster API Gateway auquel vous souhaitez appliquer une stratégie, cliquez sur l’icône dans la colonne Actions et sélectionnez Modifier la configuration avancée dans le menu déroulant. Cliquez sur Stratégies globales dans la colonne de gauche pour afficher une liste de toutes les stratégies globales que vous pouvez configurer.

Capture d'écran de la page Stratégies globales dans l'interface utilisateur d'API Connectivity Manager
Figure 5 : Configurer les politiques pour un cluster de passerelle API

Pour appliquer la politique TLS Backend , cliquez sur l’icône à l’extrémité droite de sa ligne et sélectionnez Ajouter une politique dans le menu déroulant. Remplissez les informations demandées, téléchargez votre certificat et cliquez sur Ajouter . Cliquez ensuite sur le bouton Enregistrer et soumettre . Désormais, le trafic entre le cluster API Gateway et les services backend est sécurisé avec TLS. Pour obtenir des instructions complètes, consultez la documentation d'API Connectivity Manager .

Résumé

La planification et la mise en œuvre de la gouvernance des API constituent une étape cruciale pour garantir le succès de votre stratégie API. En travaillant vers un modèle distribué et en vous appuyant sur une gouvernance adaptative pour répondre aux exigences uniques des différentes équipes et API, vous pouvez faire évoluer et appliquer une gouvernance uniforme sans sacrifier la vitesse et l’agilité qui rendent les API et les environnements cloud natifs si productifs.

Commencer

Démarrez un essai gratuit de 30 jours de NGINX Management Suite , qui inclut l'accès à API Connectivity Manager , NGINX Plus en tant que passerelle API et NGINX App Protect pour sécuriser vos API.


« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."