APIs et Architecture Événementielle : Le Duo Gagnant

Introduction

À l’ère où les systèmes d’information doivent être performants dans la réception et le traitement des données, plusieurs approches sont développées pour répondre à ce besoin croissant de performance. Les avancées en matière de données, avec les technologies d’intelligence artificielle (IA) et d’apprentissage automatique, ont poussé les limites de nos architectures et de nos méthodologies.

Aujourd’hui, plus de 87 % du trafic Internet est axé sur les API (Interfaces de Programmation d’Applications) liées aux données. Les APIs jouent un rôle central dans cette transformation, mais elles présentent également certaines limites, notamment en ce qui concerne la communication asynchrone ou non bloquante.

Quelques rappels & Définitions

Un bref rappel sur les APIs : une API est une interface de programmation informatique permettant à des applications ou à des systèmes informatiques d’échanger des données. Parmi les types d’API, on trouve REST (Representational State Transfer), SOAP (Simple Object Access Protocol), gRPC, GraphQL, et bien d’autres. Actuellement, REST, basé sur le protocole HTTP, est le type d’API le plus couramment utilisé pour sa simplicité et sa compatibilité.

Les communications sont traditionnellement basées sur le modèle client-serveur, où le client émet une requête et attend que le serveur fournisse une réponse avant de poursuivre ses traitements. Cette approche présente des limites pour certains besoins, notamment la synchronisation de données dans une architecture orientée microservices.

C’est quoi l’Event Driven Architecture

C’est dans ce contexte que l’architecture orientée événements (Event-Driven Architecture, EDA) entre en jeu. L’EDA repose sur le principe de la diffusion d’événements et de la réaction des systèmes à ces événements. Il est important de noter que l’EDA n’est pas un type d’API, car elle sert à diffuser des événements et à permettre aux systèmes de réagir à ces derniers.

Un événement est défini comme tout changement d’état dans un système. Par exemple, la création d’un utilisateur constitue un événement (l’émetteur) qui déclenche un processus métier. D’autres systèmes peuvent souhaiter réagir à cet événement (les consommateurs). Dans une approche orientée événements, il incombe au serveur d’informer les clients qu’un événement a eu lieu, plutôt que de laisser les clients interroger le serveur pour savoir si un changement a été effectué.

L’architecture orientée événements repose sur trois acteurs principaux :

  • L’émetteur d’événements (Producer) : Il génère des événements en réponse à des actions ou des changements d’état. Ces événements sont ensuite diffusés à des consommateurs potentiels.
  • Le consommateur d’événements (Consumer) : Il écoute et réagit aux événements qui l’intéressent. Les consommateurs peuvent être des applications, des services ou des systèmes autonomes.
  • Le gestionnaire d’événements (Broker) : Il joue un rôle de médiateur entre les producteurs et les consommateurs. Il s’assure que les événements sont correctement acheminés aux consommateurs appropriés.

L’architecture orientée événements offre plusieurs avantages, notamment une meilleure réactivité, une évolutivité accrue, un découplage des composants et une gestion simplifiée des erreurs. Elle est particulièrement adaptée aux cas d’utilisation nécessitant une communication asynchrone et la diffusion en temps réel d’informations.

Plusieurs technologies existent pour mettre en place l’architecture Event Driven au sein d’un , les plus populaires sont RabbitMQ , ActieMQ , Kafka , Solace ,etc…

Apport de l’Event Driven Architecture

L’architecture orientée événements (Event-Driven Architecture, EDA) se révèle cruciale pour résoudre des problèmes de performance dans les systèmes informatiques. En effet, la performance d’un système peut être grandement impactée lorsqu’il doit réagir à des événements tels que l’ajout d’un utilisateur en attendant une action explicite du client. Cependant, l’EDA permet au système de réagir instantanément à ces événements ou d’informer d’autres serveurs nécessitant cette information. Un élément clé de l’EDA est la communication asynchrone, où chaque composant est libre de traiter un événement comme il le souhaite, sans attendre de manière synchrone, ce qui améliore considérablement la réactivité.

Il est essentiel de noter que l’Event-Driven Architecture n’est pas en soi un type d’API, mais elle peut parfaitement s’harmoniser avec les API pour renforcer les systèmes d’information. Comment l’EDA et les API peuvent-elles collaborer pour améliorer un système SI ?

Implication de APIs dans Event Driven Architecture

