Un monolithe existant s'exécute derrière un équilibreur de charge interne sur des machines virtuelles Azure. Vous devez migrer progressivement les points de terminaison vers des microservices sans interruption de service et conserver un point de terminaison d'API public unique. Le plan est de déplacer une route à la fois vers de nouveaux services tout en conservant le reste sur le monolithe. Que devriez-vous implémenter ?

La bonne réponse est d'utiliser Azure API Management (APIM) car il agit comme une passerelle d'API unifiée qui peut gérer plusieurs backends (le monolithe existant et les nouveaux microservices) derrière un seul point de terminaison public. Les politiques d'APIM, telles que le routage basé sur le chemin (réécritures d'URL) et le routage canary, permettent de diriger progressivement des routes spécifiques vers les microservices tout en maintenant le reste du trafic vers le monolithe, sans interruption de service. Cette approche est idéale pour une migration progressive (strangler fig pattern). Reconstruire entièrement et basculer le DNS en un week-end est risqué et ne permet pas une migration progressive. Exposer les microservices directement via Azure Front Door ne gère pas le routage conditionnel vers le monolithe pour les routes non migrées. Azure Traffic Manager est un équilibreur de charge DNS global et ne permet pas un routage fin basé sur le chemin au niveau de l'API. Remplacer par des Logic Apps et maintenir deux points de terminaison publics ne répond pas à l'exigence d'un point de terminaison API public unique.