Naviguer dans le paysage des passerelles API

API Gateway est un composant qui fournit un point d'entrée unique vers un ensemble d'API backend. Il est similaire au patron Facade du paradigme orienté objet, mais dans ce contexte, il s'agit d'un composant essentiel d'un système distribué. Parfois également appelé backend for frontend. Il joue le rôle de point d'entrée dans notre système pour les clients API externes.

Les API Gateways peuvent être perçues comme des reverse proxies sous stéroïdes, offrant plus de flexibilité et de capacités d'automatisation qu'un simple reverse proxy. Les plus populaires sont construits sur Envoy, HAProxy et NGINX.

Dans cet article, j'examinerai les API Gateways dans le contexte des architectures modernes, fortement intégrées à d'autres services cloud ou fonctionnant nativement au sein de l'espace Kubernetes, de plus en plus populaire.

Capacités clés que nous devrions attendre :

• routage du trafic réseau,
• limitation de débit,
• mise en cache,
• observabilité,
• autorisation et authentification,
• enrichissement de la charge utile,
• Terminaison SSL,
• disjonction de circuit,
• répartition de charge,
• gestion de l'accès payant à l'API.

Flux de trafic réseau typique avec API Gateway déployé

Approche Backend for Frontend

De nombreux articles sur internet utilisent de manière interchangeable les termes API Gateway et backend for frontend, ce qui indique que vous pouvez implémenter ces règles métier, des mappages de charge utile supplémentaires, et correctifs. À mon avis, vous devriez minimiser la quantité de logique personnalisée pour atteindre une haute résilience et maintenabilité de ces composants.

Utilisation de plusieurs passerelles API

Le plus souvent, vous souhaiterez combiner les capacités offertes par le Cloud (telles que le pare-feu et le routage mondial du trafic) avec votre infrastructure interne.

Implémentations populaires à exécuter dans Kubernetes :

• Ambassadeur,
• Kong,
• Traefik,
• Spring Cloud Gateway.

Les fournisseurs de cloud populaires incluent :

• Apigee,
• Azure API Management,
• Amazon API Gateway.

Certaines des entreprises qui développaient des ESB se sont également lancées dans marché des API Gateways. Un exemple d'ESB, qui fournit des fonctionnalités d'API Gateway est MuleSoft ESB.

Attention aux ESB qui se font passer pour des API Gateways

Plutôt que de m'étendre moi-même, examinons les recommandations d'experts du secteur :

L'inconvénient le plus important est que lorsque vous implémentez une API Gateway, vous couplez ce niveau avec les microservices internes. Un tel couplage peut introduire de sérieuses difficultés pour votre application.

Clemens Vaster, Architecte chez Azure Service Bus équipe

Les ESB déguisés en API Gateway : Halte ! Nous avons longtemps mis en garde contre les bus de services d'entreprise centralisés et défini les « endpoints intelligents, tuyaux simples » comme l'une des caractéristiques fondamentales d'une architecture de microservices. Malheureusement, nous observons un schéma de rebranding des ESB traditionnels, créant des ESB déguisés en API gateway qui encouragent naturellement des API gateways trop ambitieuses. Ne vous laissez pas tromper par le marketing : quel que soit le nom que vous lui donnez, placer la logique métier (y compris l'orchestration et la transformation) dans un outil centralisé crée un couplage architectural, diminue la transparence et augmente la dépendance vis-à-vis des fournisseurs sans avantage clair. Les API gateways peuvent toujours servir d'abstraction utile pour les préoccupations transversales, mais nous estimons que l'intelligence doit résider dans les API elles-mêmes.

Thoughtworks, Technology Radar Volume 234

Identifier le style d'architecture que vous souhaitez mettre en œuvre

Lors du choix d'une API Gateway pour votre projet greenfield, tenez compte du style architectural que vous souhaitez adopter et choisissez ce qui vous convient le mieux. Bien que la chorégraphie soit souvent plus adaptée à la construction de systèmes distribués hautement évolutifs.

Exemple de configuration

Un exemple de configuration déclarative d'une règle de routage dans Open Source Ambassador/Emissary Gateway :

kind: Service apiVersion: v1 metadata: name: your-api labels: app: your-api service: your-api annotations: getambassador.io/config: | --- apiVersion: ambassador/v1 kind: Mapping name: your-api_mapping prefix: /your-api/ service: your-api:8080 timeout_ms: 15000 spec: type: ClusterIP selector: app: your-api ports: - name: http port: 8080

Cette configuration va simplement intercepter une requête portant le préfixe « your-api », le supprimer, puis transmettre la requête à votre service Kubernetes Your API.

Emissary a récemment été accepté comme l'un des Projets de la Cloud Native Computing Foundation. Il existe un grand nombre de projets Cloud Native intéressants soutenus par la CNCF, je recommande de suivre leur site web : https://www.cncf.io/

Quelques conseils pour une mise en œuvre réussie

Examinons quelques points sur la manière d'utiliser les API Gateways en tenant compte de la résilience et de la maintenabilité :

• Un tel composant constitue généralement un point de défaillance unique ; si vous introduisez de petits éléments de logique métier, vous risquez de casser toute votre plateforme, et pas seulement le service backend auquel le concerne le changement donné.
• Dans les grands écosystèmes où votre backend se compose de dizaines ou de centaines de microservices, les équipes qui apportent des modifications dans leur domaine ne devraient pas avoir la possibilité de casser les API d'autres équipes, ce qui peut être causé par l'introduction de logique personnalisée dans notre Gateway.
• Certaines API Gateways populaires nécessitent le déploiement de plusieurs composants ; tenez compte de l'impact sur votre SLA.
• Si votre Kubernetes Ingress Gateway nécessite une base de données pour fonctionner, vous devriez devenir un expert des charges de travail stateful au sein de espace Kubernetes.
• Vous pouvez valider les identifiants entrants au niveau de l'API Gateway, mais cela ne signifie pas que votre service backend ne doit pas également les vérifier ; appliquez toujours une politique de confiance minimale.
• Sélectionnez des solutions qui peuvent être gérées via une configuration déclarative.
• Chaque équipe peut gérer sa configuration sans le risque de rupture d'autres API.
• Tenez compte de la facilité de développement local ; si vous devez exécuter API Gateway pour tester localement votre microservice, considérez cela comme un échec.
• Réduire la surface de défaillance autant que possible.
• Suivez l'approche « smart endpoints, dumb pipes ».

Je recommande également vivement la conférence de l'équipe technique de Netflix disponible sur YouTube : Maîtriser le Chaos – Un guide Netflix des microservices.

FAQ