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

Andrew Stiefel

Les entreprises d’aujourd’hui sont souvent composées d’équipes réparties dans le monde entier, qui développent 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 au moins trois environnements, qu’il s’agisse du cloud public, du cloud privé, d’infrastructures sur site ou de l’edge.

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

Avec la multiplication actuelle des API et des microservices, la gouvernance des API devient rapidement l’un des sujets les plus importants pour planifier et mettre en œuvre une stratégie d’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 d’API ?

Qu’est-ce que la gouvernance des API ?

À son niveau le plus élémentaire, la gouvernance des API consiste à définir des politiques et à effectuer des contrôles et des validations afin de garantir que les API sont faciles à trouver, fiables, observables et sécurisées. Elle offre une visibilité sur l’état des systèmes complexes et des processus métier qui sous-tendent vos applications modernes, ce qui vous permet d’orienter l’évolution de votre infrastructure d’API au fil du temps.

Pourquoi avez-vous besoin d’une gouvernance des API ?

L’importance stratégique de la gouvernance des API ne saurait être surestimée : c’est grâce à elle que vous concrétisez la stratégie globale de votre organisation en matière d’API. Sans une gouvernance adéquate, vous ne pourrez jamais garantir la cohérence de la conception, de l’exploitation et de la commercialisation de vos API.

Lorsqu’elle est mal mise en œuvre, la gouvernance impose souvent des exigences contraignantes qui ralentissent les équipes. En revanche, lorsqu’elle est bien menée, la gouvernance des API réduit la charge de travail, simplifie les processus d’approbation et permet aux différentes équipes de votre organisation de fonctionner de manière autonome tout en contribuant aux objectifs globaux de votre stratégie d’API.

Quels types d’API devez-vous gouverner ?

L’élaboration d’un plan efficace de gouvernance des API dans le cadre de votre stratégie d’API commence par l’identification des types d’API que vous utilisez en production, ainsi que des outils, des politiques et des directives nécessaires à leur gestion. Aujourd’hui, la plupart des équipes en entreprise travaillent avec quatre principaux types d’API :

• API externes – Mises à la disposition des consommateurs et développeurs externes pour leur permettre d’intégrer en libre-service des données et des fonctionnalités
• API internes – Utilisées pour connecter les applications internes et les microservices, et accessibles uniquement aux développeurs de votre organisation
• API partenaires – Facilitent les relations commerciales stratégiques en partageant l’accès à vos données ou applications avec les développeurs des organisations partenaires
• API tierces – Utilisées comme un service fourni par des prestataires tiers, souvent pour traiter les paiements ou permettre l’accès à des données ou à des applications

Chaque type d’API au sein de l’entreprise doit être régi afin de garantir sa sécurité, sa fiabilité et son accessibilité aux équipes et aux utilisateurs qui en ont besoin.

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

Il existe de nombreuses façons de définir et de mettre en œuvre la gouvernance des API. Chez NGINX, nous constatons généralement que les clients appliquent l’un des deux modèles suivants :

• 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 disposent de l’autonomie nécessaire pour créer et gérer des API ; cela accélère la mise sur le marché, mais compromet la sécurité et la fiabilité globales

Cependant, à mesure que les entreprises progressent dans leur démarche API-first, les deux modèles commencent à montrer leurs limites lorsque le nombre d’API en production augmente. Les modèles centralisés cherchent souvent à mettre en œuvre une approche universelle qui nécessite différentes revues et validations tout au long du processus. Cela ralentit les équipes de développement et crée des frictions. Frustrés, les développeurs trouvent même parfois des moyens de contourner les exigences (le redoutable « shadow IT »).

L’autre modèle, celui de la gouvernance décentralisée, fonctionne bien au départ pour les développeurs d’API, mais sa complexité augmente au fil du temps. Si les différentes équipes qui déploient des API ne communiquent pas régulièrement, l’expérience globale devient incohérente d’une API à l’autre : chacune est conçue et fonctionne différemment, les changements de version entraînent des interruptions de service et les règles de sécurité ne sont pas appliquées de manière uniforme entre les équipes et les services. Pour les équipes qui développent les API, la charge de travail et la complexité supplémentaires finissent par ralentir considérablement le développement, tout comme dans le modèle centralisé.

