A comparison of push vs phone-home communication approaches between API Gateways and Management Services

API Gateways deliver critical runtime capabilities in enterprise-wide API management infrastructures. However, such runtime capabilities must also be complemented with other design-time and governance capabilities in support of activities such as APIs lifecycle management, API design, policy definition and implementation, deployment, retirement, monitoring, and so on.

The aforementioned design-time/governance capabilities, are often offered by different API management vendors as a separate Management Service infrastructure that augments/complements the runtime infrastructure (API Gateways). Needless to say in order for runtime and design-time/governance infrastructure to work together cohesively as a collective whole, there must be some sort of effective and reliable communication between these two main components.

Whereas some products like for example the Oracle API Platform Cloud Service, deliver a phone-home approach for API Gateways to communicate with the management infrastructure, other vendors implement a push approach whereby the Management Service is responsible for establishing and handling the connection to the API Gateways.

Both approaches are fundamentally different and understanding how such differences can impact/influence a solution becomes even more critical as the need for API Gateways increase e.g. as a result of  adopting cloud or Microservices Architectures.

Furthermore, as cloud adoption continues to rocket, vendors also offer Management Service capabilities as a PaaS cloud service. This is important and not trivial as it means that communication between the PaaS-based management infrastructure and the API Gateways must be in placed prior implementing the solution.

This article compares these two main communication strategies and highlights key differences including pros and cons (from the point of view of the author).

Installation / Configuration:
When installing/configuring an API Management solution, both Management Service and API Gateways should be provisioned and configured so they can talk to each other. The communication style can have a considerable impact in the steps required in order to implement the solution (e.g. open firewalls, etc).

Push:

• Pros:
• No obvious benefit.
• Cons:
• May require several network / firewall changes in order to allow inbound connections to the API Gateways if the same reside in a DMZ e.g. on-premises. This may be even more complicated if the the ports used are non-standard and random.

Phone-home (pull):

• Pros:
• Installation / configuration of the API Gateway "might" not require any major changes in networks/firewalls as connections are initiated by the API gateways to the management service (in principle) using standard ports (e.g. HTTPS/443).
• Cons:
• Outbound connectivity to the Management Service must be in place. If the management infrastructure resides in the cloud, this means outbound internet access is required. Not necessarily a con but an important consideration.

Deployment of APIs:
Once APIs are defined along with their relevant policies (e.g. OAuth, API key validation, throttling, rate-limiting, API plans, etc) they are deployed to the relevant API Gateways. The more API Gateways an API have to be deployed to, the more complicated and error prone the process can be.

Push:

• Pros:
• The main benefit is that deployment of APIs occur immediately as soon as a deployment task is initiated. This is because the Management Service initiates the connection to the API Gateway.
• Cons:
• As direct connection to the API Gateway is required, some vendor offerings might require the Management Service and API Gateways to reside in the same network segment. This is an important constraint and it also means that as more API Gateways are required (e.g. in the cloud or different locations), additional Management Services have to be implemented which is not ideal and introduces additional management overheads, complexity and costs.
• Depending on the size of the solution and how many Management Services are in place, deployment of a single API to multiple API Gateways in one-go, can be a non-trivial task.
• Issues in communication between Management Service and API Gateways may only become evident during the deployment of APIs, which isn't ideal.

Phone-home (pull):

• Pros:
• It is the API Gateway’s responsibility to phone-home and download/configure APIs, typically at the pre-defined interval (e.g. every minute, every-hour).
• The internals also act as heart-beat. So issues in communication between API Gateway and Management Service should become evident rather quickly and not during a deployment.
• Cons:
• Deployments may take a while to complete if pre-defined time internals are long (basically it won't be immediate).

Infrastructure Topology:
As briefly mentioned previously, how the management infrastructure and the API Gateway communicate, does impose important considerations in regards to the overall API management infrastructure topology and options available.

Push:

• Pros:
• Typically the Management Service can be installed and configured by the client in any infrastructure of choice. This can be beneficial if full API Management infrastructure is is required in a close-loop network with several constraints (e.g. A cruise ship) 
• Cons:
• Potential proliferation of management infrastructure as more than one Management Service might be required.
• Increased complexity in the management of the infrastructure and most likely also an increase in costs.

Phone-home (pull):

• Pros:
• Typically it means that API Gateways can share a single management infrastructure, which simplifies the solution and reduces the management overhead and costs.
• Cons:
• If the management infrastructure is only available as a PaaS capability, for solutions with special network constraints or requirements this might not be an option.

Solution at Scale:
Some very large organisations may have the need to implement API Gateways at very large scale (e.g. hundreds to even thousands). In such large-scale implementations, every small factor becomes an important consideration, and how Management Services and API Gateways communicate, is certainly of them.

Push:

• Pros:
• If the solution requires (could be for organisational reasons) to have multiple and separate management infrastructure, a push model could work well.
• Cons:
• A proliferation of management infrastructure results in overall higher TCO and more complexity.
• Additional tooling may be required to provide some sort of centralised monitoring capabilities so the overall API management infrastructure can be monitored.

Phone-home (pull):

• Pros:
• This solution is more easily scalable as more API Gateways can be added without necessarily having to also increase the number of Management Service.
• Simpler solution to operate given reduced number of Management Services.
• Deployment of APIs becomes a much easier task. A single Management Service can deploy to several API Gateways deployed in many locations easily.
• Cons:
• A single management infrastructure, could also introduce a single point-of-failure. Therefore adequate high-availability infrastructure must be in placed.

Conclusion:
In the majority of cases the business or IT management won't be interested in understanding how API Gateways and management infrastructure interact. However a different story emerges if the implications of such communication are presented in terms of TCO impact, scalability of the solution and business agility. This article summarised some of these implications in terms of installation/configuration, deployment, infrastructure topology and scalability. But ultimately what solution (push vs phone-home) works best for your organisation should be determined by what business requirements is driving the need for APIs and their management, and how each approach can best help realise such benefits.