Kong, le gorille de l'API Management vu de près
Les entreprises proposant un service au travers d'une API et qui voient le nombre de consommateurs et de partenaires augmenter, sont confrontées à de nombreux challenges :
- Comment réduire le temps d'enrôlement des nouveaux consommateurs et partenaires ?
- Comment identifier les partenaires et gérer leurs consommations des APIs ?
- Comment mesurer la consommation du point de vue producteur et consommateur ?
- Comment gérer le cycle de vie de l'API ?
Il s'agit alors, d'adresser ces problématiques de manière uniforme pour l’ensemble des APIs par l'intermédiaire d'un outil central.
Qu’est ce que l’API Management ?
Cet outil est communément appelé "une solution d'API Management" et se doit de remplir les fonctions suivantes :
Sur ce schéma, nous distinguons quatre briques :
API Gateway : Point d'entrée de toutes les requêtes à destination des APIs Redirige le flux vers l'API cible et permet de gérer des aspects tels que la gestion des quotas, le logging mais aussi la sécurité par l’intermédiaire de l’Authentification, l’Authorization (OAuth2, ACL), et l’Accounting.
Plate-forme Analytique : Permet de mesurer et de représenter graphiquement la consommation d'API.Ce module est à destination à la fois de l'entreprise mais aussi des partenaires.
Portail développeur : Outil permettant d'exposer la documentation relatifs aux APIs, d'automatiser l'enrôlement des nouveaux partenaires et de donner accès à un environnement sandbox pour tester l'API.
API Facade : Fonctionnalité optionnelle, qui abstraint la complexité d'un SI en proposant de la transformation SOAP vers REST ou l’orchestration des requêtes par exemple.
Un marché en plein essor
De nombreux produits propriétaires et open-source ont émané de ce besoin avec pour chacun d’eux, leur lot de fonctionnalités et leur communauté.
Dans cet article, nous allons nous intéresser à une solution dénommée Kong (Version 0.8.3), une solution à la fois propriétaire et open-source.
Cet outil se démarque du lot par son système original de plugins qui permettent assez facilement d’obtenir une solution personnalisable.
La genèse de Kong
Mashape est une entreprise qui propose une plate-forme endossant le rôle de point d'entrée unique vers une multitude d'APIs, afin de simplifier leurs consommations et encourager la création d'applications combinant différentes APIs.
Au tout début de son aventure, seulement 3 APIs étaient exposées et gérées par Kong, puis le nombre de fournisseurs d’API a augmenté au rythme que les requêtes affluaient.
Tout cela impliquait une gestion précise des APIs ainsi que leurs consommateurs.
En effet, il était critique pour l’organisation de pouvoir gérer chacune de ses APIs de manière transparente et unifiée par l’intermédiaire d’un seul outil : une API Gateway.
Kong est né de cette problématique, en adressant tous les problèmes liés à la gestion des APIs de façon simple et efficace.
Aujourd’hui, la plate-forme rencontre un franc succès et, par l’intermédiaire de son catalogue d’environ 15.000 APIs, elle fait face à quelques milliards d’appels par mois, appels effectués par près de 200.000 utilisateurs.
Nous pouvons notamment citer Spotify ou encore Amazon, qui consomment par l’intermédiaire de Mashape, les APIs disponibles sur le market-place.
Kong est désormais open-source sous licence Apache 2 .0 depuis Avril 2015.
Kong-cretement ?
Une API Gateway misant sur la simplicité
Kong est une API Gateway, se situant à mi-chemin entre les applications dites clientes et vos APIs.
Les requêtes HTTP vont tout d’abord communiquer avec Kong qui va ensuite se charger de rediriger correctement le flux vers le fournisseur d’API.
L’outil se base sur un système de plugins qui permet d'agrémenter la solution de base, avec de nouvelles fonctionnalités.
Nous pouvons donc rendre Kong plus robuste et plus en adéquation avec nos besoins.
Une solution d’API Management personnalisable : Kong Gelato Galileo (KGG)
En parallèle de Kong, Mashape a développé deux outils externes qui, eux ne sont pas open sources.
Il s’agit d’un portail développeur : Gelato, et d’une solution d’analytiques : Galileo.
Ces deux solutions peuvent êtres utilisées indépendamment de Kong, mais leur intérêt majeur est de pouvoir s’interfacer avec ce dernier et de fournir, une fois assemblées, une solution d’API Management complète.
En effet, Gelato et Galileo s'intègrent dans Kong via le système de plugins.
Gelato, un portail développeur mâture
Gelato est un portail développeur complet qui se scinde en deux parties : la partie administrateur et la partie développeur.
Du côté administration, nous retrouvons l’import de définitions d’APIs par l’intermédiaire des formats Swagger, Blueprint et RAML qui sont supportés, la gestion des utilisateurs ainsi que du reporting en ce qui concerne la consommation des APIs exposées.
Nous pouvons personnaliser le portail en ayant accès au code HTML et le CSS dans la version entreprise de l’outil.
Enfin, d’un point de vue développeur, nous pouvons avoir accès à la documentation des APIs ainsi qu’à une interface permettant d'interagir avec elles.
En se basant sur la documentation d’une API, l’outil est capable de fournir le code nécessaire à l’implémentation côté client, de la connexion à l’API.
Ce dernier est assez limité et nécessite des développements spécifiques de notre part pour l’adapter.
Analysez facilement vos données avec Galileo
Galileo est une solution d’analytiques (reporting) s’interfaçant avec Kong afin d’afficher toutes les actions réalisées sur les APIs.
L’outil propose une interface graphique avancée permettant de filtrer et d’analyser les appels et plus généralement, la consommation des APIs.
Son fonctionnement est simple : Kong génère des rapports d’événements sous format Api Log Format (ALF) qui est une extension de HTTP Archive, un format permettant de collecter et de mettre en forme des données pour ensuite les traiter facilement.
Dans notre cas, Galileo réceptionne les fichiers ALF via un collecteur et les exploite.
En tant qu’API Manager, il est possible de construire un tableau de bord en choisissant les indicateurs à afficher, les périodes à analyser etc.
Cela peut permettre de répondre à des questions simples : Quelle API est la plus consommée ? Ou encore à des questions plus pointues : Quel est le temps moyen de réponse de mon API sur cette ressource ou endpoint ?
En somme, l’outil apporte une vision à 360 degrés sur les APIs exposées.
Il est en effet possible, par l’intermédiaire de filtres, de construire des rapports précis, répondant à des problématiques IT ou business.
De base, uniquement les données contenues dans le header et les paramètres des requêtes (query string) sont enregistrées et utilisables pour une analyse détaillée via Galileo.
Il est possible de sauvegarder les données présentes dans le body de la requête.
Cependant, il faut être conscient de l’éventuel impact de cette opération, car mettre en mémoire tampon (buffer) ces données peut avoir pour conséquences de ralentir la machine virtuelle LuaJIT en saturant la mémoire.
Il faut donc penser à configurer la taille de la file d’attente (queue_size) du plugin Galileo afin que Kong envoi fréquemment les données pour éviter un éventuel goulot d’étranglement.
Une des fonctionnalités importantes d’une solution d’API Management est la partie facturation.
Il s’agit de mettre en place un système veillant à gérer toute la politique économique des APIs, or avec Kong, cela n’est pas encore possible.
Anatomie de Kong
Kong mise sur un principe simple : la developer experience (DX).
C'est à dire que le processus d’installation est simple et la solution peut fonctionner au bout de 5 minutes, sans avoir à consulter des forums à cause d’erreurs obscures.
Kong repose sur le pattern API First, l’outil est donc administrable via des commandes cURL et ne possède pas d’interface graphique native.
Cette approche API First consiste tout d’abord à se focaliser sur l’exposition de nouvelles fonctionnalités via une API, et par la suite, de définir les plates-formes sur lesquelles elles seront disponibles.
La communauté est assez active, et propose souvent des solutions tierces telle que Kong Dashboard UI qui est une interface d’administration.
Afin de démarrer Kong, une seule commande suffit : $ kong start.
Le processus tourne alors en tache de fond sur 127.0.0.1 et est à l’écoute par défaut sur trois ports (8000, 8443 et 8001).
Pour un usage en production, ceux-ci peuvent être modifiés dans le fichier de configuration kong.yml afin de répondre à des enjeux de sécurité.
Kong se dit nativement platform agnostic, ce qui rend son déploiement peu contraignant. Cette indifférence à la plate-forme exclue cependant Windows**.**
D’autres types de déploiements sont possibles, comme par exemple en utilisant des systèmes de virtualisation ou containerisation.
Serveur HTTP et Reverse-Proxy
Nginx est un serveur HTTP et un reverse-proxy à partir duquel Kong tire toute son efficacité et sa configuration.
En effet, Kong se base sur une sur-couche de Nginx : OpenResty**,** qui embarque toutes les fonctionnalités de Nginx, avec en prime, le compilateur LuaJIT et des librairies écrites en Lua permettant la configuration du serveur.
Grâce à tout cela, Kong se veut modulable, performant et stable.
Stockage des données
Afin de garantir la persistance des données, Kong nous offre le choix d’utiliser soit Cassandra 2.X.X ou PostgreSQL 9.4+.
Dans le cadre d’un système plus classique, PostgreSQL 9.4+ est une valeur sûre.
L’utilisation d’une base de données externe est justifiée par la forte volumétrie des données transitant entre les différents composants. Il s’agit alors de stocker l’ensemble des APIs exposées dans la gateway ainsi que les plugins et les utilisateurs.
L’évolutivité ou scalabilité d’une telle plate-forme est un point crucial.
Pour ce faire, il faut revenir sur une des caractéristiques majeures du serveur HTTP sur lequel Kong est bâtit. Ce serveur est stateless, ce qui signifie qu’aucune information n’est stockée de façon pérenne et qu’une instance de Kong (nœud) peut être supprimée, ajoutée sans que cela ait de conséquences sur le fonctionnement général de la gateway.
Le système de Plugins
Comme évoqué précédemment, Kong se base sur un système de plugins qui est la fonctionnalité phare de la solution.
En effet, toutes les fonctionnalités proposées par Kong sont en réalité des plugins, que l’on peut choisir d’ajouter ou non à la gateway existante.
Ces plugins sont simplement des programmes écrits en Lua qui, lors de l’envoi d’une requête de configuration sur le port 8001, seront exécutés et automatiquement liés à l’instance Kong.
Cela permet de construire une solution sur mesure en fonction de nos besoins, et c’est une possibilité appréciable.
Exemple d’ajout de l’authentification par clé (key-auth) sur l’API “nooi-store”
L’API proposée par Kong est basée sur REST et est très bien documentée ce qui la rend developer friendly.
De plus, en plaçant la communauté au coeur du produit, Mashape nous laisse l’opportunité de développer nous même des plugins.
Il est donc possible pour une entreprise ayant un besoin précis se traduisant sous la forme d’un plugin, de le développer en interne, et de ne pas l’exposer à la communauté.
Nous pouvons aussi faire une pull-request sur le Github de Kong, en exposant l’idée générale du plugin ainsi que le code source afin qu’il soit validé ou non par les développeurs et par la suite, distribué à la communauté.
A l’heure actuelle, il existe cependant très peu de plugins développés par la communauté.
Différents modes de déploiement
A partir de cette section, nous ferons référence aux 3 éléments composant la brique API Management (Kong, Gelato, Galileo) sous l'acronyme KGG.
La solution d’API Management KGG se décline en trois modes de déploiement.
On-premise
Nous retrouvons tout naturellement le mode On-premise qui inclut gratuitement et uniquement Kong dans sa version communautaire.
Galileo et Gelato étant hébergés en SaaS, et nous ne pouvons malheureusement pas les intégrer localement.
A partir de là, deux solutions s’offrent à nous pour pallier à ce manque :
- Nous pouvons expliciter notre besoin sur le site de Mashape afin que leurs équipes construisent pour nous la solution KGG afin qu’il soit possible de l’utiliser localement. Cette demande se fait par le biais d’un formulaire en ligne à remplir en indiquant le contexte et l’ensemble des informations de notre entreprise. C’est une démarche un peu contraignante car nous ne sommes pas “maîtres” de l’assemblage et de l’évolution des composants.
- D’un autre côté, Kong met à disposition des fichiers de logs (ALF) qui peuvent être utilisés afin de développer par exemple, une solution d’analytiques locale qui exploitera les données et les mettra en forme, tout en communiquant avec la gateway.
Cette solution s’adresse donc à des utilisateurs ayant une appétence pour le développement informatique.
Une des solutions envisageable est d’utiliser la suite ELK pour développer un tableau de bord sur-mesure.
Hybride
Avec sa solution hybride, Kong propose d’héberger la gateway localement, et de fournir en SaaS, le portail développeur et le module analytique.
Nous regretterons le manque d’informations sur la localisation géographique des serveurs hébergeant les données.
Cela peut représenter un frein à l’intégration dans un SI, en se heurtant à la politique de sécurité de l’entreprise.
En effet, le seul élément que l’on maîtrise est la configuration de la gateway, le reste s’interfaçant de façon transparente via le système de plugins.
Cloud
Dernier mode de déploiement, le modèle cloud est naturellement basé sur le SaaS.
Mashape gère toute l'infrastructure pour vous et fourni une solution clé en main.
Une solution semi-open-source ?
Kong est open-source sous licence Apache 2.0 et via son système de plugins gratuit, propose un large panel de fonctionnalités.
Cependant, pour obtenir une solution d’API Management basée entièrement sur KGG, il faut avoir recours à l’utilisation de Gelato et de Galileo qui sont des modules SaaS payants.
Leurs tarifs sont abordables : comptez unitairement entre 750$ et 800$ par an pour Galileo et Gelato, cela permet de maîtriser raisonnablement les coûts de déploiement.
Nous apprécions la possibilité de pouvoir développer nous même des plugins bien que la courbe d’apprentissage soit relativement importante au vu de la complexité de la pile technologique.
Le support communautaire est complet (Gitter et Github) malgré la difficulté à obtenir des réponses concrètes et rapides.
Enfin, le public cible se doit d’avoir un minimum de connaissances techniques et d’être familier avec la ligne de commande.
Pour une solution personnalisée, il faut en effet configurer l’ensemble de la gateway par l’intermédiaire de commandes cURL et ne pas avoir peur de se frotter à la pile technologique sur laquelle repose KGG, c’est à dire le langage Lua et OpenResty.
Kong utilise par la même occasion des bases de données NoSQL, des compétences internes sont donc nécessaires à la maintenance et au bon fonctionnement de ces dernières.
En conclusion
Kong reste une solution relativement jeune de part le fait qu’il n’y ait toujours pas de V1 au moment où cet article est publié.
Le manque de références clients de taille conséquente utilisant Kong en production accentue cet aspect.
Cependant, elle reste intéressante dans la mesure où l’ensemble des technologies utilisées sont récentes et reposent sur des bonnes pratiques telle que la developer experience ainsi que grâce à son approche par plugin, qui permet d’embarquer des fonctionnalités en fonction de nos besoins.
Enfin, Kong ne représente pas la solution miracle tant attendue.
L’intégration OAuth2 nécessite du développement en parallèle, afin d’être à 100% fonctionnelle.
En se basant sur les standards sur web tels que REST et le format de données JSON, l’entreprise utilisatrice de la solution se doit donc de fournir des APIs à l’état de l’art pour profiter de cette dernière.