Luis Weir explique comment les API peuvent alimenter la croissance de l’entreprise

La gestion des API est une discipline qui a évolué pour fournir les processus et les outils nécessaires pour découvrir, concevoir, mettre en œuvre, utiliser ou exploiter des API de niveau entreprise. La discipline divise en deux deux communautés distinctes et mérite l’attention des deux: les développeurs qui créent des API et les chefs d’entreprise et informatiques qui recherchent des API pour stimuler la croissance.

Dans Gestion des API d’entreprise, Luis Weir montre comment définir la bonne architecture, implémenter les bons modèles et définir le bon modèle d’organisation pour les API métier. Le livre explore les décisions architecturales, les modèles de mise en œuvre et les pratiques de gestion pour des API d’entreprise réussies. Il donne également des conseils clairs et exploitables sur le choix et l’exécution de la bonne stratégie d’API dans votre entreprise.

Voyons ce que Luis a à dire sur la gestion des API et les principes clés pour améliorer la conception d’API pour les entreprises.

Ce qu’implique la gestion des API

Que signifie et qu’implique la gestion des API?

Luis Weir: En termes simples, c’est la discipline qui aligne les outils avec les processus et les personnes afin de tirer parti de la valeur de la mise en œuvre d’API de niveau entreprise tout au long de leur cycle complet. Par entreprise, j’entends des API qui respectent un ensemble minimum de normes de qualité, non seulement dans l’API elle-même (par exemple, utilisation d’une sémantique normalisée, d’interfaces bien documentées et d’une bonne expérience utilisateur), mais aussi dans les processus d’ingénierie derrière leur livraison (par exemple, pipelines CICD et automatisation robuste à tous les niveaux, différents niveaux de test, etc.).

Principes directeurs pour la conception d’API

Quels sont les principes directeurs qui peuvent améliorer la conception des API?

LW: Tout d’abord, l’identification des API elles-mêmes. Il ne s’agit pas seulement de créer une API pour le plaisir et la valeur viendra. Sans adopter un processus (par exemple, l’idéation) qui puisse aider à identifier les API qui peuvent vraiment ajouter de la valeur, il y a un risque réel qu’une API finisse par être un DOA (mort à l’arrivée), car il pourrait même ne pas être nécessaire.

En supposant qu’un tel processus a eu lieu et que les API qui ont un réel potentiel d’ajouter de la valeur ont été identifiées, l’étape suivante consiste à conceptualiser une conception. C’est à ce stade que des disciplines telles que la conception axée sur le domaine peuvent aider à produire une telle conception de manière à ce que les professionnels et les informaticiens puissent s’y rapporter. Cette conception doit capturer des éléments tels que la consommation d’applications, la production d’applications (sources de données), les entités de données et les services impliqués dans le concept. Il doit définir clairement et simplement la relation entre les composants et définir les limites (contextes délimités) car ceux-ci seront essentiels non seulement dans la mise en œuvre réelle de l’API ou des API (car cela peut finir par être plus qu’un seul), mais aussi dans la création des spécifications d’API elles-mêmes pensait aux IDL (par exemple un fichier OAS, un plan d’API, un schéma GraphQL, un fichier .proto dans gRPC pour n’en nommer que quelques-uns).

L’étape suivante et très importante pour produire une bonne API est de suivre un processus de conception d’API d’abord. Ce processus garantit que les spécifications API et les simulations API (produites à partir des spécifications API elles-mêmes) subissent une série de validations par les consommateurs potentiels de l’API eux-mêmes ainsi que par d’autres parties concernées. L’idée est d’obtenir autant de commentaires que possible grâce à plusieurs itérations (ou boucles de rétroaction) pour s’assurer que l’API est adaptée à son objectif mais qu’elle offre également une bonne expérience utilisateur.

Pour plus de détails, veuillez consulter le Cycle de vie de l’API section dans mon livre.

Test des API

Quelles sont les différentes approches de test d’API?

LW: Au minimum, les tests d’API doivent impliquer les approches de test suivantes:

• Test d’interface
• Test fonctionel
• Test de performance
• Test de sécurité

Les tests d’interface sont utilisés pour valider qu’une implémentation d’API est conforme à la spécification d’API. Les tests fonctionnels sont utilisés pour valider que l’API fournit les fonctionnalités qu’elle est censée fournir et avec le comportement attendu. Les tests de performances garantissent que les API peuvent réellement gérer le volume attendu et évoluer selon les besoins. Les tests de sécurité garantissent que l’API n’est pas vulnérable aux threads courants tels que ceux décrits dans les 10 meilleurs projets OWASP.

