Reference Architecture Brief: API Management

28 February 2024 - ID G00802491 - 21 min read

By: Steve Deng
Initiatives:Software Architecture and Integration for Technical Professionals; Adopt
Modern Architectures and Technologies; Build and Deliver Software to Drive Business
Results

APIs and API management are fundamental to modern application

architecture and integration architecture. This research provides
application technical professionals with a reference architecture
for API management.

Architecture Brief
APIs and API management (APIM) have become critical to many modern application
architecture practices, such as microservices architecture (MSA), agile web applications,
cloud-native applications and application integration. A key platform capability for
managing APIs at runtime is the API gateway. API gateways secure north-south API traffic
at the network edge, enterprise edge, cloud edge and/or data center edge. They also
mediate east-west API traffic within the enterprise to support application-to-application or
service-to-service communication.

This reference architecture provides a structured framework for designing and

implementing API management across a variety of enterprise use cases. It focuses on the
most common and widely supported scenario: managing HTTP-based request-response
APIs. APIM practices and technical capabilities for other kinds of APIs (notably, event-
based APIs) are emerging. However, these scenarios require some different components
and capabilities that are not covered in this document.

Architecture Use Cases

API management architecture commonly supports the following use cases:

■ Offering external-facing APIs: In this scenario, organizations are exposing their

services and data to external developers via public APIs, private APIs or partner APIs.
Commercializing APIs that deliver access to valuable data or business capabilities
can open up new revenue and partnership channels.

Gartner, Inc. | G00802491 Page 1 of 22

This research note is restricted to the personal use of hoanx@[Link].

 ■ Managing third-party APIs: In this scenario, organizations are consuming third-party
APIs (e.g., mapping APIs, payment APIs, SaaS application APIs or other business
partner APIs). They want to control and monitor their usage of those APIs, either to
track and limit costs or to safeguard sensitive data.

■ Supporting MSA: In this scenario, organizations are using MSA principles to build
applications, and they need to manage and secure service-to-service and app-to-
service communication.

■ Implementing API-based integration: In this scenario, organizations are using APIs

to integrate internal and external applications, services and data. These APIs need to
be secured, managed and monitored.

■ Productizing APIs: When APIs are shared outside their immediate application
domain, they must be treated as products, with technical and nontechnical
contracts. In this scenario, organizations are productizing APIs so that internal or
external consumers can confidently use them to build and extend applications.

■ Managing APIs in hybrid/multicloud environments: In this scenario, organizations

need to manage, secure and monitor APIs consistently across hybrid and multicloud
environments.

Architecture Diagram
As shown in Figure 1, API management architecture comprises six core logical
components in a dual-plane architecture. These components must be deployed and
integrated into your operational environment. The figure also shows the relationships and
interactions among these components, using colored arrows to denote:

■ Policy/configuration flow

■ API transaction flow

■ Telemetry flow

■ Platform API flow

■ App identity and access management (IAM) flow

■ User IAM flow

Gartner, Inc. | G00802491 Page 2 of 22

This research note is restricted to the personal use of hoanx@[Link].

 Note that this is an abstract reference architecture. You will need to customize it to the
specific technologies and circumstances of your organization and your product
development teams.

Figure 1: Reference Architecture for API Management

Click to Download an Editable Version of This Figure

The reference architecture shows six types of connectivity:

■ Platform API flow: The integration between the API admin portal, API developer
portals or integrated development environments (IDEs), and other APIM components
via platform APIs provided by the control plane.

Gartner, Inc. | G00802491 Page 3 of 22

This research note is restricted to the personal use of hoanx@[Link].

 ■ API transaction flow: The flow of messages (e.g., requests, responses, commands or
events) between API consumers and the exposed service implementations. This flow
is mediated by one or more API gateways and optionally filtered by web application
and API protection (WAAP) capabilities.

■ Policy/configuration flow: The flow of policy or configuration updates from the

control plane to the API gateway instances making up the APIM data plane.

■ Telemetry flow: The asynchronous flow of observability and API usage metrics from
the API gateways to the control plane and telemetry collectors.

