Vos clients attendent l’excellence des API. Pouvez-vous livrer?

Sponsorisé Lorsque votre application fonctionne correctement, l’utilisateur expérimente l’harmonie de l’API. Sous le capot des applications modernes, les ingénieurs ont conçu et mis en œuvre des dizaines d’API qui communiquent entre elles.

Ces API évoluent vers le haut et vers le bas, demandent des informations et, lorsqu’elles fonctionnent correctement, offrent à l’utilisateur ce qui ressemble à une expérience d’application intuitive et ultra-rapide. Considérez une application populaire comme Lyft. Sous la jolie interface client, Lyft rassemble de nombreuses connexions API : pour le paiement, pour la géolocalisation, pour les appels vocaux, pour les images. Lyft comprend également une « API de conciergerie » qui permet aux développeurs d’autres applications de créer un bouton pour appeler des courses Lyft dans leurs propres expériences d’application.

À vrai dire, les API jouent depuis longtemps un rôle crucial dans la livraison des applications. Des résultats de football aux données sur l’état des vols en passant par les renseignements sur les menaces ou les taux d’utilisation de la mémoire d’instance AWS, la plupart des équipes d’application s’appuient sur des API tierces ou servies en interne pour faire briller les applications modernes. La différence est dans le degré. Au cours des dernières années, les API sont passées d’une partie de la conception d’applications à la quasi-totalité de la conception d’applications. Les API contrôlent tous les aspects, du panier d’achat à la gestion du trafic est-ouest dans le centre de données. À cet égard, nous sommes entrés dans un nouveau territoire avec les API.

Avec l’essor de Kubernetes, des conteneurs et des microservices, les architectures d’applications modernes ont changé d’orientation. Dans Kubernetes et les microservices, les fonctions découplées communiquent entre elles via l’API. (Kubernetes est conçu comme un moteur d’orchestration axé sur les API.) Dans ce nouveau domaine, la conception et la gestion des API deviennent d’une importance cruciale. Vos API sont vos microservices sont vos applications. Votre approche de conception et de gestion des API est tout aussi importante que celles des données, de la confidentialité, du calcul et de la mise en réseau, et est également cruciale pour le succès de n’importe lequel de ces domaines.

Concevoir une expérience API 2.0 : quatre principes

Cela présente à la fois des défis et des opportunités – ce que nous appelons un voyage vers API Experience 2.0. Nous connaissons tous les termes UX, DX et CX. Il est temps pour nous de reconnaître et de définir un autre terme – API Experience ou APIX. À l’avenir, étant donné que les équipes de développement passeront beaucoup de temps à travailler avec et autour des API, la façon dont elles expérimentent ces API deviendra un élément clé des exigences et des critères d’évaluation pour les équipes DevOps et GitOps. APIX a également un impact direct sur les utilisateurs, à la fois internes et externes. Lorsque APIX est loin d’être génial, les utilisateurs vivront des expériences d’utilisateur et d’application moins que parfaites.

APIX 2.0 commence par une réflexion sur ce qui peut être amélioré dans la manière dont les API sont architecturées, mises en œuvre et gérées. Au cœur de ce parcours se trouve la transformation de la gestion des API (APIM) et la modernisation des passerelles API pour rester en phase avec les architectures d’applications émergentes et évolutives. Cela doit être fait d’un point de vue centré sur l’utilisateur, à la fois pour les utilisateurs finaux et les utilisateurs-développeurs. Toutes les API cachent dans une certaine mesure la complexité de l’entreprise et prennent quelque chose qui aurait été difficile à construire et le rendent facile à utiliser. Le défi consiste à s’assurer que les API sont conçues de manière uniforme et sécurisée, faciles à utiliser et performantes.

Principe 1 : Concevoir une expérience uniforme basée sur des directives explicites

Chaque entreprise créant et consommant des API à grande échelle devrait envisager de créer des directives de conception d’API et une liste de contrôle d’évaluation des API. Cela permet à votre équipe de standardiser la conception et la prise en compte des API pour l’adoption et l’utilisation. À l’ère des équipes distribuées, pilotées par des microservices, de nombreux propriétaires de services sont responsables de la conception et de la maintenance de leurs API. L’application de règles communes relatives aux normes et politiques d’API améliore l’efficacité de la planification et de la conception, du développement, des tests, du déploiement et du retrait d’une API. Cela peut se résumer à des questions assez simples telles que : l’API est-elle bien documentée ? A-t-il une politique de sécurité spécifique ? Quelle est la capacité de l’API ? L’API a-t-elle un propriétaire clair ? Pouvez-vous gérer l’utilisation de l’API avec des outils ou des passerelles de gestion d’API courants ?

