You have been charged with designing your company’s API gateway deployment strategy. You know that an API gateway will help with managing authorisation, API token management, rate limiting, caching, logging, and analytics. But, should you recommend a single API gateway cluster to handle all of your APIs, or should you have separate gateways? If separate gateways are preferred, how should you segment them? This article will examine the benefits of a multi-gateway approach to your API platform, along with common gateway segmentation approaches.
From one to many API gateways
As organisations embark on installing an API gateway, they often struggle with how to approach their gateway strategy. Questions emerge such as:
- Do we deploy a single API gateway cluster that will handle all API requests for all internal and external APIs?
- How do we limit access to specific endpoints to limit the risk of a security breach for sensitive data?
- Should we have a dedicated partner API gateway?
- Do we even need an API gateway for our internal APIs?
- How does our API gateway deployment impact our regulatory compliance?
Often, using multiple API gateways provides considerable flexibility. Often, the most compelling argument for multiple API gateways is the ability to segment APIs based on risk or compliance. Let’s examine the different segmentation approaches and when each one may be useful to your company.
The internal API gateway
Internal APIs, meant for consumption within the data center or cloud, often benefit from a dedicated API gateway. This offers a few advantages, including:
- Limiting network access to sensitive APIs not meant for public consumption
- Reducing the impact of internal API consumption by segmenting internal traffic from partners and user apps
- Supporting a gradual migration path for legacy APIs not currently protected by an API gateway or that use a custom authorisation style
The partner API gateway
Dedicated partner gateways are becoming more common to restrict partner integrations to specific endpoints. There may be several reasons for this, including:
- Allowing increased rate limits without causing a negative impact on other users
- Limiting data access of personally identifiable information (PII) by restricting the data returned to only the specific fields agreed upon in the partnership agreement
- Reduce the likelihood of malicious activity by a rogue developer or partner-leaked access token
Some organisations may be concerned with opening all partner endpoints to all partners. Instead, they choose to further restrict the endpoints available to each partner while segmenting their partner-specific endpoints from those never exposed to partners. By using a dedicated partner API gateway, organisations can further protect their APIs by reducing the endpoints exposed to partners while ensuring that partner traffic does not impact users or internal systems.
The public API gateway
A dedicated public API gateway is designed to support different use cases than internal or partner gateways. APIs onboarded into a public API gateway are designed to be used by web and mobile apps. Public APIs may also be offered to developers to interact with their own data. Or, perhaps the public APIs are targeting third-party developers building solutions on behalf of customers using specific scopes authorised using a three-legged OAuth approach. Careful thought should go into the onboarding of APIs to the public API gateway, perhaps limiting the endpoints available to a subset of the overall APIs managed by the organisation.
API gateways for compliance
Regulatory compliance is one of the most compelling and perhaps the most popular reason for multiple API gateways. For organisations that require PCI compliance audits, isolating the endpoints involved to a dedicated gateway and infrastructure often contributes to an easier auditing process. Financial institutions and ecommerce websites often apply this pattern.
Environment-based gateways
Organisations that maintain multiple environments, such as separate dev, staging, and production environments, may wish to deploy a separate gateway for each environment. Just keep in mind that when multiple environments are combined with multiple API gateways, the number of instances required will multiply. It is common to see a shared API gateway for non-prod environments, rather than a per-environment gateway, to reduce the number of gateway instances required.
When one API gateway is enough
We have looked at the different kinds of API gateway deployed by some organisations. If the reasons offered for each type of gateway doesn’t fit your organisation’s requirements, you may wish to start with a single API gateway segment, then re-evaluate the need for multiple segments in the future. This not only simplifies your automated deployments, it will also reduce operating costs by limiting your API gateway footprint. Consider the reasons for multiple API gateways outlined in this article, then weigh the benefits and challenges to determine what the right approach is for your organisation.
For more ways to address the challenges vs the benefits, you can find out when microservices might be the wrong choice