D’autres approches de test plus sophistiquées peuvent inclure les tests A / B et les tests Chaos. Les tests A / B testent de manière dynamique les nouvelles fonctionnalités de l’API par rapport à un sous-ensemble de l’audience de l’API et dans un environnement en cours d’exécution (même en production). Les tests de chaos (par exemple, l’arrêt aléatoire des composants de la solution en production pour garantir la résilience de l’API) doivent être envisagés à mesure que l’initiative d’API mûrit.

Comprendre les passerelles API

Quelles sont les principales fonctionnalités d’une passerelle API?

LW: Il existe de nombreuses fonctionnalités attendues d’une passerelle API et elles sont toutes bien décrites dans la section d’exposition API de mon livre. Cependant, en plus de ces capacités, qui à mon avis sont toutes essentielles, certaines fonctionnalités clés distinguent les passerelles API modernes (3ème génération) des passerelles plus traditionnelles (1ère et 2ème génération). Ceux-ci sont:

• Poids léger: Nécessite un minimum d’espace disque, de CPU et de RAM pour fonctionner.
• Hybride: Peut fonctionner sur site, sur le cloud et sur plusieurs plates-formes cloud (par exemple AWS, Azure, Google, Oracle, etc).
• Kubernetes prêt: k8s est devenu la plate-forme d’exécution la plus populaire pour les microservices. Les API modernes doivent être facilement déployées dans l’environnement d’exécution K8 et prendre en charge la plupart des modèles décrits dans mon livre.
• Plan de contrôle commun: Si la gestion des API déployées sur les passerelles n’est pas centralisée d’une manière, d’une forme ou d’une autre, alors permettre aux utilisateurs d’entreprise de découvrir et de (ré) utiliser des API déjà construites (ou en cours de construction) sera extrêmement difficile et conduira à un beaucoup de duplication. Nous l’avons déjà vu à l’époque de la SOA. Les passerelles d’API modernes devraient donc être connectables aux plans de contrôle qui prennent en charge des éléments tels que la gestion du cycle de vie des API et la gestion des infrastructures de passerelle.
• Téléphone-maison: Il s’agit d’une fonctionnalité clé que peu de passerelles modernes prennent encore en charge. La capacité d’une passerelle API à établir la communication avec le niveau de gestion via le plan de contrôle (Phone-home) à l’aide de ports standard est essentielle dans les architectures hybrides pour éviter la mise en réseau et d’autres contraintes de sécurité.

Gestion des API d’entreprise, Je pense, fournit un aperçu assez complet de ce à quoi ressemblent les plates-formes d’API modernes et comment les différencier avec des plates-formes plus traditionnelles.

Erreurs courantes dans la gestion des API

Quelles sont les erreurs courantes que font les gens dans la gestion des API?

LW: Tout au long de mon temps en tant que stratège et praticien API, j’ai vu de nombreuses erreurs et j’en ai également fait moi-même. L’important est de pouvoir reconnaître ce qu’ils sont et d’en tirer des leçons. Le top 3 qui me vient à l’esprit:

Penser que la gestion des API consiste simplement à implémenter un produit ou des outils sans avoir de valeur commerciale et client à l’épicentre de la stratégie API. (Parfois, il n’y a même pas de stratégie d’API.) C’est peut-être la plus courante, et celle qui s’est souvent produite à l’époque de la SOA … se produit malheureusement encore à l’ère moderne des API. Mon livre, Enterprise API Management, peut être utilisé comme guide pour éviter de faire une initiative de gestion d’API moins sur les outils et plus sur la valeur commerciale / client, les personnes et les processus.

Penser que toutes les API sont les mêmes et donc les traiter toutes de la même manière. Dans certains cas, cela se produit accidentellement, dans d’autres, cela permet d’éviter de «superposer» les API parce que «les architectures de microservices et les praticiens le disent». Le fait est qu’une API conçue spécifiquement pour prendre en charge une application mobile donnée sera moins générique et moins adaptée à son utilisation en dehors du «  contexte  » sur lequel elle a été construite, par rapport à une API qui a été construite. sans aucune application consommatrice spécifique à l’esprit (et n’est donc couplée à aucun cycle de vie d’application).