■ App IAM flow: The flow of access control requests from the control plane and data
plane to the enterprise IAM to utilize authentication, authorization, public-key
infrastructure (PKI), directories and secrets management services. The identities
being authenticated here may include:

■ Application users (of the apps that employ the API)

■ Application/service accounts for apps that don’t delegate user identity checks

■ User IAM flow: The flow of authentication/authorization (AuthN/AuthZ) requests

from the API admin portal, command line interface (CLI) and API developer portals to
the enterprise IAM to authorize provider- and consumer-user access to the platform.
Single sign-on (SSO) is also supported using this flow. Note that different identity
providers and tools may be used for the consumer identities versus the
provider/admin identities.

The core components of an APIM platform are (click links to jump to sections):

■ APIM data plane: Components (mainly API gateways) responsible for mediating
APIs implemented by the API providers and making them securely accessible by the
API consumers. The three primary types of API gateways in the APIM data plane are:

■ Enterprise API gateway: A component typically located on the network

perimeter to secure inbound and outbound API traffic

■ Lightweight API gateway: A component designed to be distributed and

deployed close to individual services

■ Ingress gateway: A component that functions as the network communications

gatekeeper for a container orchestration cluster or service mesh

Gartner, Inc. | G00802491 Page 4 of 22

This research note is restricted to the personal use of hoanx@[Link].

 ■ APIM control plane: The software and services that manage API gateway
configurations, API proxy definitions and APIM policies, including security, traffic
management, rate limiting, monitoring and caching. The APIM control plane also
provides platform APIs to integrate with API developer portals, API admin operations
and data plane interfaces, among others.

■ API admin portal: The UI component (either a web portal or a CLI) for API
administrators to manage API gateways and global policies, and for API providers to
manage API proxy definitions and application-specific policies.

■ API developer portal: The UI component (typically a web portal) for API consumer
developers to discover, test-drive and request access to APIs published in the
catalog.

The following are external components that frequently integrate with APIM architecture.
These components are covered in other Gartner Reference Architecture Briefs and
research:

■ Web application and API protection: WAAP solutions support security-based

controls to help protect the back-end service environment from malicious attacks or
accidental misuse. These solutions encompass a broad set of protection capabilities
and features for web-facing applications and services, including:

■ Bot detection to discover unauthorized automation and attacks

■ Distributed denial of service (DDoS) protection to defend against brute-force

saturation of service capacity

■ Web application firewalls (WAFs) to protect against web-technology-based

attacks, such as malformed requests, script injection and cross-site request
forgery (CSRF)

Gartner, Inc. | G00802491 Page 5 of 22

This research note is restricted to the personal use of hoanx@[Link].

 ■ Identity access management infrastructure: This is a collection of IAM tools that
are architected to enable identity-first security. It typically includes the following
components:

■ Access management

■ Identity federation

■ Token services

■ Application directory

■ PKI

■ Secrets manager

■ Thirty-party API observability and security audit: This is an optional group of API
observability components that collect and store usage metrics and operational
telemetry from the APIM control plane or API gateways. The telemetry collected can
support custom analytics/reporting (e.g., for digital experience monitoring and
monetization). With additional integration, the telemetry can also be leveraged by
some security tools for security audit purposes. Software observability components
typically include (see Reference Architecture Brief: Software Observability):

■ Telemetry collector

■ Telemetry data store

■ Telemetry analytics

■ Telemetry visualization

Architecture Capabilities and Components

The following subsections provide an overview of each component of the reference
architecture.

Enterprise API Gateway

Back to top

Gartner, Inc. | G00802491 Page 6 of 22

This research note is restricted to the personal use of hoanx@[Link].

 An enterprise API gateway is typically located on the network perimeter to secure inbound
and outbound API traffic. It is best-suited for external-facing, productized and published
APIs with monetization potential. These gateways are often centrally managed by the
organization and may be part of a broader APIM solution that includes API life cycle
management and an API developer portal.

Enterprise API gateways commonly support:

■ Access management (authentication and authorization)

■ Traffic management (quotas and distributed rate limiting)

■ Request routing

