The API Gateway: Networking at Layer 8

You may recall earlier in 2021, I declared a “Well-Defined API is Layer 8.” In that declaration, I made two statements that are relevant to our discussion today:  

The first is relevant because it establishes the definition of an API. The second is relevant because it demonstrates that APIs ride atop the existing network stack, which makes them layer eight.

Now consider this definition of an API gateway:

“An API gateway takes all API calls from clients, then routes them to the appropriate microservice with request routing, composition, and protocol translation. Typically it handles a request by invoking multiple microservices and aggregating the results to determine the best path. It can translate between web protocols and unfriendly web protocols that are used internally.”  

I could rewrite this definition and use an IPv6 gateway to illustrate the parallel, but I won’t belabor the point. The reason it’s important to recognize that an API gateway is networking at layer eight is to discuss its role as a strategic point of control in the network architecture.

Just as ADCs become a strategic point of control due to its use to route requests, translate protocols (HTTPS to HTTP, anyone), and seek out the best path (load balancing/global server load balancing), the API Gateway is rapidly becoming a strategic point of control in the “application” network. I use scare quotes because it’s not really a separate network but rather a separate plane in the existing network stack. It’s accretive, not an alternative.

Whenever an architectural construct becomes “the thing” through which all traffic is routed, it becomes a strategic point of control at which decisions can be made. Those decisions might be security-related, such as redirecting requests for operational API commands through some security mechanism to ensure legitimacy and authority of the requester to invoke such a command. These decisions might be performance-related, such that they are able to determine the "best path" based on business outcomes related to digital experience expectations. That might be availability despite degraded performance, or it might be solely based on performance. By virtue of its architectural position in the network, the API Gateway is often the best judge of how to meet those expectations.

API Gateways are definitely becoming “the thing.” Nearly half (48%) of organizations are already employing them, and one in four (25%) plans to employ them by the end of 2021, based on our research.

And that’s a good thing because the use of APIs continues to explode by the minute. A survey conducted at the end of 2020 found that “API usage is poised to grow even more throughout 2021. The survey found 71.1% of developers expect to use more APIs in 2021.” [emphasis added] 

The combination of digital transformation and adoption of modern, microservices-based architectures is certainly behind this growth. For example, a 2020 Propeller Insights survey found that the sweet spot for the number of APIs per application was between 26 and 50.

api gateway.jpg

So, this growth really is – or is likely to be – explosive. Because as usual, this doesn’t take into consideration the proliferation of cloud and other operational APIs that are being exposed to manage and operate everything from IoT to network devices to admin consoles.

API growth is inevitable. That growth effectively adds more traffic – requests and responses - to the network at a layer above the traditional network stack. That makes it inevitable that a network construct will rise to provide the means to route, secure, and manage the requests and responses that traverse that network.

That construct is the API Gateway, and it will be a strategic point of control for organizations to manage, secure, and optimize the experiences of operators and consumers who – albeit unknowingly – rely on them.