Un monolito heredado se ejecuta detrás de un balanceador de carga interno en Azure VMs. Debe migrar incrementalmente los endpoints a microservicios con cero tiempo de inactividad y preservar un único endpoint de API público. El plan es mover una ruta a la vez a nuevos servicios mientras se mantiene el resto en el monolito. ¿Qué debería implementar?

La opción correcta es implementar Azure API Management (APIM) porque permite un patrón de migración incremental conocido como "Strangler Fig Pattern". APIM puede actuar como una puerta de enlace unificada, dirigiendo el tráfico a diferentes backends (el monolito o los nuevos microservicios) basándose en reglas de enrutamiento (por ejemplo, rutas de URL). Esto permite migrar endpoints específicos sin afectar otros, manteniendo un único endpoint público y logrando cero tiempo de inactividad. Las políticas de APIM, como la reescritura de URL y el enrutamiento condicional, son ideales para este escenario. Las opciones incorrectas son: Reconstruir completamente y cambiar el DNS implica tiempo de inactividad y no es incremental. Exponer microservicios directamente a través de Front Door no mantiene un único endpoint de API público para el monolito y los microservicios combinados, y no facilita la migración incremental de rutas específicas. Azure Traffic Manager se basa en DNS y enrutamiento a nivel de IP, no en rutas de URL específicas, y el enrutamiento ponderado dividiría todo el tráfico aleatoriamente, no rutas específicas. Reemplazar con Logic Apps y mantener dos endpoints públicos no cumple con el requisito de un único endpoint de API público y no es el enfoque más eficiente para la migración de microservicios.