Adopter le mauvais modèle d’organisation pour fournir des capacités d’API dans toute l’entreprise. Par exemple, cela pourrait être un modèle qui centralise tous les efforts et capacités de l’API, devenant ainsi un goulot d’étranglement et devenant finalement lent (c’est-à-dire l’informatique traditionnelle). Les initiatives d’API modernes devraient envisager l’adoption de modèles de plates-formes avec libre-service à l’épicentre.

En plus des 3 ci-dessus, il existe de nombreux pièges courants en matière d’architecture et de conception d’API. Cependant, pour couvrir ces derniers, je recommande fortement mon exposé sur les 7 péchés capitaux de la conception d’API…

Gestion des API et DevOps

Que pensez-vous de la gestion des API de 3e génération ayant un impact énorme sur DevOps?

LW: Réussir dans la gestion moderne des API et des architectures de microservices nécessite des changements au-delà de la technologie et nécessite également de plonger profondément dans l’organisation et sa culture. Cela signifie s’éloigner des livraisons traditionnelles basées sur des projets, dans lesquelles les équipes se réunissent juste pour la durée d’un projet et remettent le logiciel livré (par exemple, une API et les services associés) à différentes équipes de support. Au lieu de cela, passez à une organisation basée sur les produits dans laquelle les équipes sont rassemblées autour de capacités commerciales et conservent la responsabilité et la propriété tout au long du cycle de vie du produit.

Ce changement fondamental d’approche dans la fourniture de logiciels signifie qu’il n’y a plus de division entre les équipes de développement et d’exploitation, car une équipe produit a la pleine propriété et la responsabilité de son produit. Cela dit, afin d’éviter de (re) construire ces équipes de produits et de maintenir les capacités informatiques de base à partir de zéro (par exemple, les plates-formes API et les environnements d’exécution des services), un modèle d’exploitation de plate-forme peut être adopté. Ce modèle peut offrir des capacités informatiques communes, bien que de manière décentralisée, à la demande et en libre-service.

Et pour moi, accomplir ce qui précède est un vrai DevOps. C’est à ce stade que les organisations peuvent devenir plus agiles et peuvent vraiment augmenter leur temps sur les marchés.

Quels étaient vos buts et objectifs dans ce livre, et dans quelle mesure pensez-vous les avoir atteints?

LW: Lorsque j’ai commencé à définir et à mettre en œuvre des stratégies d’API et de microservices dans de grandes entreprises (dont beaucoup Fortune 500), même s’il y avait beaucoup de contenu autour duquel m’inspirer (une grande partie de ce contenu référencé dans mon livre), j’ai dû littéralement passer par plusieurs des articles, des livres, des vidéos et autres afin de concevoir une approche descendante dirigée par l’entreprise pour fournir des stratégies d’API et de microservices de bout en bout.

Quand je dis de bout en bout, cela ne signifie pas simplement définir des PowerPoints et de longs documents Word expliquant comment fournir des stratégies API / Microservices, puis simplement s’éloigner. Ou pire, assis sur le côté avec une opinion mais sans responsabilité (malheureusement, trop courant dans le monde du conseil – beaucoup de consultants seniors avec des opinions bien arrêtées mais qui ont peu ou pas de connaissances pratiques et d’expérience réelles). Il s’agit plutôt de donner l’exemple, de définir la stratégie et de la livrer avec toutes ses implications.

Avec ce livre, j’ai donc voulu partager avec la communauté une approche que j’ai créée, évoluée au fil des années et que j’ai vu fonctionner. Ce n’est pas seulement de la théorie, mais un mélange de théorie et de pratique. Ce ne sont pas seulement des idées, mais des idées que j’ai mises en pratique. Ce livre concerne le partage de mes expériences réelles et de mon approche dans la mise en œuvre de stratégies d’API et de microservices.

Par conséquent, je pense (ou j’espère) avoir atteint mes objectifs avec ce livre. J’ai senti qu’il y avait des trucs formidables axés sur des choses spécifiques du «bout en bout» mais pas sur le «bout en bout» réel, ce que je voulais couvrir dans ce livre. Je ne voulais pas être trop haut niveau ou trop détaillé. Je voulais donner quelque chose à plusieurs publics, car cela nécessite la collaboration de plusieurs publics (techniques et non techniques) pour réussir la gestion des API. En fin de compte, les lecteurs seront le juge, mais je pense que j’ai atteint mes objectifs avec ce livre.