Um monólito legado é executado por trás de um balanceador de carga interno em VMs do Azure. Você deve migrar endpoints incrementalmente para microsserviços com tempo de inatividade zero e preservar um único endpoint de API público. O plano é mover uma rota por vez para novos serviços, mantendo o restante no monólito. O que você deve implementar?

A opção correta é usar o Azure API Management (APIM) porque ele permite a migração incremental de um monólito para microsserviços com tempo de inatividade zero, mantendo um único endpoint público. O APIM atua como um gateway de API, permitindo configurar o monólito e os novos microsserviços como backends. Através de políticas de roteamento baseadas em caminho (path-based routing) e reescrita (rewrite), é possível direcionar operações específicas para os microsserviços, enquanto o restante do tráfego continua para o monólito. Isso suporta estratégias como canary releases ou blue/green deployments, essenciais para uma transição suave. As outras opções são incorretas porque: Reconstruir completamente e fazer um cutover único é arriscado e não garante tempo de inatividade zero. Expor microsserviços diretamente via Azure Front Door sem um gateway de API centralizado não permite o roteamento granular necessário para a migração incremental e manter um único endpoint. O Azure Traffic Manager opera em um nível de DNS/IP e não oferece o roteamento baseado em caminho ou políticas de reescrita necessárias para direcionar operações específicas dentro de uma API. Substituir módulos por Logic Apps e manter dois endpoints públicos viola o requisito de um único endpoint de API público e pode introduzir complexidade desnecessária.