Share via

Should Internal services communication go through Azure APIM?

SeanN 21 Reputation points
2020-10-05T21:32:54.747+00:00

Hi,
I have a question regarding what services would go through APIM Gateway.

Here is a scenario: Services of all departments of an enterprise are running in on-premise.
Would you have internal service-service interactions going through APIM Gateway?

Other scenario: What about services in one VNET connecting to services in another VNET? would they go through APIM Gateway?

Thank you!
Sean

Azure API Management
Azure API Management
An Azure service that provides a hybrid, multi-cloud management platform for APIs.
2,243 questions
0 comments

4 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Pramod Valavala 20,646 Reputation points Microsoft Employee
    2020-10-06T13:43:56.967+00:00

    This would completely depend on your requirements.

    Azure APIM provides functionality like authentication, caching, rate limiting, etc. If these are things you would like to enforce between internal service calls, then APIM would be a good fit. Also, it could serve as a service discovery endpoint where all internal services would be available for use, especially if you have lots of microservices that can be reused across other services.

    Even across VNETs, APIM could be present if required for reasons like above. You could also restrict which APIs are exposed compared to peering the VNETs together, if that is something that you are looking for.

    0 comments
  2. SeanN 21 Reputation points
    2020-10-06T18:18:50.667+00:00

    We have two opposing thoughts about using APIM as a gateway between internal services.
    As you mentioned, one thought is to use APIM for discovery and decoupling. Another opposing thought is treat gateway as front to the API landscape. Let other tools do the job so that it doesn't need make additional hop.

    Just to be sure, In the diagram taken from Azure documentation.. I annotated to show what we are talking. So you are saying it is it okay for Service 1 call going back to API Gateway to call Service 2?

    30553-custom-service-api-gateway.png

    https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern

    In the same doc, it said this.

    " In addition, there are many other products in the market offering API Gateways features, such as Apigee, Kong, MuleSoft, WSO2, and other products like Linkerd and Istio for service mesh ingress controller features." -- when would you chose service mesh for service-service control vs APIM gateway?

    Also, if we use API layers design approach, do you see all internal service - service going through APIM gateway?
    30476-layers.png

    if you look at the service mesh diagram: https://miro.medium.com/max/2000/1*JHrJe_8TO05wRQvwhwoKfA.png, there is no going back to gateway.
    I just wonder whether Azure APIM is even designed for inter service communication with in the network. If so, would that be an anti pattern of Gateway Pattern? Is this officially supported feature of APIM to act as a Service Mesh?

    Also, there is this stack overflow post where a poster covered about load on the API Gateway.https://stackoverflow.com/a/56845784
    Is this a valid concern with Azure APIM? I noticed it uses EventHub underneath as there are some capacity metrics.

    Thank you!

    0 comments
  3. Pramod Valavala 20,646 Reputation points Microsoft Employee
    2020-10-07T05:26:11.497+00:00

    From this design perspective, an API Gateway is meant as an aggregation layer to reduce the number of requests coming in from clients. And while the same gateway could be used for inter-service requests, it would not be recommended since it would increase the load on the same gateway instance. And yes, this is a valid concern to have but can easily be mitigated by having multiple instances of the gateway - public and internal instances, for example.

    Now coming to Service Meshes, they aim to provide most features of an API Gateway tailored for service-to-service communication and there are different kinds of such service meshes.

    1. Proxy Pattern
      These could simply be API Gateways themselves, acting like a proxy between services. These are usually simpler solutions and open-source equivalents like Traefik Mesh follow this pattern. The obvious downside here is the extra hop and potential bottleneck (this can be avoided by scaling the proxy) but could make sense for a simpler setup where not a lot of microservices (and traffic) are involved.
    2. Sidecar Pattern
      This is how most of the other service meshes work (like Istio, Linkerd, etc.). Here a sidecar (container or process) runs alongside each microservice handling all network traffic coming in and going out of the service (surprisingly two hops in this case, but these are localhost hops). The sidecar implements all the functionality you would expect like retry, authentication (like mTLS), etc. These service-meshes are usually more complex to setup and demand more compute for all the extra proxy/sidecar containers running, but pay off for the benefits they bring in.

    Considering all of the above, the sidecar pattern is the more enticing one to consider but is something that you will have decide on, taking into account your requirements and the investment required to setup.

    Doubling back to your questions,

    So you are saying it is it okay for Service 1 call going back to API Gateway to call Service 2?

    Yes. Not a problem apart from the network hop and being aware of the capacity required for your scenario. APIM has a nice developer portal which internal developers can come to try out the different APIs while they are integrating them into your app.

    Also, since APIM exposes Swagger Specs for these APIs, you could use that to generate SDKs for simpler integration. This is something sidecar-style service meshes do not provide but instead developers write the swagger themselves to or author SDKs if required.

    when would you chose service mesh for service-service control vs APIM gateway?

    I hope the above description should help. In the end, it would depend on your requirements.

    Personally, I'd go with a service mesh for large projects and a simpler solution for smaller projects (unless I could deploy them into an existing K8s cluster that has a service mesh ready to use).

    Also, if we use API layers design approach, do you see all internal service - service going through APIM gateway?

    Depending on the pattern you choose above. In case of APIM, yes.

    I just wonder whether Azure APIM is even designed for inter service communication with in the network. If so, would that be an anti pattern of Gateway Pattern? Is this officially supported feature of APIM to act as a Service Mesh?

    The Gateway Pattern is for client-to-service communication. And APIM can be used to expose APIs which can be consumed by client applications or other services, doesn't really matter to it.

    I don't see any reason it should not work as a proxy between services. Additionally, APIM supports calling Dapr Services and Service Fabric Apps.

    Is this a valid concern with Azure APIM? I noticed it uses EventHub underneath as there are some capacity metrics.

    Yes. You would scale the gateway as required to handle the expected load. As for Event Hub, I believe it's just used for logging.

    0 comments
  4. SeanN 21 Reputation points
    2020-10-08T00:18:20.503+00:00

    Thank you for detailed response.

    Yes. Not a problem apart from the network hop and being aware of the capacity required for your scenario. APIM has a nice developer portal which internal developers can come to try out the different APIs while they are integrating them into your app.

    The Gateway Pattern is for client-to-service communication. And APIM can be used to expose APIs which can be consumed by client applications or other services, doesn't really matter to it.

    I don't see any reason it should not work as a proxy between services. Additionally, APIM supports calling Dapr Services and Service Fabric Apps.

    Please check it out .. as how API gateway between services becomes an ESB. A Microsoft architect at Azure Service Bus talk here https://youtu.be/rXi5CLjIQ9k?t=661. He is using Azure itself as a case study.

    30811-screen-shot-2020-10-06-at-32250-pm.png30794-screen-shot-2020-10-06-at-32350-pm.png

    Yes. You would scale the gateway as required to handle the expected load. As for Event Hub, I believe it's just used for logging.

    It looks APIM uses EvenHub under the hood. Following metrics APIM is exposing to Azure Monitor.
    https://learn.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported

    EventHubDroppedEvents Yes Dropped EventHub Events Count Total Number of events skipped because of queue size limit reached Location
    EventHubRejectedEvents Yes Rejected EventHub Events Count Total Number of rejected EventHub events (wrong configuration or unauthorized) Location
    EventHubSuccessfulEvents Yes Successful EventHub Events Count Total Number of successful EventHub events Location
    EventHubThrottledEvents Yes Throttled EventHub Events Count Total Number of throttled EventHub events Location
    EventHubTimedoutEvents Yes Timed Out EventHub Events Count Total Number of timed out EventHub events Location
    EventHubTotalBytesSent Yes Size of EventHub Events Bytes Total Total size of EventHub events in bytes Location
    EventHubTotalEvents Yes Total EventHub Events Count Total Number of events sent to EventHub Location
    EventHubTotalFailedEvents Yes Failed EventHub Events Count Total Number of failed EventHub events

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.