Les applications cloud natives s’appuient sur les API pour permettre aux différents microservices de communiquer entre eux et de renvoyer les réponses à l’origine de la requête. Alors que les entreprises continuent d’adopter les microservices pour leur flexibilité et leur agilité, la prolifération des API n’est pas près de disparaître. Il vous faut donc adopter une approche différente pour gouverner les API dans ces environnements complexes en constante évolution.

Utilisez une gouvernance adaptative pour donner plus d’autonomie aux développeurs d’API

Heureusement, il existe une meilleure approche. La gouvernance adaptative propose un modèle alternatif qui donne davantage d’autonomie aux développeurs d’API, tout en offrant aux équipes chargées des opérations de la plateforme le contrôle nécessaire pour garantir la fiabilité et la sécurité des API dans toute l’entreprise.

La gouvernance adaptative repose sur un équilibre entre le contrôle (le besoin de cohérence) et l’autonomie (la capacité à prendre des décisions localement), afin de favoriser l’agilité dans toute l’entreprise. En pratique, le modèle de gouvernance adaptative décentralise et répartit la prise de décision entre les équipes.

Les équipes chargées des opérations de plateforme gèrent l’infrastructure partagée (passerelles API et portails pour développeurs) et définissent des politiques globales afin de garantir la cohérence entre les API. Les équipes qui développent les API sont toutefois les expertes de leurs services ou de leur secteur d’activité. Elles sont habilitées à définir et à appliquer des politiques locales à leurs API – contrôle d’accès basé sur les rôles (RBAC), limitation du débit pour leur service, etc. – afin de répondre aux exigences propres à leurs contextes métier.

La gouvernance adaptative permet à chaque équipe ou secteur d’activité de définir ses workflows et de trouver le juste équilibre quant au niveau de contrôle requis, tout en utilisant l’infrastructure partagée de l’organisation.

Mettez en œuvre une gouvernance adaptative pour vos API avec NGINX

Lorsque vous commencez à planifier et à mettre en œuvre votre stratégie d’API, suivez ces bonnes pratiques pour instaurer une gouvernance adaptative au sein de votre organisation :

• Fournir une infrastructure partagée – Fournissez aux équipes un accès à des passerelles d’API et à des portails pour développeurs afin de publier des proxys d’API et de la documentation
• Donner de l’autonomie aux équipes – Aidez les équipes à intégrer et à gérer le cycle de vie de leurs API au sein d’un espace de travail partagé
• Concilier les politiques globales et le contrôle local – Définissez des politiques globales pour l’infrastructure partagée tout en permettant aux équipes de contrôler précisément leurs services

Voyons comment vous pouvez mettre en œuvre ces cas d’usage avec API Connectivity Manager, qui fait partie de F5 NGINX Management Suite.

Fournir une infrastructure partagée

Les équipes de votre organisation développent des API et doivent intégrer des fonctionnalités similaires à leurs microservices : authentification et autorisation, chiffrement mTLS, entre autres. Elles doivent également mettre la documentation et les informations de version à la disposition des utilisateurs de leurs API, qu’il s’agisse d’équipes internes, de partenaires commerciaux ou de développeurs externes.

Plutôt que de demander aux équipes de développer leurs propres solutions, les équipes chargées des opérations de la plateforme peuvent leur donner accès à une infrastructure partagée. Comme pour toutes les actions dans API Connectivity Manager, vous pouvez configurer cette infrastructure en quelques minutes seulement, soit à l’aide de l’interface utilisateur, soit à l’aide de l’API REST entièrement déclarative, qui vous permet d’intégrer API Connectivity Manager à vos pipelines CI/CD. Dans cet article, nous utilisons l’interface utilisateur pour illustrer quelques workflows courants.

API Connectivity Manager prend en charge deux types d’espaces de travail : infrastructure et services. Les espaces de travail d’infrastructure permettent aux équipes chargées des opérations de la plateforme d’intégrer et de gérer une infrastructure partagée sous la forme de clusters de passerelles API et de clusters de portails pour développeurs. Les espaces de travail de services permettent aux développeurs d’API de publier et de gérer des API et de la documentation.

Pour configurer une infrastructure partagée, commencez par ajouter 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, team-sentence, une équipe fictive qui développe une API simple « Hello, World! »).

Figure 1 : ajouter des espaces de travail d’infrastructure

