Kong vs WSO2 : comment choisir sa passerelle API

Kong vs WSO2 revient dans presque chaque cadrage où les deux noms sont cités ensemble. La question est mal posée si l’on attend un gagnant. Kong Gateway, dans son édition open source, est une passerelle : un proxy, des routes, des plugins, une configuration déclarative ou portée par une base. WSO2 API Manager 4.3 est une plateforme : Publisher, portail développeur, Key Manager, Traffic Manager et passerelle, selon sa documentation d’architecture. On choisit un périmètre, puis un produit. Les pages Kong et WSO2 API Manager détaillent chacun. Le comparatif les remet parmi d’autres offres.

La première question : que faut-il le jour de la mise en production

Si le besoin du premier incrément est de recevoir des appels HTTP, de vérifier une identité, d’appliquer une limite de débit et de transmettre à un service, une passerelle suffit. Kong est construit pour cela. La configuration peut vivre dans un dépôt, en mode déclaratif, ce qui se revue comme le reste du système. Sur Kubernetes, un contrôleur d’ingress publie les routes à partir des ressources du cluster.

Si le besoin du premier incrément comprend un portail où des équipes externes découvrent les API, s’abonnent et obtiennent des clés, ainsi qu’un cycle de vie avec versions et dépréciation, la plateforme WSO2 contient ces pièces dans la distribution documentée. Les ajouter à Kong open source signifie les construire, ou passer à une édition et à un plan de contrôle, notamment Konnect, qui les fournissent. Ce n’est pas le même projet que l’installation de la passerelle.

Qui exploite quoi

Les deux produits, dans leur forme installée, laissent le runtime à l’équipe. Il faut superviser les processus, les certificats et les montées de version. WSO2 ajoute les bases du plan de gestion, le Key Manager et le Traffic Manager. Kong en mode avec base ajoute PostgreSQL. Kong en mode déclaratif retire cette base du chemin de la configuration, et déplace la contrainte vers le déploiement du fichier : un mauvais apply retire des routes.

Kong Konnect déplace le plan de contrôle chez l’éditeur. WSO2 reste, dans le produit API Manager décrit ici, une plateforme que l’on exploite. L’offre cloud de l’éditeur WSO2 est un autre produit, à ne pas confondre avec l’installation dont parle cet article. Le critère est simple : qui est d’astreinte lorsque la passerelle ne répond plus, et qui est d’astreinte lorsque la console de publication ne répond plus. Si ces deux réponses doivent être la même équipe, les deux produits installés conviennent. Si la console doit être opérée par le fournisseur, il faut regarder l’offre correspondante, pas l’édition installée.

Identité et quotas

WSO2 documente un Key Manager, qui peut être celui du produit ou un gestionnaire tiers, et un Traffic Manager pour les quotas. Les applications s’abonnent et reçoivent des identifiants liés à ce modèle. Kong vérifie l’identité par des plugins, et limite le débit par d’autres plugins. Le fournisseur d’identité, dans les deux cas, peut rester celui déjà utilisé par les applications. La passerelle valide. Elle ne devient pas l’annuaire de l’entreprise.

La différence apparaît au moment où plusieurs équipes consomment les mêmes API avec des contrats différents. WSO2 exprime cela par des applications et des abonnements. Kong l’exprime par des consommateurs et des plugins attachés à des routes. Les deux modèles fonctionnent. Changer de modèle plus tard, c’est réémettre des secrets et réécrire les contrôles. Le choix se fait avant la première application externe.

Kubernetes

WSO2 documente un déploiement par ressources Kubernetes ou OpenShift. L’architecture de référence consiste à séparer la passerelle, le plan de gestion et les bases. L’article WSO2 API Manager sur Kubernetes développe ce découpage. Kong s’utilise comme proxy et comme contrôleur d’ingress. Les routes suivent alors le cycle de vie des manifestes du service.

Une équipe qui publie déjà tout par des ressources Kubernetes et qui n’a pas besoin d’un portail trouvera le modèle Kong plus proche de ses habitudes. Une équipe qui veut que la publication d’une API soit un acte dans un Publisher, distinct du déploiement du service backend, trouvera ce geste dans WSO2. Imposer un Publisher à une équipe qui livre par Git, ou imposer des manifestes à une équipe qui ne travaille que dans une console, crée un contournement. Le contournement devient le vrai processus, non relu.

Étendue des API

WSO2 API Manager 4.3 documente REST, GraphQL, l’exposition de SOAP en REST, WebSocket, WebSub / WebHook, SSE et AsyncAPI. Kong documente une passerelle HTTP et, selon les versions, d’autres protocoles dont gRPC, avec des plugins. Si le parc est un ensemble de services HTTP contemporains, les deux couvrent le besoin. Si le parc comprend des services SOAP à exposer en REST et des abonnements asynchrones déjà décrits dans la documentation WSO2, cette couverture est un critère factuel, à vérifier dans la version que l’on installera, pas un argument général.

Ce qu’il ne faut pas utiliser comme critère

Le nombre de plugins annoncés ne dit pas lesquels sont dans l’édition retenue, ni lesquels seront maintenus. Un essai de charge sur un exemple vide ne dit rien du coût d’une politique de transformation ou d’un journal trop bavard. Un tableau de prix trouvé dans un article tiers vieillit vite. L’open source ne signifie pas l’absence de coût d’exploitation. Le service managé ne signifie pas l’absence de responsabilité sur les contrats d’API.

Il est également peu utile de trancher sur la notoriété. Les deux produits sont documentés, utilisés, et limités par ce que leur édition contient.

Une façon de conclure un cadrage

On écrit quatre réponses. Faut-il un portail et des abonnements au premier incrément. Qui exploite le runtime et la console. Où le trafic doit-il rester. Quel est le style des API réellement en jeu. Si le portail est requis et que l’équipe exploite la plateforme, WSO2 API Manager est le candidat cohérent. Si la passerelle et une configuration déclarative suffisent, Kong est le candidat cohérent. Si les réponses se contredisent, par exemple un portail requis et personne pour exploiter une plateforme, le cadrage n’est pas fini : il manque soit une édition opérée, soit un renoncement au portail pour plus tard.

D’autres produits répondent à d’autres contraintes. Gravitee est une plateforme installée, voisine de WSO2 sur le périmètre portail et passerelle. Apigee, Azure API Management et AWS API Gateway déplacent le plan de contrôle chez un fournisseur cloud. Les écarter sans regarder l’hébergement déjà choisi serait incomplet. Les retenir sans regarder où le trafic doit rester le serait aussi.

Ce que Technocify peut prendre en charge

L’audit pose les quatre questions ci-dessus sur le parc réel. La conception retient une édition et un mode, déclaratif ou avec base pour Kong, runtime resserré ou distribué pour WSO2. La mise en œuvre livre un parcours : une API, une identité, une limite, un journal. Le run suit les mises à jour et les changements de routes ou de révisions.

Les équipes Technocify s’appuient sur une pratique de l’intégration et des API depuis 2009. Nos consultants sont certifiés WSO2 API Manager Practitioner V4 (2023), WSO2 API Manager Developer V3 (2021), MuleSoft Developer V4 (2022), Workato Automation Pro I, II, III (2025, valides jusqu’en 2027) et ITIL V4 (2020). Le détail est sur À propos. Voir aussi plateformes API et cloud et interopérabilité.