Déclenchement d’événements via les API : Les API peuvent être utilisées pour initier des événements. Par exemple, un composant peut exposer une API pour créer une ressource, et lorsqu’une nouvelle ressource est créée, un événement est automatiquement déclenché pour informer d’autres composants. Cette méthode garantit la systématisation des événements et permet une réaction cohérente du système.

Abonnement aux événements via les API : Les API peuvent également être utilisées pour décrire comment d’autres composants peuvent s’abonner à des événements spécifiques. Par exemple, un composant peut fournir une API permettant aux autres composants de s’abonner à des notifications en cas de modification d’une ressource particulière. Cette approche simplifie la création de flux d’informations réactifs au sein du système.

Définition du traitement des événements via les API : Les API peuvent servir à spécifier comment les composants réagissent après avoir émis ou reçu un événement. Par exemple, une API peut déterminer comment une autre application doit réagir à un événement donné en effectuant une action précise. Cela facilite l’orchestration des actions entre différents composants du système. En combinant l’EDA avec les API, les systèmes informatiques deviennent plus agiles, réactifs, robustes, évolutifs et résilients. Cette combinaison améliore la gestion des événements, la réduction des goulots d’étranglement potentiels et l’optimisation des performances, ce qui est essentiel dans un environnement numérique en constante évolution.

Conclusion

Dans les configurations globales de nos SI , plusieurs technologies concepts se heurtent pour pouvoir pallier aux problématiques de scalabilité et de fiabilité de données .
Les APIs sont une part très importantes des infrastructures informatiques ,cependant elles sont souvent couplées à d’autre concept tel que l’Event Driven Architecture qui offre une flexibilité avec les communications asynchrones .

Kong: la relève API management est assurée

Introduction

Pour la deuxième année consécutive et malgré son jeune âge, Kong est nommé leader et visionnaire par le Magic Quadrant du Gartner sur les API management.

Cette ascension fulgurante attise naturellement notre curiosité, je vous propose donc dans cet article de découvrir ensemble la solution d’API Management Kong.

Cet article s’adresse à un public familier avec les notions d’API et d’API Management.
Si ce n’est pas votre cas, je vous invite à explorer les liens ci-dessous :

     https://accetal.fr/glossaire-api-management/
     https://accetal.fr/introuduction-api-management/
     https://accetal.fr/webinar-quels-criteres-pour-bien-choisir-sa-solution-dapi-management/

Vous pouvez également si vous le souhaitez, suivre la formation complète sur les API :
     https://accetal.fr/formations/reussir-lapisation-de-son-si/

Kong, qu’est ce que c’est au juste ?

Kong, c’est d’abord Kong Gateway, une passerelle d’API Open Source et Cloud-native, qui adresse aussi bien des API, que des microservices.

Compatible avec différents systèmes d’exploitation, elle peut également être déployée via Docker ou Kubernetes.

Elle se dit légère, rapide mais aussi flexible notamment grâce à son système de plugins et de modules. Elle est ainsi proposée sous différents formats allant :

  • de la simple passerelle d’api pour le mode OPEN SOURCE,
  • à une solution complète d’API management pour le mode ENTERPRISE avec :
    • l’interface Kong Manager : un portail de gestion/publication Api
    • l’interface Kong Developer : un portail développeur
    • le module Kong Vitals : un outil de monitoring (logs, métriques, performance…)
    • le module Kong Immunity : un outil d’analyse de logs (maching learning, alertes…)
    • une gestion des contrôles d’accès de type RBAC (Role-based Access Contrôle)
    • ainsi qu’un ensemble de plugins.
Kong Modes
Credits image : Kong

En janvier 2021, Kong va encore plus loin et lance Kong Connect (Konnect), une plateforme d’administration en mode SaaS. Cette plateforme comporte un nouveau module « Runtime Manager » dont l’objet est la gestion de plusieurs nœuds Kong Gateway, tout en s’affranchissant de base de données.

Ci-dessous, la liste des modules Konnect en modes SaaS :

  • ServiceHub (équivalent de Kong Manager, pour gérer les services)
  • RuntimeManager (facilite le déploiement des runtimes de Kong Gateway)
  • Portal Developper
  • Vitals

La petite histoire : naissance de la bête

Tout commence par Mashape, une société née avec le succès montant des API dans les années 2010.

Mashape avait pour ambition de créer la première marketplace dédiée aux API, une sorte de Airbnb mais pour de la location d’API. Les fournisseurs y publiaient leurs API (description, spécification, tarification). Les développeurs accédaient alors à un catalogue d’API, qu’ils pouvaient directement tester, souscrire et surtout consommer via la plateforme Mashape.

