Exploring the need for an open source protocol and SDK
Multi-gateway developer portals are something that a growing number of our customers and prospects have started asking us about. In most cases the goal is to have a single platform portal that allows organizations to get observability across their API landscape. To achieve this goal, APIs need to be findable and discoverable, and not isolated on a vendor island. This is essential to improve developer experience, and a first step towards a coherent development platform.
Multi-gateway portals make it possible to organize information in a way that makes it easier for developers to form a mental model of an organization’s IT architecture and is related to the need for developer portals to document many different interface types.
Will you use key provisioning?
Fast key provisioning is an important aspect of developer experience, that is why most gateway providers have an automated provisioning capability in their integrated developer portal solution. The reality is that a lot of businesses can’t provide a frictionless approval process for key provisioning—there is a need to wait for a human to approve the API access request. In the case of an external developer portal, the rules can be very strict. To date, most of our customers have security, data governance, or business reasons why a majority of their APIs require some sort of evaluation step before a developer will get access to an API. Often these approval processes also depend on who is requesting access: the same request might be automatically granted for an internal colleague, and require processing for an external partner.
On the other hand, on external developer portals, mock APIs are often freely available with a free and frictionless onboarding process because this allows you to:
- capture contact details and to receive permission from developers to facilitate marketing/conversion activities; and
- provide realistic responses and error codes to facilitate development (for example, some banking companies require their customers to develop against a mock API and to troubleshoot any issues they encounter before they get production access).
But mock APIs can be hosted on a dedicated infrastructure that is integrated with your developer portal solution, so in this case you might not need a multi-gateway integration.
Unify developer experience through a gateway
Another solution is to put a gateway in front of all the other gateways, this allows you to use the full range of features of a gateway like Apigee (for example, for monetisation). In a lot of cases customers express concerns about latency as a result of an extra proxy hop. There are ways to mitigate the latency. For example, moving the gateway proxy closer to the service such as when using a hybrid cloud approach.
Proxying your legacy gateway infrastructure might make sense when:
- you need advanced policy tools like API products abstractions, apps, and monetization to turn APIs into customer facing API products;
- you are planning an eventual migration to a new gateway; and
- you want a multi-layer governance model for certain target audiences.
Why multiple gateways?
If the above scenarios don’t work, you will probably need a developer portal that can connect to multiple gateways.
Even in organizations that have done a centrally coordinated API roll-out with a single API gateway there are often parts of the organization that have implemented part of their landscape on top of a second, third or even fourth API gateway. Especially in larger organizations, the convergence of gateway vendors and cloud providers means that they need to deal with a fragmented gateway landscape.
There are also strategic reasons why organizations may deliberately implement APIs across multiple gateways:
- To prevent vendor lock-in
- To better satisfy divergent technical requirements
- Multi-cloud strategy (although gateway solutions like Apigee Hybrid allow you to deploy proxies across cloud providers)
- Data residency in different regulatory regions
- Conflicting gateway requirements: e.g. internal vs external API programs
Towards an open API management API standard
In 2020, we drafted a gateway agnostic protocol definition for a customer that wanted to be able to switch gateways without having to reimplement their devportal. The protocol we worked with provided a generalization of the core capabilities that an API management solution usually delivers. Based on the protocol a middleware could be implemented on the customer’s infrastructure and can sit between their gateway and the developer portal we created for them.
Benefits to Implementing the gateway connection as a stand-alone application:
- it allows customers that work with cloud-hosted developer portals, to host the application that provisions keys on their on-prem infrastructure;
- it adds an additional application layer that can be hardened against attacks; and
- it creates a standalone application that makes it easier for organizations to collaborate on gateway integrations.
Drawbacks of implementing the gateway connection as a stand-alone application:
- some advanced API gateway features might not be available in a unified protocol;
- added latency; and
- extra maintenance cost.
Limitations to this type of solution:
- Budget and timeline introduce constraints for delivering external devportal needs or internal devportal needs, support for various types of key provisioning, etc.
- Normalizing differences in how keys and apps are provisioned out of each gateway may pose unique challenges.
An open source API gateway middleware
A new generation of API management solutions has emerged on the heels of the acquisition wave that brought the largest players in the API management landscape into the hands of the leading cloud vendors. As a result there is now an even larger landscape of API management solutions that all have implemented their own developer portal solution.
Traditionally developer portals have been a part of the evaluation criteria that analysts like Gartner and Forrester use to help organizations choose their gateway solution. But in a world where companies need multi-gateway developer portals, challenger and incumbent gateways might start to bundle their efforts to create a best of class open source developer portal, and to focus on differentiating features in the gateway.
Any gateway that works with a developer portal solution that doesn’t require a customer to migrate APIs, will be more valuable for companies with a mature API program. The key feature of such a generic developer portal solution would be the ability to connect to a broad range of the most important API gateways.
An open source gateway connector
As gateway solutions continue to differentiate, and APIs grow in importance, the growing complexity of the gateway landscape could benefit from an open source gateway protocol and/or bridge that creates an interoperability layer for the community. Such a layer would free up the energy that today flows into point-to-point integration because:
- developer portal teams don’t need to keep up with API changes from their gateway vendors, but can rely on the central team to do so;
- new gateway providers only need to integrate with the open source connector project to become compatible with a range of tools in the ecosystem; and
- teams that have built an in-house gateway solution can integrate with a range of tools through the connector project.
This is the first step towards an integrated coherent capability platform.
How you can help
We are researching what would be the best solution for the community. If you are interested in an open source gateway connector project, as a user or collaborator, you can help us organize a better project by filling out our questionnaire.
All Pronovix publications are the fruit of a team effort, enabled by the research and collective knowledge of the entire Pronovix team. Our ideas and experiences are greatly shaped by our clients and the communities we participate in.
