Le control plane

Le control plane est l’endroit où l’intention se déclare : quelles API existent, quelles policies s’appliquent, qui a le droit d’appeler quoi. Il ne voit passer aucun trafic. La gateway exécute, lui décide.

Control plane

API, policies, identités, historique

configuration

Gateways

Servent le trafic avec la dernière configuration reçue

La séparation, et l’épreuve qui la vérifie

Un appel traverse la gateway en quelques millisecondes. Une modification de policy prend le temps d’une revue. Ces deux régimes ne doivent jamais dépendre l’un de l’autre, et la règle qui en découle se teste : la gateway doit continuer à servir avec sa dernière configuration connue quand le control plane est éteint.

L’épreuve se fait sur une plateforme d’essai, en coupant le control plane une journée. Trois choses se dégradent en général, et il faut savoir lesquelles vous acceptez : les nouvelles souscriptions et les rotations de clés ne se propagent plus, les compteurs de quota exacts dépendent d’un magasin central qui peut tomber avec le reste, et surtout une instance de gateway redémarrée pendant la coupure peut ne jamais devenir opérationnelle, faute de pouvoir récupérer sa configuration.

Ce dernier point corrige l’épreuve elle-même : couper le control plane ne suffit pas, il faut redémarrer une gateway pendant la coupure. Sans cela le test réussit toujours, et le jour d’un incident réel on découvre que la panne du control plane empêche la mise à l’échelle. La question mérite d’être posée avant l’achat, la réponse mérite d’être vérifiée.

Ce qu’il contient

• Le référentiel des API : contrats, versions, états de cycle de vie.
• Les policies, avec leur portée : globale, par API, par consommateur.
• Les identités applicatives : applications déclarées, clés, souscriptions. Les identités d’utilisateurs finaux restent au fournisseur d’identité.
• Les environnements, avec une promotion tracée de l’un vers l’autre : la même API n’a pas la même policy en recette et en production.
• L’historique : qui a changé quoi, quand, et comment revenir en arrière.

Son interface se juge sur son API

La console sert à explorer et à diagnostiquer. Elle ne doit pas être le moyen de modifier la production, pour les raisons développées dans industrialiser. Trois questions évaluent un produit :

• la configuration s’exporte-t-elle en totalité dans des fichiers versionnables.
• se réimporte-t-elle dans un environnement vide en reproduisant le même état.
• une modification faite hors de ce chemin est-elle détectée et signalée ?

Un produit qui échoue à la troisième condamne à un écart permanent entre le déclaré et le réel, sans moyen de le mesurer.

Le multi-gateway

Peu d’organisations n’ont qu’une gateway : une historique, une par fournisseur de cloud, une arrivée avec un rachat. Deux stratégies existent. La topologie hybride, un control plane unique qui pilote ses propres data planes déployés par zone, décrite dans interne et externe. Et la fédération, une couche de gouvernance qui inventorie et surveille des gateways de fournisseurs différents sans les remplacer. Plusieurs produits du marché se positionnent désormais là.

Dans les deux cas, la question préalable est la même : quelles gateways sont pilotées, lesquelles ne le sont pas. L’inventaire honnête tient sur une page, et les incidents se produisent dans la colonne non pilotée.

Les piliers qu’il porte

Les trois autres piliers ne passent pas par lui. L’accès et la médiation s’appliquent sur le chemin de l’appel, donc à la gateway. La découverte se joue sur le portail.