The use of API gateways in a microservices architecture provides a really interesting way of approaching the microservices integration problem, while also following one of the patterns of application integration through the use of federated gateways. So, let’s take a look at how the API gateways help us in the process of microservices integration.

An API gateway inside the microservices-based application acts as central point through which the microservices can interact with the other microservices present in the infrastructure. This API gateway provides the following characteristics:

• Restricted exposure of APIs: The API gateway provides the functionality of exposing only a restricted set of APIs from the backend microservices, hence limiting what functionality is exposed. Along with this, the API gateway can also introduce new API endpoints in the infrastructure, where each API endpoint can map to multiple API endpoints of the backend microservices.
• Federated access: An API gateway implements federated access for the integration of the microservices. This happens because of the fact that, if any two services want to interact with each other, a call needs to be made to the API gateway, which will indeed make the request to the other microservice and provides the result from the microservice.
• Transformation of request: The API gateway is also responsible for the transformation of the request between the microservices if both of them use a different mechanism of representing the data. For this kind of transformation to take place, the API gateway usually implements a common data format that every service can use to handle the communication with the API gateway, a concept which was usually implemented by the ESBs.

For microservices integrated through the use of API gateways, the process of communication between the different microservices looks as follows:

• Imagine that there are two microservices, A and B
• The microservice A wants to notify the microservice B of some event that has taken place as a result of some call or any other outside event
• The microservice A makes an API call to an endpoint of microservice B exposed by the API gateway
• The API gateway takes up the request, performs any kind of transformation on the request, and forwards the call to the microservice B
• The API gateway now waits for the response to be returned from the microservice B
• Once the response is returned, the API gateway transforms the response into the format supported by microservice A and returns the response back completing the cycle

This kind of process is usually followed with the other services as well.

The use of API gateways for the integration of the microservices provides a number of advantages over the traditional approaches, as in the following examples:

• Improved security: Since the API gateway restricts the exposed backend APIs, the API gateway provides better security between the different microservices. This security can also be increased by implementing simple end-to-end encryption between the communications happening between the different microservices and API gateway.
• Better scalability: An API gateway provides better scalability than traditional middleware-based approaches by allowing for dynamic scaling through the use of a load balancer. Multiple API gateway processes can run behind a load balancer, eventually distributing the requests coming to them.
• Easier maintenance: Applications integrated with the use of API gateways are usually easier to maintain due to the reduced amount of API endpoints that they need to manage individually.

Those are some great benefits and it seems like a good approach for integration of microservices-based applications. So, do we not require an ESB anymore? Has the ESB gone?

The answer to this is no. Rather, it has transformed with the advent of microservices. Let's take a look at how this transformation looks.