Un service interne doit récupérer des données utilisateur auprès d'un service de facturation — et chaque milliseconde compte. Router ce trafic interne via une passerelle d'accès (edge gateway) publique force votre requête à quitter le réseau privé, à traverser des pare-feu externes et à subir une surcharge de sérialisation inutile. Ce chemin peut facilement ajouter 30 millisecondes de latence à un simple appel de dépendance.
La communication interne de service à service nécessite une approche architecturale différente du routage périphérique (edge). À la périphérie, vous avez besoin de portails développeurs publics, d'une limitation de débit complexe pour les clients externes et d'une validation OAuth2 lourde. En interne, vous recherchez une faible latence, une découverte de services native et une friction opérationnelle minimale.
Le choix de l'API gateway idéal pour vos microservices internes dépend de la charge opérationnelle que votre équipe peut supporter face à vos exigences de performance pure.
Le défi du routage des microservices internes : auto-hébergé vs managé
Les architectes de plateforme font face à un choix fondamental lors de la conception du routage interne : déployer et gérer une passerelle auto-hébergée au plus près des services, ou déléguer l'infrastructure à un service cloud managé.
Les passerelles auto-hébergées s'exécutent au sein de votre réseau privé — souvent sous forme de sidecars ou de contrôleurs d'ingress dans un cluster Kubernetes. Ce modèle de déploiement maintient le trafic local, ce qui minimise la latence. Il vous offre également un contrôle total sur les règles de routage, la manipulation des en-têtes et l'intégration de la découverte de services avec des outils comme Consul ou Etcd. Cependant, votre équipe doit gérer les machines virtuelles sous-jacentes, les politiques de mise à l'échelle et les mises à jour.
Les passerelles cloud managées fonctionnent comme des services externes. Elles ne nécessitent presque aucune maintenance et s'adaptent automatiquement pour gérer les pics de trafic. Le compromis réside dans la latence et le coût. Chaque requête interne doit transiter par le point de terminaison de la passerelle du fournisseur cloud avant de revenir dans votre cloud privé virtuel (VPC). Ce saut réseau supplémentaire introduit une latence qui peut dégrader les performances des appels de microservices en chaîne.
Kong : haute performance et écosystème riche en plug-ins
Kong est une passerelle open-source construite sur le serveur web Nginx et la plateforme web OpenResty. En héritant de l'architecture événementielle de Nginx, Kong excelle dans le routage à haut débit et à faible latence.
[Requête interne] ---> [Kong Gateway (Nginx/OpenResty)] ---> [Microservice cible]
|
[Plug-ins Lua] (Auth, Rate Limiting, Logging)
Kong utilise Lua pour son extensibilité. Si vous devez modifier des en-têtes, injecter des jetons d'authentification ou journaliser des requêtes vers Prometheus, il vous suffit d'appliquer un plug-in. La version open-source, Kong Gateway OSS, comprend une large sélection de plug-ins communautaires. Pour les fonctionnalités d'entreprise avancées telles que le contrôle d'accès basé sur les rôles (RBAC) et le déploiement multi-zone, les équipes doivent passer à Kong Enterprise.
La gestion de Kong nécessite de gérer l'état de sa configuration. Vous pouvez exécuter Kong en mode base de données traditionnel, ce qui requiert une base PostgreSQL pour stocker les configurations de routage. Alternativement, vous pouvez utiliser le mode sans base de données (DB-less). Dans ce mode, vous écrivez les configurations dans un fichier YAML déclaratif et les appliquez directement dans la mémoire de la passerelle. Cette approche s'intègre parfaitement aux flux de travail GitOps et aux environnements Kubernetes, mais elle vous empêche d'utiliser certains plug-ins nécessitant un stockage dynamique en base de données.
Tyk : complet et nativement écrit en Go
Tyk est une API gateway open-source entièrement écrite en Go. Contrairement à Kong, qui s'appuie sur une architecture modulaire de plug-ins pour ses fonctionnalités de base, Tyk intègre directement la limitation de débit, l'analyse et la virtualisation des services dans son moteur central.
Puisque Tyk est écrit en Go, il séduit les équipes disposant déjà d'une expertise en Go. Les développeurs peuvent écrire des plug-ins personnalisés en Go, Python, JavaScript ou Lua en utilisant le coprocesseur de plug-ins basé sur gRPC de Tyk.
Tyk nécessite Redis pour fonctionner. Il utilise Redis pour le stockage des sessions, les compteurs de limitation de débit et la mise en cache. Bien que cette dépendance ajoute un composant opérationnel à gérer, Redis permet à Tyk de traiter de gros volumes de trafic avec une latence faible et prévisible. La version open-source de Tyk est très complète, offrant le même moteur de passerelle que l'édition entreprise payante, bien que cette dernière ajoute un plan de contrôle de gestion et un tableau de bord.
Options cloud-native : AWS API Gateway et services managés
Si votre infrastructure fonctionne entièrement dans un cloud public, les options managées comme AWS API Gateway, Azure API Management ou Google Cloud Apigee sont très accessibles.
AWS API Gateway s'intègre directement aux autres services AWS. Vous pouvez router un appel API entrant directement vers une fonction AWS Lambda, une file d'attente SQS ou un Application Load Balancer (ALB) interne sans écrire de code d'intégration personnalisé. La sécurité est gérée via les politiques AWS Identity and Access Management (IAM), ce qui simplifie le contrôle d'accès.
Cependant, les passerelles managées dans le cloud imposent des compromis en matière de performances :
- Démarrages à froid (cold starts) : Si vous intégrez des backends serverless, la requête initiale peut prendre plusieurs secondes à s'exécuter.
- Sauts réseau : Le trafic doit souvent sortir de votre sous-réseau privé pour atteindre le point de terminaison public de la passerelle avant d'être redirigé vers votre réseau privé.
- Dépendance vis-à-vis du fournisseur (vendor lock-in) : Les configurations sont liées aux API propriétaires et aux outils de déploiement du fournisseur cloud.
Pour les microservices internes à haut débit, ces facteurs peuvent rendre les options cloud-native moins adaptées que les alternatives auto-hébergées.
Cadre de décision : choisir selon la taille de l'équipe et le budget opérationnel
Pour choisir la bonne passerelle, évaluez la capacité de votre équipe à gérer l'infrastructure par rapport à vos exigences de performance.
Petites équipes de startup (1 à 10 développeurs)
Si vous avez une petite équipe, donnez la priorité à une faible charge opérationnelle. Utilisez la passerelle managée de votre fournisseur cloud (comme AWS API Gateway) pour lancer rapidement vos services. À cette échelle, la facilité de configuration et le modèle sans maintenance l'emportent sur les légères pénalités de latence.
Équipes plateforme de taille moyenne (10 à 50 développeurs)
À mesure que votre maillage de services (service mesh) grandit, les coûts des passerelles cloud augmentent de manière linéaire avec le volume de requêtes. À ce stade, l'auto-hébergement devient viable financièrement et opérationnellement.
Examinons une comparaison réaliste des coûts :
- Scénario managé (Exemple) : Une application de taille moyenne traite 100 000 000 de requêtes internes par jour. Avec un tarif indicatif de passerelle cloud de 3,50 $ par million de requêtes, le coût de routage s'élève à lui seul à 350 $ par jour — soit environ 10 500 $ par mois.
- Scénario auto-hébergé (Exemple) : La même équipe déploie Kong ou Tyk sur son cluster Kubernetes existant. Elle fait tourner trois petites instances de calcul pour la haute disponibilité, pour un coût total de 150 $ par mois en ressources de calcul.
L'option auto-hébergée permet de réaliser d'importantes économies budgétaires, mais elle exige que l'équipe plateforme consacre quelques heures chaque mois à la gestion des mises à jour, à la surveillance de Redis ou PostgreSQL et à la configuration des pipelines de déploiement.
Équipes plateforme d'entreprise (plus de 50 développeurs)
Pour les grandes organisations soumises à des exigences strictes de conformité et de latence inférieure à la milliseconde, les passerelles auto-hébergées sont presque toujours indispensables. Ces équipes déploient généralement Kong ou Tyk dans une configuration hybride ou multi-région afin de maintenir le trafic entièrement au sein des centres de données locaux ou des VPC.
| Critères de sélection | Kong | Tyk | AWS API Gateway |
|---|---|---|---|
| Langage principal | Lua / C | Go | Propriétaire |
| Dépendance base de données | PostgreSQL ou DB-less | Redis | Aucune (Managé) |
| Extensibilité | Plug-ins Lua | Go, Python, gRPC | Intégrations AWS |
| Profil de latence | Inférieure à la milliseconde | Faible (de l'ordre de la microseconde) | Modérée (sauts réseau) |
| Idéal pour | Environnements Nginx haute performance | Équipes axées sur Go recherchant des fonctionnalités prêtes à l'emploi | Architectures serverless et 100 % AWS |
Évaluez vos options d'infrastructure API sur StackMatch
Choisir la bonne API gateway est une décision d'architecture critique qui influe sur la latence, le coût et la complexité opérationnelle de votre système. Vous pouvez explorer d'autres options et comparer ces outils en détail sur StackMatch. StackMatch propose des sélections d'outils, des pages de comparaison côte à côte et des évaluations éditoriales basées sur la facilité d'utilisation, la transparence des prix et les intégrations pour aider les ingénieurs plateforme à trouver la solution idéale pour leur stack technique.
FAQ
Kong est-il plus rapide qu'AWS API Gateway pour le routage interne ?
Oui, Kong offre généralement une latence nettement inférieure à celle d'AWS API Gateway. Comme Kong fonctionne sur Nginx et peut être déployé au sein de votre VPC privé au plus près de vos microservices, il évite les sauts réseau et les démarrages à froid associés au service entièrement managé d'AWS.
Puis-je exécuter Tyk sans base de données ?
Tyk nécessite Redis pour la mise en cache, la limitation de débit et le stockage des sessions. Bien que vous ne puissiez pas l'exécuter de manière totalement sans état (stateless) sans Redis, cette architecture permet à Tyk de gérer un trafic à haut débit avec une latence minimale par rapport aux passerelles reposant sur des bases de données relationnelles.
Quand une équipe doit-elle passer d'une passerelle cloud-native à une passerelle auto-hébergée ?
Les équipes effectuent généralement cette transition lorsque les factures de la passerelle cloud-native augmentent de manière linéaire avec le volume d'appels API, ou lorsque la latence ajoutée par le routage WAN affecte les performances des microservices internes. Si vos services internes exigent des temps de réponse inférieurs à 10 ms, l'auto-hébergement de Kong ou Tyk sur Kubernetes est généralement indispensable.
Comment Kong et Tyk gèrent-ils gRPC et GraphQL ?
Les deux passerelles prennent en charge le routage gRPC et GraphQL, mais de manière différente. Kong utilise des plug-ins pour le transcodage gRPC et la validation de schéma GraphQL, tandis que Tyk propose des fonctionnalités de moteur GraphQL natives pour fusionner plusieurs schémas en un seul graphe dès le départ.