Le flux interne et l'effet mille-feuille

Un appel entre deux services internes traverse rarement une seule couche. Dans les plateformes que l’on croise, il en traverse trois ou quatre : un load balancer, un point d’entrée de cluster, une gateway d’API, parfois un proxy de maillage. Chacune a été ajoutée pour une bonne raison, aucune n’a été retirée, et personne ne possède l’empilement.

Aucune de ces couches n’est absurde prise isolément, et c’est bien le problème. Le load balancer existait avant la plateforme, le point d’entrée est arrivé avec Kubernetes, la gateway avec l’API management, le maillage avec le chiffrement entre services. Chacune a été justifiée devant une instance différente, à une époque différente, par une équipe différente. La question « combien de sauts pour un appel interne » n’a jamais été posée à personne, parce qu’elle ne relève d’aucun de ces projets.

Ce que ça coûte

De la latence, et surtout de la variance. Chaque saut ajoute son traitement et une traversée réseau : comptez deux à cinq millisecondes par couche correctement dimensionnée, donc dix à vingt millisecondes pour un empilement à quatre. Sur un appel interne qui devrait en prendre vingt, la plomberie double le temps de réponse.

Mais le vrai coût n’est pas cette moyenne, c’est la variance. Quatre couches, ce sont quatre occasions de tomber sur une file d’attente pleine, une pause du moteur d’exécution ou une renégociation de connexion. Chaque couche a son propre centile 99, et ils ne surviennent pas au même moment : un appel a donc quatre fois plus de chances d’en croiser un. C’est pourquoi l’empilement se voit sur les centiles hauts, ceux qui font les signalements, et pas dans le tableau de bord qui affiche une moyenne rassurante.

Et de l’infrastructure. Une couche qui n’applique aucune policy utile continue de consommer des instances, des certificats, une supervision et une place dans chaque astreinte. C’est le chiffre le plus facile à sortir d’un dossier de simplification, et celui qu’on oublie de compter.

Un diagnostic impossible. Quand la latence monte, la question devient « laquelle des quatre » et personne ne peut y répondre sans corréler des journaux de quatre outils différents. C’est la situation que l’observabilité doit éviter, et l’empilement la rend mécaniquement plus difficile.

Des policies en double, ou en contradiction. Deux couches limitent le débit avec des seuils différents, deux couches réessaient, et un retry de retry multiplie la charge sur un backend déjà en difficulté. Ce cas est traité dans la résilience : les retries ne se composent pas, ils se multiplient.

Des contournements. Le coût le plus élevé n’est pas technique. Une équipe interne qui subit quatre sauts, des quotas conçus pour des inconnus et un délai de publication finit par appeler le service en direct. La plateforme perd sa visibilité, et c’est le sujet de pourquoi vos équipes contournent la plateforme.

Le principe qui range l’empilement

Une règle simple suffit à trancher la plupart des cas : une couche par frontière franchie, pas une couche par fonction souhaitée.

Un appel interne entre deux services du même domaine de confiance ne franchit aucune frontière. Il n’a donc besoin d’aucune gateway d’API. Ce dont il a besoin, identité de service, chiffrement, télémétrie, reprise, relève du réseau ou du maillage. À une condition, que le maillage ne soit pas lui-même un saut de plus : c’est ce que change un maillage sans sidecar, ou une télémétrie prise au niveau du noyau. Le partage précis est dans gateway et service mesh.

Un appel qui franchit une frontière de confiance, entre domaines, vers un partenaire, depuis l’extérieur, passe par la gateway, et une seule fois.

Ce que ça donne en pratique

L’application de ce tableau retire souvent une couche entière, et c’est presque toujours la gateway d’API sur les flux internes du même domaine. Elle y avait été mise pour la visibilité. La visibilité s’obtient mieux par la télémétrie du réseau, sans se mettre sur le chemin.

Par où commencer

Le préalable est un inventaire, et il tient sur une page : pour trois appels internes représentatifs, la liste des sauts, avec le temps passé dans chacun. Ce document se fabrique en une journée avec des traces distribuées et il produit presque toujours au moins une surprise : un saut que personne ne savait présent, ou une policy appliquée deux fois.

Le retrait se fait ensuite couche par couche, en commençant par celle qui n’applique aucune policy et ne produit aucune télémétrie que les autres ne produisent pas. Il y en a presque toujours une.

Une précaution : retirer une couche modifie les adresses sources vues par les services en aval. Les règles de filtrage réseau qui s’appuient dessus doivent être révisées avant, et c’est le genre de détail qui transforme une simplification en incident.