Ces principes atténuent la complexité qui accompagnait auparavant la gestion des cycles de vie des API. La gestion des cycles de vie des API est un défi de taille car l’aspect gouvernance imposé par les architectes de sécurité et d’entreprise n’est généralement pas pris en compte par les développeurs. Cette gestion du cycle de vie des API implique une collaboration entre les développeurs et les consommateurs, car les itérations des API sont versionnées et emballées dans plusieurs produits pour la distribution. Trop souvent, les entreprises essaient de plier les outils APIM pour s’adapter à diverses API – une gestion efficace des API « boulonnée ». Cela crée de la complexité, des cas extrêmes et des problèmes. En fait, l’inverse est préférable, où l’API est conçue ou repensée pour correspondre aux directives. En procédant ainsi, vous obtiendrez de meilleurs résultats APIX.

Étant donné que les API sont utilisées dans les applications mobiles, cloud et sur site, les passerelles API peuvent fournir un point central où les chefs d’entreprise et les parties prenantes appliquent les meilleures pratiques et contrôles ou garantissent que les bonnes politiques sont appliquées à chaque ensemble d’API.

Ce cheminement vers APIX 2.0 ne nécessite pas nécessairement que votre organisation soulève et déplace vos applications héritées vers le cloud. Par exemple, au lieu d’arrêter ou de reconstruire un système de base hérité, une banque peut développer des API qui permettent aux applications modernes d’accéder à ses données. À Singapour, Deloitte a collaboré avec l’Association of Banks et la Monetary Authority pour identifier et mapper 5 636 systèmes et processus commerciaux communs aux sociétés de services financiers à une collection de 411 API. Ces API aident à accélérer le développement de solutions allant du financement commercial basé sur la blockchain à une expérience de succursale de vente au détail en réalité virtuelle.

Tout cela est grandement amélioré lorsqu’une organisation crée des directives explicites pour la conception et l’approbation des API.

Principe 2 : Formaliser la propriété du service

Au-delà de l’équipe de développement logiciel, n’importe quelle partie de l’organisation peut publier ses propres API ou utiliser des API tierces. Par conséquent, l’inventaire des API utilisées est une première étape essentielle vers l’établissement de contrôles d’API adéquats pouvant être gérés de manière centralisée et même automatisés.

Les outils APIM peuvent rendre les API plus détectables en incorporant un inventaire de services ou un catalogue de services. Avec des milliers d’API exécutées à tout moment, il est très difficile de suivre le nombre de services et ce qu’ils font. En d’autres termes, un élément clé d’APIX 2.0 cohérent est le catalogue de services. L’enregistrement de la propriété des services du catalogue offre également la visibilité nécessaire pour gérer le cycle de vie des API, car les API sont exploitées de manière distribuée.

Dans le catalogue, une équipe ou un propriétaire doit être défini pour chaque service ou groupe de services. Sans établir la propriété du service, la gestion du cycle de vie de l’API n’est pas possible. Diverses API peuvent fonctionner sans surveillance pendant des années ; restant actif mais oublié. Une API abandonnée mais active pose un risque de sécurité énorme ; Les API sont de plus en plus ciblées par les criminels pour des attaques contre des institutions de services financiers, par exemple.

L’intégration du concept de catalogue de services dans l’outil APIM permet à l’entreprise d’avoir une image complète de la façon dont les services fonctionnent et qui les utilise, et de prendre des décisions plus judicieuses sur les API à conserver et celles à supprimer. Par exemple, il est probablement inutile d’exécuter un service qui ne prend que 10 requêtes par jour. Au lieu de cela, vous pouvez décider de regrouper des API de différents secteurs d’activité (LOB) ou unités commerciales (BU) en tant que produit. Mais sans propriété explicite des API, ces considérations prennent du temps et sont pénibles.

En conclusion, une API sans propriétaire peut être pire que pas d’API du tout.