C’est-à-dire que toutes les requêtes d’API devaient passer par une API gateway assez puissante et robuste pour gérer une telle volumétrie de transactions.

En 2015, Mashape donne un nom à cette Api Gateway et décide de la rendre open Source : c’est la naissance de Kong.

La version Enterprise fera son apparition en 2018 et en 2021 Kong donne naissance à un petit dernier très prometteur, Konnect. Celui-ci fournit le portail Konnect et la plupart de ses modules en mode SaaS, tandis que l’hébergement des runtimes restent à la charge des clients.

Avec ces nouveaux produits, Kong s’impose aux côtés d’autres géants de l’API management, et prend place dans la case Leaders du Gartner magic-quadrant-api-management de 2020 et 2021 : https://accetal.fr/magic-quadrant-api-management-2021/.

Kong dans le Gartner Magic Quadrant Api Management 2021
Gartner Magic Quadrant Api Management 2021

Dissection du gorille : qu’a-t-il dans le ventre ?

Dans le mode Enterprise, on retrouve bien tous les composants d’une plateforme de gestion d’API.

Une API gateway : « Kong Gateway »

Celle-ci se compose des éléments ci-dessous :

Kong Gateway
Kong Gateway

Un reverse proxy

Kong Gateway repose sur la plateforme web OpenResty, qui est une surcouche de Nginx combinée à un moteur LuaJIT.

  • Nginx est un serveur web et reverse proxy. Léger et rapide, il est réputé pour ses hautes performances.
  • Lua est un langage de script dont les threads peuvent se greffer à un programme existant afin d’en étendre les fonctionnalités. C’est sur ce mécanisme que repose le système de plugins de Kong Gateway.

Des plugins

Ce qu’on appelle plugins chez Kong, c’est l’équivalent des policies, c’est-à-dire des règles et actions qui sont appliquées aux requêtes et réponses qui transitent sur la Gateway (authentification, autorisations, quotas, cache…).

