La gateway unique est un faux ami

La décision se prend en général sans être prise. On monte une gateway pour un premier besoin, souvent un flux partenaire, parce que c'est celui qui a un budget, et comme elle est là, on y fait passer le reste.

Dix-huit mois plus tard, la plateforme est en place, elle fonctionne, et pourtant les équipes internes s'appellent en direct. Personne ne l'a décidé. C'est arrivé.

Le mécanisme

Une gateway unique doit servir des régimes de confiance différents avec une seule configuration. Face à ce conflit, une organisation raisonnable choisit le régime le plus strict, celui du flux le plus exposé.

Conséquence pour une équipe interne qui veut exposer une API :

• des quotas calibrés pour des inconnus, alors qu'elle est identifiée et jointe par Slack.
• un processus de publication conçu pour un contrat partenaire, avec revue et préavis.
• un aller-retour réseau supplémentaire, parfois par la zone d'exposition, pour joindre un service qui tourne à trois mètres.
• une latence ajoutée qu'elle ne peut justifier à personne.

Cette équipe a un projet à livrer. Elle fait ce que fait n'importe qui : elle appelle le service en direct.

Et là, la plateforme perd la seule chose qui justifiait son existence, la visibilité. Le jour où l'on veut savoir qui consomme quoi pour déprécier une API, la réponse est incomplète, et personne ne sait de combien.

Pourquoi c'est rarement corrigé

Parce que rien ne casse. Il n'y a pas d'incident, pas d'alerte, pas de ticket. Il y a simplement une plateforme dont le périmètre réel se réduit lentement pendant que son schéma d'architecture, lui, reste juste.

Le symptôme se lit dans un chiffre que personne ne calcule : la part du trafic inter-services qui traverse effectivement la gateway. Si elle baisse d'un trimestre à l'autre, la plateforme est en train d'être contournée.

Il se calcule sans projet. Le numérateur est dans les journaux de la gateway. Le dénominateur est dans la télémétrie du réseau : les flux entre pods d'un maillage comme Istio ou Cilium, ou à défaut les journaux de flux du réseau virtuel chez votre fournisseur de cloud. Les deux chiffres existent déjà. Ils ne sont simplement jamais mis côte à côte, parce qu'ils appartiennent à deux équipes différentes.

Les vraies raisons de garder une gateway unique

Il y en a, et elles sont légitimes.

Le démarrage. Au lancement, avec cinq API et un seul régime réellement en jeu, une seule gateway est le bon choix. Deux plateformes à exploiter pour cinq API est une sur-ingénierie qui coûtera plus cher que le problème qu'elle prévient.

L'absence d'équipe. Deux gateways veulent dire deux fois l'exploitation, et une seule astreinte qui doit connaître les deux. Sans les gens, la deuxième gateway est un risque, pas une protection.

Le coût de licence. Certains modèles facturent au control plane ou au data plane déployé, et le supplément est public : chez Kong, une seconde gateway hybride ajoute deux cents dollars par mois, une gateway dédiée cinq cents. La séparation se chiffre donc avant d'être décidée, et le montant est presque toujours inférieur à ce que le comité imagine.

Ces trois raisons ont un point commun : elles sont temporaires. Le problème n'est pas de commencer avec une gateway unique. Le problème est de ne jamais décider d'en sortir.

Ce qui coûte cher, et ce qui ne coûte rien

La bonne nouvelle : la topologie n'est pas la décision irréversible. Deux détails le sont, et ils ne coûtent rien au jour 1.

Les noms de domaine. Si le trafic interne et le trafic externe partagent le même nom d'hôte, les séparer un jour impose une migration à tous les consommateurs. Un api.exemple.fr unique aujourd'hui, c'est demain une modification de code chez chaque appelant, un cycle de recette chez chacun, un retour arrière à préparer pour chacun.

Deux noms distincts dès le départ, api.exemple.fr et api-interne.exemple.fr, même servis par la même gateway, rendent la séparation ultérieure invisible pour tout le monde : elle devient un changement d'enregistrement DNS. Une ligne de configuration aujourd'hui, plusieurs mois de coordination dans deux ans.

La frontière d'authentification. Décider tôt de l'endroit exact où le jeton est validé et de ce qui est transmis derrière. Déplacer cette frontière plus tard touche tous les services, un par un.

Le reste, nombre d'instances, produits, zones réseau, se change avec de l'argent et du temps. Ces deux-là se changent avec la coopération de tous vos consommateurs, ce qui est une autre monnaie.

La question à poser en comité

Une seule, et elle tranche mieux qu'un dossier d'architecture :

Que se passe-t-il si la gateway externe tombe ?

Si la réponse est « les équipes internes ne peuvent plus travailler », la topologie est mauvaise, quel que soit le produit, quel que soit son classement, quelle que soit la qualité de sa configuration.

Le détail des topologies possibles, unique, séparée, hybride, ou gateway plus service mesh, est traité dans flux interne, flux externe et gateway hybride.