Your API program is accelerating, with new APIs being delivered on a weekly basis. You have formalised an API centre for enablement (API C4E) to ensure that your delivery teams are equipped to design and deliver APIs quickly and consistently. Everything seems to be going great.
And then it hits you. An email arrives that asks how a solution team is supposed to integrate with two separate API gateway vendors. After some digging, you realise that someone in another part of the organisation has procured an API gateway from a different vendor. You do some more digging and realise that five separate API vendors are deployed in your organisation.
How do you manage your API C4E when you have multiple API gateway vendors? Let’s dive into why this situation occurs and provide some steps to help you stay organised and secure in a multi-gateway environment.
How did we end up with multiple API gateways?
Multiple API gateways are standard for medium-to-large organisations. There are five common reasons why your organisation has various API gateway vendors. Let’s explore each and identify the primary reasons your organisation is now dealing with multiple API gateways.
Reason #1: Local procurement of an API gateway
The most common reason for multiple API gateways is that organisational structures have resulted in a local governance model. This may be due to political or legacy reasons, or perhaps the organisation has failed to identify the need for API gateways to be part of shared infrastructure. Whatever the reason, multiple areas of the organisation have licensed API gateways from different vendors.
The yearly licensing fees may cost too much when supporting multiple vendors, so it will be up to API C4E to build a roadmap to handle multiple API gateway vendors and eventually reduce the number of vendors used across the organisation.
Reason #2: Mergers and acquisitions
Another common reason for multiple API gateway vendors is due to mergers and acquisitions. M&A brings with it the merging of staff, technologies, and multiple API gateways. Because APIs from acquired companies already have consumers, you can’t simply move everyone over at once. Instead, you will need to manage multiple API gateway vendors for the foreseeable future. However, this introduces an interoperability issue that has to be resolved.
Reason #3: Cloud migration
Many enterprises are still migrating their systems to the cloud. Some have opted for a lift-and-shift, while others are modernising systems while undergoing a cloud migration. This leaves APIs in on-premises data centres and the cloud that requires an API gateway.
Under these circumstances, the organisation has selected a new API gateway vendor for their cloud environment while retaining the existing vendor for on-premises. Blending both environments is becoming difficult, given vendors’ different identity and access management approaches.
Reason #4: Multi-cloud vendor support
Related to cloud migration, many cloud vendors now offer API gateway solutions. For organisations opting to apply a multi-cloud strategy, this will require the management of multiple API gateway vendors. Each cloud environment is slightly different but requires its API gateway to gain the most flexibility. You must now balance API management and security across multiple gateways your cloud vendors offer.
Reason #5: Regulatory and multi-tenant requirements
For highly regulated industries, it is common to need separate API gateway instances to limit the amount of API consumers accessing sensitive information. Dedicated gateway instances also help speed up the audit process, as network traffic is limited to those operations that are under regulation. In these circumstances, the same or different vendors may be selected to support the APIs in this sensitive environment. A related pattern separates partner and internal API traffic to prevent negatively impacting the other when traffic spikes occur.
We covered the need for multiple API gateway instances in a previous article, all about using multiple API gateways to support compliance, security, and flexibility.
Implementing API governance with multiple API gateways
We have determined the reason for having multiple API gateway vendors, which helps us to understand how we got here. It is your job to create a path to unify the gateway vendors into something more manageable.
Identify the needs
The focus is whether to remain this way, consolidate to a few vendors, or select one vendor and eliminate the others. If you are in charge of the entire API program, you may need to understand the key features or reasons why each vendor is required. This means capturing each vendor’s advantages list, what specific features are relied upon, and what features are not used. This will help you establish a plan to keep or sunset each API gateway in the organisation.
Create the roadmap
The next step is to unify API governance across these different groups and API gateway vendors. To ensure that developers can move between APIs on other gateways, APIs must be designed for consistency.
Start by establishing API standards and practices acceptable to different groups across the organisation. You should start with a set of shared standards that groups slowly move to as they are able without introducing breaking changes to their API consumers. Over time, you may end up with a centralised or federated governance model. We discussed this in the article titled, “How to create an API style guide, and why“.
Consistency is key moving forward if you will sunset all but one API gateway or decide they will need to co-exist for some time. Find ways to unite the different groups, consolidating your API gateways over time, all while striving for standards and practices.
Additional strategies for multiple API gateways
While API governance is essential, there are some additional steps you can take as you work toward unifying your API gateway strategy. I have seen these strategies used across different organisations I have consulted with over the last decade.
1. Unify your authorisation
If you cannot consolidate your API gateways, you may need a unified control plane to keep them all in sync and managed properly. This could involve implementing a unified API management layer that reverse proxies all API calls to the appropriate API gateway.
This will allow you to begin to unify your authorisation model while ensuring your API configuration is consistently applied to prevent malicious usage.
2. Establish a central API catalogue
With a unified authorisation approach underway, API consumers need to be able to see all of your APIs across the entire organisation. Unify your API portfolio by registering all APIs into a centralised API catalogue.
3. Create a unified traffic log
It may be inevitable that your API gateways will need to continue to run in parallel for some time. Use a distributed logging solution to capture and report API traffic and usage patterns across your gateways.
4. Introduce reverse proxies
In the cases where APIs are not using an API gateway, introduce a reverse proxy to log API traffic. Examine your logs, looking for shadow APIs that you didn’t know existed.
These reports will also help you to spot zombie APIs that are no longer used but require expensive infrastructure resources. Shadow and zombie APIs can be a source of API exploits since they are no longer monitored or managed, so this process will help you firm up your security posture simultaneously.
5. Add support for troubleshooting
Consider adding correlation identifiers to help trace calls between APIs, especially those spanning API gateways. When troubleshooting a problem that spans API gateways, this will be essential as you may currently have no insight into how API calls are moving between API gateways.
Interoperability across gateway vendors
We’ve talked about why organisations may end up with multiple API gateways. We also looked at some strategies to unify your API gateway strategy. Take the time to assess the current situation, plot a solution that includes fewer API gateway vendors when possible, and then work toward unifying your API gateways.
While you may never get to a single vendor approach, these strategies will make interoperability across gateway vendors possible while ensuring a consistent governance approach.