■ Request and response payload validation

■ Payload filtering or transformation

■ Caching

■ Coarse-grained security policy enforcement

Example Technologies

■ Amazon API Gateway

■ Axway Amplify API Management — API Gateway

■ Google Cloud Apigee X and Apigee hybrid API gateway

■ [Link] API Management

■ IBM API Connect API gateway

■ Kong Gateway

■ Microsoft Azure API Management — gateway

■ MuleSoft Anypoint Mule Gateway

■ Software AG webMethods API Gateway

■ WSO2 API Gateway

Key Characteristics

Gartner, Inc. | G00802491 Page 7 of 22

This research note is restricted to the personal use of hoanx@[Link].

 An enterprise API gateway implementation has the following general characteristics:

■ It must secure APIs at the edge of the enterprise, ensuring consistency in the
enterprise’s overall API security strategy. Typically, only coarse-grained policies are
enforced here.

■ It must publish APIs to consumers outside the enterprise as external, private or

partner APIs.

■ It must publish internally hosted APIs or third-party APIs to internal applications or

services.

■ It should manage access to APIs as products. These APIs are productized and
published in a developer portal or API marketplace.

■ It should support business value reporting and monetization, aiming to contribute

direct and indirect revenue to the business.

An enterprise API gateway implementation has the following technical characteristics:

■ It should be offered as SaaS and/or a customer self-managed deployment option.

■ It may require a multicomponent runtime footprint to operate, increasing the

operational overhead in customer self-managed environments.

■ It should integrate with WAAP and enterprise IAM infrastructure for all external-
facing north-south mediation.

Related Research

■ Decision Point for Mediating API and Microservices Communication

■ Comparing Architectures for Hybrid and Multicloud API Management

■ How to Evaluate API Management Solutions

■ How to Deliver Sustainable APIs

Lightweight API Gateway

Back to top

Gartner, Inc. | G00802491 Page 8 of 22

This research note is restricted to the personal use of hoanx@[Link].

 A lightweight API gateway, aka microgateway, is designed to be distributed and deployed
close to individual services. Unlike enterprise API gateways, which are often centrally
managed as shared middleware, lightweight gateways can be individually deployed,
configured and managed by a development team to meet the needs of the application.

Lightweight API gateways commonly support:

■ Access management (authentication and authorization)

■ Traffic management (quotas and distributed rate limiting)

■ Request routing

■ Request and response payload validation

■ Payload filtering or transformation

■ Caching

■ Basic security checks

Example Technologies

■ Apache APISIX

■ Contour

■ Envoy Gateway

■ Kong Gateway

■ Microsoft Azure self-hosted API gateway

■ MuleSoft Anypoint Flex Gateway

■ [Link] Gloo Gateway

■ Spring Cloud Gateway

■ Tyk Gateway

■ WSO2 API Platform for Kubernetes

Key Characteristics

Gartner, Inc. | G00802491 Page 9 of 22

This research note is restricted to the personal use of hoanx@[Link].

 A lightweight API gateway implementation has the following general characteristics:

■ It should be optimized as a self-contained turnkey solution for customers to deploy

and operate in private clouds or in on-premises data centers.

■ It should be configurable to keep its resource footprint to a minimum.

■ It should allow organizations to confine internal API traffic within their trusted
network for security and compliance reasons by placing the lightweight API gateway
in close proximity to API providers and API consumers.

■ It should allow certain lightweight gateway instances to enforce domain-specific,

fine-grained API policies as a way to implement a defense-in-depth strategy.

■ It can be deployed as part of the organization’s DevOps process. Configuration and

control can be delegated to the development team.

A lightweight API gateway implementation has the following technical characteristics:

■ Its lightweight runtime footprint can be packaged in a single container or virtual

machine (VM) image.

■ It’s built to be cloud-native. Recent implementations are built on the Envoy proxy.

Related Research

■ Decision Point for Mediating API and Microservices Communication

■ Comparing Architectures for Hybrid and Multicloud API Management

■ How to Evaluate API Management Solutions

■ How to Deliver Sustainable APIs

Ingress Gateway

Back to top

