Un monolite legacy è in esecuzione dietro un load balancer interno su VM di Azure. È necessario migrare gli endpoint in modo incrementale a microservizi con zero tempi di inattività e preservare un singolo endpoint API pubblico. Il piano prevede di spostare una rotta alla volta verso nuovi servizi mantenendo il resto sul monolite. Cosa si dovrebbe implementare?

Questa opzione è corretta perché Azure API Management (APIM) è progettato per gestire API, consentendo di definire backend multipli (il monolite e i nuovi microservizi) e di utilizzare policy avanzate per il routing basato sul percorso o la riscrittura. Questo permette una migrazione incrementale (strategia "strangler fig") reindirizzando specifiche chiamate API ai nuovi microservizi, mantenendo il resto sul monolite, il tutto con un unico endpoint pubblico e senza tempi di inattività. Le altre opzioni sono errate perché: Ricostruire e fare un cutover in un weekend comporta tempi di inattività e rischi elevati. Esporre i microservizi direttamente tramite Azure Front Door non risolve la necessità di un singolo endpoint API pubblico che gestisca sia il monolite che i microservizi in modo incrementale. Front Door è più adatto per il bilanciamento del carico globale e la protezione, non per la logica di routing API complessa tra backend diversi. Azure Traffic Manager opera a livello DNS e non è adatto per il routing basato sul percorso o per la gestione di API specifiche; dividerebbe il traffico casualmente per tutte le rotte, non per operazioni specifiche. Sostituire moduli con Logic Apps e mantenere due endpoint pubblici non soddisfa il requisito di un singolo endpoint API pubblico e potrebbe introdurre complessità nella gestione degli endpoint.