Ajoutez ensuite un environnement à l’espace de travail. Les environnements contiennent des clusters de passerelles API et des clusters de portails pour développeurs. 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 illustré à la figure 2. Renseignez le champ Nom (et, éventuellement, le champ Description), sélectionnez le type d’environnement (production ou hors production), puis cliquez sur le bouton + Ajouter correspondant à l’infrastructure que vous souhaitez ajouter (clusters de passerelles API, clusters de portails pour développeurs, 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.

Figure 2 : créer un environnement et intégrer une infrastructure

Donnez de l’autonomie aux équipes

Il est pertinent de séparer logiquement les équipes par secteur d’activité, zone géographique ou selon toute autre délimitation logique, à condition que 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 devrait pas obliger les équipes à se préoccuper des activités à l’échelle globale. Elles devraient plutôt pouvoir se concentrer sur la définition de leurs propres besoins, l’élaboration d’une feuille de route et le développement de leurs microservices.

Pour aider les équipes à s’organiser, les équipes Platform Ops peuvent leur fournir des espaces de travail dédiés aux services afin qu’elles puissent organiser et exploiter leurs services et leur documentation. Ces espaces 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 à celui de la création de l’espace de travail d’infrastructure que nous avons effectuée 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 un nom à votre espace de travail (ici, api-sentence pour notre service « Hello, World ») et, si vous le souhaitez, ajoutez une description et des coordonnées.

Figure 3 : Créer un espace de travail pour les 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 d’API et de documentation, consultez la documentation d’API Connectivity Manager.

Concilier les politiques globales et le contrôle local

La gouvernance adaptative exige de trouver un équilibre entre l’application de politiques globales et l’autonomie accordée aux équipes afin qu’elles puissent prendre des décisions favorisant l’agilité. Vous devez établir une répartition claire des responsabilités en définissant les paramètres globaux imposés par les équipes Platform Ops et en mettant en place des « garde-fous » qui déterminent les outils que les développeurs d’API peuvent utiliser ainsi que les décisions qu’ils peuvent prendre.

API Connectivity Manager propose une combinaison de politiques globales (appliquées à l’infrastructure partagée) et de contrôles granulaires gérés au niveau du proxy d’API.

Les stratégies globales disponibles dans API Connectivity Manager comprennent :

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

Les stratégies de proxy d’API disponibles dans API Connectivity Manager comprennent :

• Méthodes HTTP autorisées – Définissez les méthodes de requête pouvant être utilisées (GET, POST, PUT, etc.)
• Contrôle d’accès – Sécurisez l’accès aux API à l’aide de différentes techniques d’authentification et d’autorisation (clés API, authentification HTTP Basic, jetons Web JSON)
• Contrôles de l’état des services backend – Effectuez des contrôles d’état continus afin d’éviter l’échec des requêtes adressées aux services backend
• CORS – Autorisez un accès contrôlé aux ressources pour les clients provenant de domaines externes
• Mise en cache – Améliorez les performances du proxy d’API grâce à des stratégies de mise en cache
• En-têtes de requête du proxy – Transmettre certains en-têtes 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 les communications entre un proxy API Gateway et les services backend.

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 de portail des développeurs de cet environnement.

Figure 4 : Configurer les politiques globales pour les clusters de passerelles d’API et les clusters de portails des développeurs

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

Figure 5 : Configurer des stratégies pour un cluster API Gateway

Pour appliquer la stratégie TLS Backend, cliquez sur l’icône … située à l’extrémité droite de sa ligne, puis sélectionnez Add Policy dans le menu déroulant. Saisissez les informations demandées, chargez votre certificat, puis cliquez sur Add. Cliquez ensuite sur le bouton Save and Submit. Désormais, le trafic entre le cluster API Gateway et les services backend est sécurisé par 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 assurer la réussite de votre stratégie d’API. En adoptant progressivement un modèle distribué et en vous appuyant sur une gouvernance adaptative pour répondre aux besoins spécifiques des différentes équipes et API, vous pouvez évoluer et appliquer une gouvernance uniforme sans sacrifier la rapidité et l’agilité qui rendent les API et les environnements cloud natifs si productifs.

Commencer

Commencez un essai gratuit de 30 jours de NGINX Management Suite, qui comprend l’accès à API Connectivity Manager, à NGINX Plus en tant que passerelle d’API, ainsi qu’à NGINX App Protect pour sécuriser vos API.

À propos de l’auteur

Andrew Stiefel

Autres articles de Andrew Stiefel