Kong propose aujourd’hui plus de 60 plugins, et il est possible de créer ses propres plugins en langage Lua, GO, JS et Python (liste des plugins : https://docs.konghq.com/hub/).

Une base de données

Pour la persistance des données (enregistrement des configurations des API, des déclarations d’applications …), Kong gateway donne le choix entre Cassandra et PostgreSQL, mais supporte également un mode DB-less.

Des outils d’administration

L’Api Gateway est fournie avec deux outils d’administration :

curl -X POST http://127.0.0.1:8001/services --data name=demo-api --data url=http://mockbin.org
curl -X POST http://127.0.0.1:8001/services/demo-api/routes --data paths[]=/demo-api
deck dump
deck sync

Un portail fournisseur : « Kong Manager » ou « Konnect » pour la version SaaS

« Kong manager » est une interface web d’administration de Kong Gateway. On y publie les API, gère leurs cycles de vie puis on les surveille grâce au module « Vitals ».

Il permet également de gérer et personnaliser le portail développeur.

Quant au module complémentaire de machine learning « Kong Immunity », il facilite la détection des comportements anormaux en analysant les logs en temps réels.

Portail Kong Manager
Portail Kong Manager
Portail Konnect
Portail Konnect

Un portail développeur : « Kong Developers » ou « Konnect Developers »

Le portail développeur est dédié aux consommateurs des API.

Il présente un catalogue d’API classées par catégories et est entièrement personnalisable pour correspondre à la chartre graphique d’une entreprise par exemple.

En quelques clics, les consommateurs d’API (les développeurs) sont capables de tester ces API, d’y souscrire, et de suivre leurs consommations directement depuis ce portail.

Portail Kong Developers
Portail Kong Developers
Portail Konnect Developers
Portail Konnect Developers

Place à la pratique : apprivoisons Konnect

Créer un compte

Pour commencer avec Konnect, il faut se créer un compte puis se connecter via le portail https://konnect.konghq.com/ :

Création d'un compte Konnect
Création d’un compte Konnect

Préparer une instance du runtime Kong Gateway

Une fois le compte créé, nous aurons besoins d’installer un runtime. Pour cela, cliquez sur le menu runtime sur le panneau gauche, puis sur le bouton « Configure Runtime ».

Ensuite, laissez-vous guider en suivant les instructions selon le mode de déploiement que vous souhaitez (container docker, Linux ou Kubernetes).

Le runtime configuré apparaitra sur le portail Konnect.

Runtime Manager
Runtime Manager

Publier une API

Pour notre exemple, nous allons publier l’api Petstore mise à disposition par Smartbear, très souvent utilisée pour les démos et les exemples : https://petstore.swagger.io/.

  1. Sur le portail Konnect, nous allons déclarer ce service, pour cela cliquez sur le menu « Services » du panel gauche, puis sur le bouton « Add New Service », et renseignez le formulaire avant de le soumettre.
Création d'un service
Création d’un service
  1. Cliquez sur la version déclarée (1.0.5 dans cet exemple), puis cliquez sur « New Implementation ».
Sélection de la version d'un service
Sélection de la version d’un service
  1. Configurer l’upstream service (il s’agit du service backend) comme suit :
Configuration d'un upstream
Configuration d’un upstream
  1. Configurez ensuite la route en renseignant le nom le chemin (path) qui exposera le service via la gateway :
Configuration d'une route
Configuration d’une route
  1. Cliquez sur le bouton « Create » puis tester sur la machine dans laquelle est installée le runtime de notre test : la requête ci-dessous doit retourner un code statut http 200 OK.
curl http://127.0.0.1:8000/petstores/store/inventory

A ce stade, nous avons publié notre API (dans cet exemple l’api petstore) sur notre gateway.
Cette dernière redirige les appels commençant par « http://127.0.0.1:8000/petstores… » vers http://petstore.swagger.io/v2…
Ainsi, notre appel de test a été redirigé par notre gateway vers « http://petstore.swagger.io/v2/store/inventory« .

Ajouter un plugin

Kong est extensible grâce à des plugins qui peuvent être ajoutés à différents niveaux (service, global …). Nous allons ici ajouter un plugin au niveau de notre service, celui-ci sécurisera l’accès à notre API à l’aide d’une APIKey.

  1. Dans le menu « Services », sélectionnez l’API Petstore, sélectionnez la version « 1.0.5 » puis cliquez sur « New Plugin ».
Ajout d'un plugin
Ajout d’un plugin
  1. Activez le plugin « Key Authentication » (laisser les paramètres par défaut, puis cliquez sur « Create »).
Plugin Key Authentication
Plugin Key Authentication
  1. Testez de nouveau l’api :
curl http://127.0.0.1:8000/petstores/store/inventory

Cette fois-ci un code erreur 401 est retournée car aucune apikey n’a été fournie lors de l’appel. Ce contrôle est effectué par le plugin « Key Authentication » que nous avons activé pour le service.

Créer un consommateur pour interroger l’API

Désormais, notre API nécessite une clé de souscription pour être consommée. Nous allons donc devoir déclarer un consommateur et lui attribuer une clé.

  1. Dans le menu « Shared Config/Consumers », créez un consommateur en cliquant sur le bouton « New consumer ».
Création d'un consommateur
Création d’un consommateur
  1. Sélectionnez le consumer nouvellement créé, et générez une apikey dans l’onglet « Credentials » via le bouton « new Key Auth Credentials ».
Nouveau KeyAuth
Nouveau KeyAuthNouveau KeyAuth
  1. Enfin, cliquez sur « Create » sans rien renseigner pour générer une clé automatiquement.
Création KeyAuth
Création KeyAuth
  1. Copiez la clé et envoyez la dans la requête au niveau de l’entête « apikey ».
curl --header apikey: http://127.0.0.1:8000/petstores/store/inventory

L’api-key étant renseignée, vous devriez obtenir un code statut http 200 OK.

Pour aller plus loin

Maintenant que vous savez comment publier une API sur Kong Gateway via le portail Konnect et la sécuriser à l’aide d’ApiKey, vous pouvez aller plus loin en testant d’autres plugins et en manipulant les différents modules.

Vous trouverez toute la documentation Kong disponible à cette adresse : https://docs.konghq.com/.

Je vous recommande par ailleurs de vous inscrire à Kong Academy, une plateforme d’apprentissage générant des environnements Kong éphémères au début de chaque cours.

Enfin, pour les plus curieux d’entre vous, les sources de Kong Gateway OSS sont disponibles dans le repository : https://github.com/Mashape/kong.


Vous avez des questions ? Vous souhaitez être accompagnés ? Contactez-nous !


    Accetal utilise les informations que vous fournissez afin de vous proposer des informations et du contenu personnalisé sur nos produits et services. Vous pouvez vous désinscrire de nos communications à tout moment. Pour plus d'informations, consultez notre politique de confidentialité.