If you remember back to your high school days you’ll recall being taught about the earth’s magnetic field. Which to put it in layman’s terms is like seeing the earth as a huge magnetic bar with the red part of the bar being the North Pole and the blue part the South Pole – the magnetic field runs north to south. In a computing networking context, North-South traffic describes the client-to-server traffic that moves into the data center from a location outside of the data center. The term North-South comes from network diagram drawings that usually depict Wide Area Network (WAN) traffic vertically. For API Management, North-South traffic is the external traffic originating from external clients (API consumers), across the DMZ, arriving at some endpoint behind the DMZ.
However, with respect to Earth’s poles, at irregular intervals averaging several hundred thousand years, the earth’s field mysteriously reverses and the North and South Magnetic Poles respectively, abruptly switch place. The red part of the bar is now pointing south and vice versa!
READ MORE: Why you need an API Gateway and security
In a computer networking context, the same thing happens with traffic, requests can originate within the data center and be sent out to the cloud. (aka, ground to cloud) So rather than North-South orientation of traffic you have South-North traffic.
The API Gateway, typically aligned north and south, can also act as a security policy enforcement point for South-North traffic. The Gateway is therefore positioned between a company’s internal applications that rely upon cloud services and the respective cloud service providers. Positioning an API Gateway in this manner allows an enterprise to apply its security policies at the point of egress from their private network, only when these cloud resources are accessed.
As it’s sitting in the South-North traffic flow the API Gateway can provide the following capabilities:
API catalog: An API catalog offers visibility to cloud services and their respective APIs which are allowed to be consumed in the enterprise along with their Terms of Service. The catalog makes it possible for developers anywhere in the organization to search for, find, and integrate APIs they may want for their applications. Restrict access to cloud service by project/department/team.
Credentials management: Centrally manage credentials/tokens for accessing cloud services. There is no longer the need to issue to every consuming application of different cloud credentials. Revoke access to any cloud service in a single location.
Govern cloud access: Define the level of governance that your organization requires for access cloud services
Metering and Monitoring: Provide insights into your organization’s consumption of cloud services based on project/department/team/application.
Mediation: providing lightweight mediation and context-based routing to cloud services
Transformation: providing response transformation for easier consumption by the cloud service consumer.
Caching: reduce the number of calls to cloud service providers by caching request/responses in the Gateway thereby saving on pre-transaction subscript costs to cloud provider.
Even if the earth’s magnetic field is happily spinning, as long as you have an API Gateway in place you’re covered for N-S and S-N traffic.
LEARN MORE: Enterprise Comparison of API Gateways and ESBs