Gartner, Inc. | G00802491 Page 10 of 22

This research note is restricted to the personal use of hoanx@[Link].

 An ingress gateway is part of the organization’s container environment. It is a component
that functions as the network communications gatekeeper for a container orchestration
cluster or service mesh. All inbound traffic to services running inside the cluster must pass
through the ingress gateway first. As a result, the ingress gateway becomes an ideal
policy enforcement point (PEP) for protecting APIs implemented by the services deployed
to the cluster or service mesh.

In the context of this research, “ingress gateway” collectively refers to a class of

components that implement Kubernetes ingress functionality. Ingress gateways are
differentiated only by their configuration model, which could be Kubernetes Ingress
controller, Kubernetes Gateway API or a service mesh ingress gateway.

Example Technologies
■ Ambassador Labs Emissary-Ingress

■ Apache APISIX

■ Contour

■ Envoy Gateway

■ HashiCorp Consul API Gateway

■ Kong Ingress Controller (KIC) for Kubernetes

■ Mulesoft Anypoint Flex Gateway in connected mode

■ [Link] Gloo Gateway

■ Tyk Gateway

■ WSO2 API Platform for Kubernetes

Key Characteristics

An ingress gateway implementation has the following general characteristics:

■ It should secure all external access to services running in Kubernetes or a service

mesh.

Gartner, Inc. | G00802491 Page 11 of 22

This research note is restricted to the personal use of hoanx@[Link].

 ■ It should support the delegation of ingress routing rules to individual development
teams. This capability gives development teams autonomy over the application-
specific routing configurations while allowing the platform team to retain control
over the entry point of the cluster.

■ It must support a declarative configuration model to manage API mediation and

service deployment.

An ingress gateway implementation has the following technical characteristics:

■ It is often built on Envoy, with xDS as the most common data plane API.

■ It must support Kubernetes CustomerResourceDefinition (CRD)-based configuration.

It should support Kubernetes Ingress controller and/or Kubernetes Gateway API
CRDs.

■ It must minimize communication latency between gateway instances and the

control plane. Options include using a local control plane or a local agent to bridge
communication with remote control planes.

■ It may obtain policies from a remote APIM control plane via a local operator, or
directly from CRD.

Related Research

■ Decision Point for Mediating API and Microservices Communication

■ Comparing Architectures for Hybrid and Multicloud API Management

■ How to Evaluate API Management Solutions

■ How to Deliver Sustainable APIs

APIM Control Plane

Back to top

The APIM control plane is typically provided as a part of an APIM suite. It is a set of core
software and services that manage API gateway configurations, API proxy definitions, API
management policies, and API monitoring and observability policies. The control plane
hosts:

Gartner, Inc. | G00802491 Page 12 of 22

This research note is restricted to the personal use of hoanx@[Link].

 ■ Data plane APIs for communication with the API gateways

■ Platform APIs for communication with the API admin portal and API developer
portals

The platform APIs can also facilitate integration with external IDEs and DevOps
processes. The control plane often contains one or more data stores or repositories to
store API gateway configurations, API proxy definitions, API enforcement policies and API
usage metrics. APIM control plane implementations also include an API catalog or
registry, which can be accessed by API developer portals.

Runtime for the APIM control plane should be deployed and managed independently from
the data plane. APIM control planes are typically offered as managed services from cloud
providers or service providers. Only some APIM vendors offer self-hosted, customer-
managed APIM control plane options.

Example Technologies

■ Amazon Web Services (AWS) Management Console

■ APIIDA API Control Plane

■ APIwiz

■ Axway Amplify Management Plane

■ Envoy Gateway control plane

■ Google Cloud Apigee hybrid management plane

■ IBM API Connect control plane, including the management server and analytics
server

■ Kong Konnect — Kong Gateway control plane

■ Microsoft Azure API Management — management plane

■ WSO2 API Control Plane and Management Plane

Key Characteristics

An APIM control plane implementation has the following general characteristics:

Gartner, Inc. | G00802491 Page 13 of 22

This research note is restricted to the personal use of hoanx@[Link].

 ■ It must expose the control plane’s core capabilities, such as user management, API
