Omni Gateway & gestion des API multi-protocoles (Course #omni-gateway)
For architectes, admins plateforme, DevOps.
À la fin, vous saurez
À l'issue de cette formation, vous serez capable de positionner et piloter une gateway multi-protocoles unifiée (REST, GraphQL, gRPC, WebSocket, IA) afin d'aligner tous les backends sur un seul control plane et un jeu de policies uniques.
Cas fil rouge
Cascadia Logistics gouverne 90 API dispersées entre Classic Mule Gateway, bords NGINX improvisés et un proxy LLM hors contrôle ; le dernier audit pointe un mTLS incohérent et aucune vision centrale du trafic. À évaluer : une couche gateway multi-protocoles unifiée, sous NFR — policies déployées en < 1 semaine, mTLS sur 100 % des appels est-ouest, plafond de dépense LLM par équipe.
Programme chaque ligne est quelque chose que vous faites
6 modules · 14 sujets · dans l'ordre du cours
-
Module 1
Générations de gateways comparées
Objectif. Comparer les générations de gateways sur modèles de déploiement et périmètre protocolaire pour objectiver la migration.
- Comparer Classic Mule Gateway, Flex Gateway et Omni Gateway sur modes de déploiement et protocoles couverts
- Formuler les motifs de migration en écarts mesurables : constats d'audit, délais d'application des policies, plafonds de coûts
-
Module 2
Un seul control plane
Objectif. Schématiser la séparation control plane/data plane et placer chaque runtime dans la topologie cible.
- Esquisser les responsabilités control plane vs data plane pour un patrimoine hybride mêlant runtimes Mule et non-Mule
- Placer microservices et endpoints IA dans la topologie en marquant autonomie et frontières d'isolation de panne
-
Module 3
Toute API, un seul catalogue
Objectif. Intégrer des endpoints hétérogènes dans un catalogue unique doté de métadonnées propriétaire/tier/SLA uniformes.
- Enregistrer des endpoints REST/OAS, GraphQL, gRPC/Protobuf, WebSocket et LLM avec métadonnées uniformes (owner, tier, SLA)
- Vérifier les sondes de santé par protocole et signaler tout endpoint sans check (cible : 100 % sondés)
-
Module 4
Une policy, appliquée partout
Objectif. Normaliser mTLS, OAuth et token exchange en bundles réutilisables validés protocole par protocole.
- Paramétrer mTLS, OAuth 2.0 et token exchange en bundles de policies réutilisables sur backends hétérogènes
- Prouver l'application par tests négatifs — certificats expirés, audiences erronées — sur une gateway de préproduction
-
Module 5
Économie du trafic IA, observée au bord
Objectif. Arbitrer les coûts du trafic IA au bord — plafonds par token, refacturation, cache sémantique — preuves analytiques à l'appui.
- Limiter les API LLM par jetons plutôt que par requêtes (exemple de plafond : 100 k tokens/min par client)
- Refacturer la dépense LLM par équipe avec arrêts durs — alertes à 80 % et 100 % du budget, 429 aux en-têtes exploitables
- Expérimenter le cache sémantique sur prompts répétés, fraîcheur pesée contre tokens économisés (cible : −30 % de facture LLM)
- Consolider l'analytics gateway dans Anypoint Insights et propager le contexte de trace entre HTTP et trames WebSocket
- Alerter sur les pics de coût, pas seulement de latence — un agent emballé se voit en dollars avant de se voir en millisecondes
-
Module 6
Lab : trois backends, une gateway
Objectif. Produire le livrable du lab : trois types de backends enregistrés et gouvernés sous une même configuration gateway.
- Enregistrer une app Mule, un microservice tiers et un endpoint LLM sous une même gateway avec policies partagées
Références & documentation officielle chaque affirmation ci-dessus a une source
Transversal au cours
- Présentation d'Omni GatewayDoc MuleSoft
Module 1
- Présentation des gateways Anypoint PlatformDoc MuleSoft
Module 2
- Modèles de déploiement d'Omni GatewayDoc MuleSoft
Module 3
- Ajouter une instance d'API Omni GatewayDoc MuleSoft
Module 4
- RFC 8693 — Échange de jetons OAuth 2.0Spécification
- Politique Transport Layer Security — entranteDoc MuleSoft
Module 5
Module 6
- Démarrer avec Omni Gateway auto-géréDoc MuleSoft