Application/API Gateway
An application gateway, also commonly referred to as an API Gateway, is used in a microservices architecture for traffic aggregation and request routing of inbound client requests to the necessary services. These gateways are also quite commonly used for authentication offload and SSL offload, as well as quality of service throttling, monitoring, and many other things. Even very basic load balancing and routing requirements will often require a reverse gateway, as most load balancers in public cloud environments are not dynamic or flexible enough to meet the needs of modern microservices deployments.
Common Gateway Responsibilities:
• Request routing and load balancing: Perform service lookup and route requests to the appropriate service instances.
• Request aggregation: To reduce chattiness between the client and back-end services, the gateway will sometimes be responsible for handling a single request from the client, and then sending requests to multiple services and returning the aggregate results as a response to the client.
• SSL offload: A secure SSL connection is established between the client and the gateway, and then non-SSL connections are used internally, or different internal certificates are used to encrypt communications.
• Authentication: A gateway can be responsible for authenticating requests, and then passing customer information to the services behind them.
• Protocol transformation: The gateway can be responsible for converting protocols the client might need to those used by the internal services.
NGINX and HAProxy are two of the more popular technologies used as application gateways today. Both of these applications support dynamically configurable back-end pools. Tools like confd or Consul Templates can be used to maintain the back-end pools, replicating data from the service registry into configurations.
Figure 5.7 shows two or more instances of an application gateway running behind an Azure load balancer for high availability. Services will announce changes and the endpoint information to the service discovery registry. The gateway will update its upstream pools based on the services and service instance information. The gateway can then route requests using the path, so that requests to the “/catalog” path are routed to instances of the catalog service. The gateway can load balance across multiple instances of the catalog services, even though they are different machines and ports. Requests can be routed based on other factors such as the destination port, IP address, or some header value.
We don’t necessarily need to deploy our gateway onto separate dedicated nodes. We could instead configure the Azure load balancer to route traffic to a couple of nodes in the cluster, and then use tagging and constraints to deploy a gateway container to appropriate hosts. We could also configure the load balancer to route traffic to every node in the cluster and set up a gateway on every node in the cluster. A gateway on every node in the cluster can work well for small clusters, but as the cluster size increases you might want to use a dedicated set of nodes. These nodes can be part of the cluster or they could be special virtual machines outside the cluster manager, even in a different edge network.
Deployment Considerations:
• Dedicated gateway: Use a dedicated set of gateway virtual machines managed independently of the scheduler. The Azure load balancer is then configured to load balance across this specific set of machines.
• Peer gateway request routing: With a smaller cluster, we can place a gateway on each node in the cluster and route requests. By doing this we can save management and compute costs by eliminating a couple of virtual machines. When adding a node to the cluster, we will need to update the load balancer.
• Dedicated cluster nodes: We can configure the Azure load balancer to route traffic to a subset of the nodes in the cluster and tag the nodes appropriately so that we can schedule a gateway to run on them. We will need to ensure the Azure load balancer configuration and node configuration are in sync.