definition and policy definition, via RESTful APIs. The vendor then uses these APIs to
implement the admin portal and developer portal features. The vendor also
publishes the APIs for automation and integration purposes.

■ It must maintain policy stores and distribute policy updates to API gateways.

■ It should receive and aggregate API usage metrics and telemetry from API gateways.

■ It should generate API analytics and reporting for API providers and consumers,
often via the admin portal and developer portals. Such API analytics can also
support API monetization/chargeback capabilities.

■ It should provide some basic form of built-in identity and access management when
an external enterprise IAM service is not available. This built-in capability should
include “superadmin” management to enable API gateway management, federation,
life cycle management and control from central IAM tools.

■ It must provide or facilitate certificate and secrets management for API gateway
provisioning and configuration.

■ It should support native integration with third-party IAM tools.

■ It must maintain a registry or catalog for API proxy definitions and interface
specifications.

An APIM control plane implementation has the following technical characteristics:

■ It should be deployed and managed independently from the data plane.

■ It should offer a self-hosted option (e.g., for internal-facing APIs).

■ It should offer SaaS options (e.g., for external-facing APIs).

■ It should use data plane APIs to dynamically configure the data plane.

■ It should publish data plane APIs (e.g., Envoy xDS) to facilitate integration with third-
party API gateways.

■ It should publish platform APIs for integration with third-party developer portals or
IDEs.

Gartner, Inc. | G00802491 Page 14 of 22

This research note is restricted to the personal use of hoanx@[Link].

 Related Research

■ Decision Point for Mediating API and Microservices Communication

■ Comparing Architectures for Hybrid and Multicloud API Management

■ How to Evaluate API Management Solutions

API Admin Portal (for API Providers)

Back to top

The API admin portal, aka API manager or APIM console, is the web UI front end to the
APIM control plane. It uses the platform APIs to communicate with the control plane core
services as part of the platform API flow. Alternate UIs for configuring the control plane
and API gateways include CLI and Kubernetes CRD.

The API admin portal serves as the policy administration point (PAP) for APIM platform
operators, API product managers and API providers to administer all aspects of the API
management platform.

APIM platform operators use the API admin portal and other tools to:

■ Set up and configure APIM environments

■ Set up multitenancy structures and role-based access control (RBAC) rules on the
APIM platform to support multiple lines of business (LOBs), departments or
development teams

■ Set up API gateway deployment topologies and cluster configurations

API product managers use the API admin portal to:

■ Define API products

■ Define API subscription plans

■ Approve or deny subscription requests from API consumers

■ View API usage metrics and reports

API providers/developers may use the API admin portal and other tools to:

Gartner, Inc. | G00802491 Page 15 of 22

This research note is restricted to the personal use of hoanx@[Link].

 ■ Create API proxy definitions and API documentation

■ Create and manage security, monitoring and routing policies

■ Manage the life cycle of their own APIs

Example Technologies
■ APIIDA API Developer Portal

■ APIwiz

■ Axway Amplify API Management — API Manager

■ Google Cloud Apigee UI

■ IBM API Connect API Manager

■ Kong Konnect — Gateway Manager

■ Microsoft Azure portal

■ [Link] Gloo Portal

■ WSO2 API Manager

Key Characteristics

An API admin portal implementation has the following general characteristics:

■ It should allow the APIM platform team or administrators to configure organizations,

suborganizations and environments for the APIM platform.

■ It should allow the APIM platform team or administrators to set up API gateway
instances, cluster configurations and high availability/disaster recovery (HA/DR)
options.

■ It should allow the APIM platform team or administrators to define global API
policies by organization, environment, application or product.

■ It should allow API providers to define API proxies, mediation policies, API products
and subscription plans.

An API admin portal implementation has the following technical characteristics:

Gartner, Inc. | G00802491 Page 16 of 22

This research note is restricted to the personal use of hoanx@[Link].

 ■ It is an integral part of the APIM platform, often with limited customization options.

■ It integrates with the APIM control plane using platform APIs.

Related Research

