NET-Microservices-Architecture-for-Containerized-NET-Applications-(Microsoft-eBook)

The API Gateway pattern versus the Direct client-to-microservice
communication
In a microservices architecture, each microservice exposes a set of (typically) fine‐grained endpoints.
This fact can impact the client‐to‐microservice communication, as explained in this section.
Direct client-to-microservice communication
A possible approach is to use a direct client-to-microservice communication architecture. In this
approach, a client app can make requests directly to some of the microservices, as shown in Figure 4-
12.
Figure 4-12. Using a direct client-to-microservice communication architecture
In this approach. each microservice has a public endpoint, sometimes with a different TCP port for each
microservice. An example of a URL for a particular service could be the following URL in Azure:
http://eshoponcontainers.westus.cloudapp.azure.com:88/
In a production environment based on a cluster, that URL would map to the load balancer used in the
cluster, which in turn distributes the requests across the microservices. In production environments,
you could have an Application Delivery Controller (ADC) like Azure Application Gateway between your
microservices and the Internet. This acts as a transparent tier that not only performs load balancing,
but secures your services by offering SSL termination. This improves the load of your hosts by
offloading CPU-intensive SSL termination and other routing duties to the Azure Application Gateway.
In any case, a load balancer and ADC are transparent from a logical application architecture point of
view.
A direct client-to-microservice communication architecture could be good enough for a small
microservice-based application, especially if the client app is a server-side web application like an
ASP.NET MVC app. However, when you build large and complex microservice-based applications (for
40 Architecting Container- and Microservice-Based Applications