Public facing applications have globally distributed users. In order to deliver low latency, the APIs that the application front ends consume, need to be globally distributed as well.
CDNs are used to deliver static content to globally distributed users but have limited efficacy for providing access to API endpoints that offer dynamic responses as requests come in. This article shows how to achieve low latency secure delivery of API endpoints using F5 Global Server Load Balancing, and Essential App Protect from F5 Cloud Services, and also to publish, authenticate and authorize API calls using NGINX Controller and NGINX Plus instances. The article shows how to achieve Central Management for APIs using NGINX Controller, and easy management of security of the API via F5 Cloud Services.
The picture below shows an architecture that I set up as an example for delivery of distributed API.
This architecture consists of three main layers: 1) Global Server Load Balancer (GSLB) Cloud Service for source aware traffic steering. 2) Essential App Protect (EAP) for application protection, and 3) NGINX Controller for centralized API delivery.
Traffic journey starts from user making DNS query for app.company.test. GSLB as authorized DNS server returns nearest EAP endpoint location which in turn forwards traffic to application instance in the same region to keep latency low. Lastly NGINX Plus gateway centrally managed by NGINX Controller load balances traffic between local application servers.
As any production ready architecture should be, this architecture is fully redundant and doesn't contain any single point of failure. If any hop in the chain goes down traffic gets redirected to secondary avaliable path. This is true for both cloud services and NGINX instances.
What is GSLB and why is it here?
The GSLB solution is offered in the cloud as a SaaS. It provides automatic failover, load balancing across multiple locations, increased reliability by avoiding a single point of failure, and increased performance by directing traffic to the nearest application instance. It does this by monitoring application availability and performance, and then responds dynamically to client DNS queries in order to direct traffic based on rules that you define.
The architecture uses GSLB to direct users to the nearest Essential App Protect endpoint that offers security for the traffic. When DNS query arrives at GSLB, it reads user source IP, identifies a region which this source belongs to and returns response from a pool associated with this particular source region. Therefore, regardless of user geographical location GSLB makes user traffic to go to the nearest EAP endpoint to keep latency low. Picture below shows the way GSLB routes traffic to the appropriate EAP instance.
At step 1 user makes a DNS query for api.company.test. GSLB as authorized DNS server returns CNAME type record with domain name of EAP endpoint. On step 2 user resolves domain name of Essential App Protect endpoint and gets Essential App Protect gateway IP addresses as destination for data traffic. Essential App Protect accepts connections from all users on the same gateway IPs and differentiates traffic based on HTTP host header in request. In our example, at this stage HTTP traffic with host header api.company.test is further examined by Essential App Protect.
What is EAP and why is it here?
Essential App Protect (EAP) is the first line of defense for API endpoints.. It intercepts all traffic destined to the API endpoint, performs full-featured WAF inspection and forwards only clean traffic to the backend.
EAP as a mature cloud service is avaliable in multiple regions around the world. Regardless of where user is located, EAP can accept user traffic with minimal latency and then forward it towards nearest backend. Obviously in order to keep latency low for all end users, application owner should have EAP endpoint and API instance deployed in every target region.
What is NGINX Controller and why is it here?
NGINX Controller is the cloud-agnostic application delivery platform which reduces deployment time, supports seamless integration with CI/CD tools and provides clear insights into performance metrics. NGINX Controller performs central management of NGINX Plus gateways that are geographically distributed and sit in front of every API instance. Just like every other element in the architecture, NGINX Controller is also deployed in HA mode. NGINX Plus instances talk to the Controllers via Load Balancers which forward traffic to the active Controller.
Data plane reliability is ensured by NGINX Plus HA in every region. It is important to note that doubling of NGINX Plus instances doesn't cause additional management burden for application development team. NGINX Controller pushes exactly the same configuration to all gateway instances.