■ Decision Point for Mediating API and Microservices Communication

■ Comparing Architectures for Hybrid and Multicloud API Management

■ How to Evaluate API Management Solutions

■ How to Deliver Sustainable APIs

API Developer Portal (for Consumers)

Back to top

An API developer portal is a self-service website or UI designed to support developers. It

covers aspects of API consumption, including:

■ Access to API documentation

■ API client development support, such as software development kits (SDKs) and
sample codes

■ API testing tools

■ Self-service onboarding of API clients/consumers

■ Analytics and reporting on API usage by API consumers

Many organizations create separate developer portal instances — internal developer

portals and external developer portals — to serve distinct purposes and target audiences:

■ Internal API developer portal: This portal is optimized to support internal API
developers as part of developer hubs.

■ External API developer portal: This portal is the storefront that connects an
organization’s external API consumers to its public- or partner-facing APIs. Its
primary focus is to create developer communities and showcase API business value.

Example Technologies

Gartner, Inc. | G00802491 Page 17 of 22

This research note is restricted to the personal use of hoanx@[Link].

 Many API management products include a developer portal as part of their offering.
Examples include:

■ APIwiz API Marketplace

■ Axway Amplify API developer portal

■ Google Cloud Apigee Drupal modules and integrated portal

■ IBM API Connect Developer Portal

■ Kong Konnect Dev Portal

■ Microsoft Azure API Management developer portal

■ MuleSoft Anypoint Platform API portal

■ [Link] Gloo Portal

In addition, some stand-alone developer portal offerings include:

■ Apiable

■ Backstage

■ Microsoft Azure API Management developer portal (open-source software)

■ OpsLevel

■ Postman workspaces

■ SwaggerHub Portal

Key Characteristics

A developer portal implementation has the following general characteristics:

■ It must present to an API catalog. The API catalog may be managed by the API
control plane or, in some cases, be stand-alone to support the portal user experience
that must be maintained/synchronized with the runtime environment. An API catalog
is the most basic requirement of an API developer portal.

Gartner, Inc. | G00802491 Page 18 of 22

This research note is restricted to the personal use of hoanx@[Link].

 ■ It must enable developers to register and obtain the proper credentials — such as API
keys or client credentials for their consuming application — to access APIs published
on the developer portal. Developers can manage their credentials, with the ability to
add, modify, renew or revoke keys. This feature requires integration with the
respective APIM control plane.

■ Developers can access usage metrics and performance analytics to help optimize
their applications’ API consumption. This feature requires integration with analytics
and reporting capabilities, either built into the APIM platform or available from third
parties.

■ Developers can seek assistance from API product teams or engage with the broader
developer community to exchange knowledge and share code. API providers can
also use the developer portal to communicate feature updates, changes in SLAs and
service contracts, and changes to relevant policies.

■ API client libraries, downloadable via a developer portal, allow the developer to
interact with the API through a well-defined object model rather than through low-
level API calls. Such libraries are referred to as “SDKs” once they approach full
coverage of all API features. The easier the SDK is to use, and the more functionally
complete it is, the more productive a developer using it will be.

A developer portal implementation has the following technical characteristics:

■ It is built on a content management system (CMS), such as Drupal. Familiarity with

the underlying CMS may be required to customize/enhance the portal.

■ It must integrate with APIM and other components to support self-service

onboarding, visibility of analytics and metrics, and maintenance of any stand-alone
API catalog (if present).

■ It must integrate with enterprise IAM for SSO of internal/external users via identity
federation.

Related Research

■ Leverage API Portals for Successful API Adoption

Key Architecture Principles and Patterns

Foundational principles of API management architecture include:

Gartner, Inc. | G00802491 Page 19 of 22

This research note is restricted to the personal use of hoanx@[Link].

 ■ API mediation: API gateways act as an abstraction layer between sources and
consumers, decoupling them from one another. API mediation may include protocol
and format transformation, content filtering and mapping, and orchestration and
composition of requests and responses.

■ Dual-plane architecture: The data plane (including API gateways) and control plane
are decoupled. Control plane and data plane components can be deployed and
managed independently of each other.

