Gateway Groups and Gateway Instances
In this document, you will learn the concept and uses of gateway groups and gateway instances, an advanced and exclusive feature in API7 Gateway.
Overview
A gateway instance is a single proxy that handles traffic, while a gateway group is a logical unit that combines one or more API gateway instances. This ensures consistent API handling and simplifies administration across the group. Multiple gateway instances within a gateway group operate independently to realize horizontal scaling and load balancing. Although using centralized configurations, gateway instances do not share states.
The default gateway group is sufficient for simple scenarios with only a single cluster or production environment. The advanced gateway groups are used for complex scenarios with separate API policies for different subsidiaries, lines of business, clusters, and environments like UAT and Staging. Although API7 Enterprise lacks concepts of multiple clusters and environments, you can achieve the same goal by naming and labeling gateway groups.
A gateway group contains one or more gateway instances, but each gateway instance belongs to only one gateway group. The gateway instances can be deployed on the same or different virtual machines, bare metal servers, or Kubernetes nodes. Such combinations can meet users' diverse requirements across multiple lines of business, clusters, work zones, and environments.
For example, in the diagram below, two teams are using API gateway in a company: Payment Team and Quote Team. The Payment Team has Production and UAT environments while the Quote Team has only one Production environment. In this case, three gateway groups can be created: Payment Prod, Payment UAT, and Quote Prod, and they can be labeled with Env:Prod and Env:UAT.
Key Features
API Gateway Group Management: Managing a collection of API gateways as a logical unit sharing the same configurations. This simplifies administration and ensures consistent policy enforcement across the gateway instances.
Business-Aligned Gateway Partitioning: Segregating an enterprise's lines of business and solutions by assigning them to dedicated API gateway groups. This architectural approach enables better alignment between the API infrastructure and the organization's functional domains.
Physical Isolation: The gateway group isolates multiple API gateway instances in different physical environments, including datacenters, cloud platforms, and virtual machines. This effectively prevents interference between gateway groups and enhances system stability and security.
Elastic Scaling: Gateway group dynamically adds or removes API gateway instances based on traffic fluctuations to meet business demands. This improves resource utilization and reduces operational costs.
Scalable and Flexible Infrastructure: The logical architecture of the API gateway group is decoupled from the physical deployment of the individual gateway instances. This approach provides increased flexibility and scalability for the API infrastructure.
Fine-Grained Permission Control: The gateway group enables different permission configurations for different gateway instances and APIs to adhere to compliance requirements.
Ingress Controller: Support Kubernetes ingress controller using API7 Enterprise as the high-performance reverse proxy. Using the declarative way to configure resources provided by API7 Enterprise.
Use Cases
Segregating Development, Test, UAT, and Production Environments
API deployment and release go through different stages and environments, which vary depending on companies' API management processes. Suppose your company has four environments: Dev, Test, UAT, and Prod. Without using gateway groups, you need to deploy 4 separate instances of API7 Enterprise, each with its independent control plane and data plane. Developers, QA, and Ops engineers need to develop, test, and release the same API by accessing API7 Enterprise's control plane with different domain names.
This approach has significant drawbacks. When you have 5 business lines, each with 4 environments, you need to deploy a total of 20 sets of API7 Enterprise, resulting in resource wastage and increased management costs.
By utilizing the gateway groups feature of API7 Enterprise, you can easily overcome this challenge. You can create 20 different gateway groups, following a naming convention that combines business line and environment names, and add labels for filtering and selection. Additionally, Role-Based Access Control (RBAC) can be applied to enable fine-grained permission control. In this manner, the developers can only modify the configuration in the development environment.
Managing Multiple Clusters across Different Regions
It is challenging to manage API services across multiple regions and clusters while ensuring data compliance for companies with a global customer base. Suppose your company operates in NA, EU, and APAC regions with 4 production clusters in each. Without gateway groups, you would need to maintain 12 sets of API gateway control planes and data planes. However, configuration discrepancies can easily occur with this approach.
Consistent API Gateway configs do not guarantee encryption, privacy, and compliance for loggers, secrets, and observability tools - extra work is needed.
API7 Enterprise's gateway groups provide a solution to centrally manage and configure API gateway clusters across multiple regions using a single control plane. You can use environment variables, service discovery, and registry centers to simplify and unify management and maintenance to reduce overall maintenance costs.
Moreover, API7 Enterprise supports multi-layer networking, enabling seamless data processing and compliance across regions. If a US user named John logs in from Europe, the EU cluster can determine and redirect his API requests to the NA cluster based on his user ID. This capability ensures compliance and efficient API request handling.
Meeting Service-Level Objectives for Different Projects
Services within various projects vary from their Service Level Objectives (SLOs). For instance, the SLO for a payment service can be 99.999%, while the SLO for a historical order service might be 99%. Specific strategies can be used for each service to align with their respective SLOs.
The infrastructure and operations teams can deploy the payment service in multiple regions. Then allocate more gateway instances and higher-quality machine resources to this gateway group, and set strict alerting policies and detailed observability metrics for it. Conversely, the historical order service with lower SLO requirements can adopt a lightweight deployment strategy with relaxed alerts and monitoring to reduce resource allocation.
Gateway Instance Status
Gateway instance status represents the connectivity between gateway instances (data plane) and control plane. It is reported periodically by each gateway instance. Only healthy gateway instances can handle API traffic.
- Healthy: Gateway instance is running normally.
- Only Heartbeat: This status indicates a configuration delivery failure, even though the gateway instance is maintaining a connection with control plane through heartbeat probes.
- Lost Connection: The control plane has not detected the gateway instance for more than 30 seconds but less than 2 hours.
- Offline: The control plane has not detected the gateway instance for more than 2 hours. In this case, if the gateway instance still cannot connect to the control plane, the gateway instance will be removed after 7 days.