I am creating a reference architecture regarding integration patterns for hybrid on-premises/Azure cloud scenarios. An Azure Express Route is established between the two worlds.
In the on-premises world, there is already a middlware service that handles the inbound-outbound traffic and acts as a gateway.
In the Azure cloud world, there is already an APIM instance that handles the inbound traffic and the outbound traffic to external public services.
I am thinking to use the APIM for system-to-system invocations between an Azure cloud application (Azure Function, Logic App, AKS Microservice etc.) and the on-premises middlware/gateway application. The reasons behind this is that I wanted a centralized management system of all the inbound and outbound traffic, having all the policies, security, logging and traffic management in one system. Also all the Azure systems will not have direct dependencies with the on-premises systems, having only APIM to manage that. I am also considering some downsides like the scaling of APIM that currently takes at least 20 minutes, which is considered huge for low latency scenarios. Also, adding one more hop, except from the added latency, introduces more risk for potential failures as APIM is becoming a SPOF.
What are your thoughts on such an architectural approach?
Overall it makes sense. Not sure if you've seen it already, but this reference architecture is similar to what you're building: https://learn.microsoft.com/en-us/azure/architecture/example-scenario/integration/app-gateway-internal-api-management-function
Some comments:
SPOF concerns can be mitigated by onboarding availability zones to be protected from compute failure. Configuration deployment failures can be prevented by controlling your dev process.
Look at v2 tiers to have lower provisioning and scaling time: https://learn.microsoft.com/en-us/azure/api-management/v2-service-tiers-overview#key-capabilities