■ Modular design: Key API management capabilities, such as developer portals, API
gateways and analytics, are independent components that can be customized,
extended or replaced by customers to meet specific requirements.

■ API- and event-based communication: API management components interact with

each other using well-defined APIs and events.

■ Cloud-native design: APIM architecture is cloud-native by design and is ready to

support hybrid and multicloud deployment.

■ APIs as products: The APIM platform embraces and supports APIs as products
throughout their life cycle for all personas involved, including API providers, product
managers and API consumers.

■ Customer focus: The APIM platform enables API providers to design, develop,
maintain and continuously improve APIs to meet the customers’ evolving needs.

Key Architecture Recommendations

■ Implement API mediation centered on API gateways, but do not overload the
gateways with integration tasks. Use complementary technologies, such as
enterprise service bus (ESB), integration platform as a service (iPaaS) and custom
software, to accomplish complex integration tasks.

■ Use cloud-managed enterprise API gateways for external-facing public APIs or

partner APIs to provide high availability and elasticity while minimizing operational
costs. However, latency and data ingress/egress are concerns for internal APIs,
especially when the API consumers and API providers are located on different clouds
or on-premises networks.

■ Protect and manage containerized services by using an ingress gateway to apply

API-specific policies to requests from external clients. An ingress gateway helps
define and secure the boundary for services deployed in a container orchestration
platform.

Gartner, Inc. | G00802491 Page 20 of 22

This research note is restricted to the personal use of hoanx@[Link].

 ■ Choose lightweight API gateways when you need to deploy and manage your own
gateways on-premises or in self-managed cloud infrastructure (containers or VMs)
to minimize operational overhead. Lightweight API gateways are also well-suited for
governing internal APIs or domain-specific APIs that demand their own gateway
instances for better isolation and customization.

■ Integrate your APIM platforms or services with your enterprise IAM tools rather than
using the APIM’s native identity provider. This approach not only ensures long-term
compliance with your enterprise security and identity federation policies, but also
reduces vendor lock-in.

Related Architecture Research

■ When to Use a Service Mesh in Cloud-Native Architectures

■ Decision Point for Mediating API and Microservices Communication

■ Comparing Architectures for Hybrid and Multicloud API Management

■ How to Evaluate API Management Solutions

■ Market Guide for API Gateways

■ Architect a Modern API Access Control Strategy

■ Reference Architecture Brief: Cloud-Native Application Architecture

■ Reference Architecture Brief: Event-Driven Application Architecture

■ Reference Architecture Brief: Microservices Architecture Delivery Platform

■ Reference Architecture Brief: Software Observability

■ Reference Model for API Management Solutions

■ Leverage API Portals for Successful API Adoption

■ Critical Capabilities for API Management

Recommended by the Author

Some documents may not be available as part of your current Gartner subscription.

Decision Point for Mediating API and Microservices Communication

Gartner, Inc. | G00802491 Page 21 of 22

This research note is restricted to the personal use of hoanx@[Link].

 Comparing Architectures for Hybrid and Multicloud API Management
How to Evaluate API Management Solutions
How to Deliver Sustainable APIs

© 2025 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of
Gartner, Inc. and its affiliates. This publication may not be reproduced or distributed in any form
without Gartner's prior written permission. It consists of the opinions of Gartner's research
organization, which should not be construed as statements of fact. While the information contained in
this publication has been obtained from sources believed to be reliable, Gartner disclaims all warranties
as to the accuracy, completeness or adequacy of such information. Although Gartner research may
address legal and financial issues, Gartner does not provide legal or investment advice and its research
should not be construed or used as such. Your access and use of this publication are governed by
Gartner's Usage Policy. Gartner prides itself on its reputation for independence and objectivity. Its
research is produced independently by its research organization without input or influence from any
third party. For further information, see "Guiding Principles on Independence and Objectivity." Gartner
research may not be used as input into or for the training or development of generative artificial
intelligence, machine learning, algorithms, software, or related technologies.

Gartner, Inc. | G00802491 Page 22 of 22

This research note is restricted to the personal use of hoanx@[Link].