Principe 3 : Conception pour des économies d’échelle, des économies de gamme, ou les deux

D’autres facteurs clés dans la conversation APIX 2.0 sont les économies d’échelle et les économies de gamme. Des entreprises comme Netflix peuvent se concentrer étroitement sur le streaming, mais l’échelle à laquelle elles opèrent est astronomique. Ces entreprises doivent être en mesure de fournir des API et des services à grande échelle. Ils bénéficient d’un coût moyen plus faible de gestion des cycles de vie d’un volume croissant de services.

D’un autre côté, les banques doivent généralement se concentrer sur des économies de gamme plus importantes pour soutenir leurs nombreux produits et unités commerciales. Ces entreprises privilégient la fonctionnalité à l’évolutivité. Ils bénéficient de coûts moyens inférieurs lorsque les coûts sont répartis sur une plus grande variété de services. Les organisations qui conçoivent pour optimiser APIX et offrir une expérience API 2.0 premium doivent reconnaître l’économie de conception qu’elles recherchent dans chaque API et en tenir compte dans les décisions de regroupement, de mise à l’échelle, de sécurisation des API internes ou d’utilisation d’API externes.

En d’autres termes, sachez pour quelle économie vous construisez ou essayez d’imiter et utilisez-la pour guider votre conception et vos choix d’API.

Principe 4 : Facilitez la gestion

Pour fournir APIX 2.0, les DSI doivent également faire face à la tyrannie de la complexité dans les environnements applicatifs d’aujourd’hui. Les passerelles API sont conçues pour apprivoiser cette complexité. La passerelle doit gérer les API tierces, les API des microservices et les API légèrement exposées enfouies dans des monolithes.

Alors que les API facilitent la création et la gestion des microservices, les solutions APIM traditionnelles ne sont pas conçues pour gérer les environnements conteneurisés, natifs du cloud et multi-cloud. Les API sophistiquées nécessitent souvent des interactions entre plusieurs applications et services, avec une logique métier complexe. Cette complexité et cette chaîne d’interactions dépendantes imbriquées augmentent les risques de sécurité et l’exposition des données sensibles.

Pour cette raison, le module de gestion d’API du contrôleur NGINX présente une architecture innovante qui réduit la complexité. En découplant le plan de données (NGINX Plus) et le plan de contrôle (le module de gestion d’API), le trafic d’exécution d’API est isolé du trafic d’APIM pour permettre un traitement plus déterministe et efficace.

À titre d’exemple, après avoir déployé NGINX comme passerelle API, CapitalOne a pu mettre hors service trois passerelles commerciales tout en traitant 12 milliards de requêtes par jour avec des latences aussi faibles que 10 millisecondes.

Conclusion : Vous êtes déjà sur la voie d’un APIX génial

Que vous l’ayez dit ou non, il y a de fortes chances que vous et votre équipe soyez déjà en train de construire un APIX 2.0. C’est le résultat naturel de l’adoption et de la croissance des APIM et des passerelles API. Une gestion efficace des APIM et des passerelles aide les entreprises à intégrer des systèmes internes et à briser les silos, à favoriser la collaboration entre les développeurs et les équipes fonctionnelles et à connecter les microservices. APIM peut rendre visible la propriété des clés et les propriétés de sécurité des API. En déployant efficacement APIM et les passerelles sur la base des directives que vous avez créées, vous et votre équipe pouvez offrir une expérience uniforme tout au long du cycle de vie de vos applications hébergées dans n’importe quel endroit. Vous pouvez le faire, qu’il s’agisse d’un projet cloud natif ou d’applications héritées exécutées dans des centres de données sur site.

Cela dit, un grand APIX ne se produit pas tout simplement. Il doit s’agir d’un effort conscient, soigneusement guidé et géré. Nous espérons que les quatre principes que j’ai exposés ici, avec l’aide d’un certain nombre d’experts clés en API dans F5, peuvent vous donner une base solide pour concevoir une meilleure expérience API pour votre développeur, vos clients, vos partenaires et vos utilisateurs. Les API sont désormais les routes et les ponts qui rendent possibles les architectures d’applications modernes. La maintenance et le développement de cette infrastructure d’API virtuelle joueront un rôle important dans le succès de vos applications et, par extension, celui de votre entreprise.

Sponsorisé par NGINX (partie de F5)