The value of federated API management is that it enables the management of multi-cloud and multi-vendor API gateways for a more unified experience for API consumers, making it easier to drive adoption. But how do you achieve federated APIM (also known as universal API management)?
There are three main approaches: proxies, agents, and DIY homebrew. The relative merits and drawbacks are laid out in this blog post. Axway’s Amplify Platform uses lightweight agents to automate discovery, capture, and validation of all APIs into one registry where they can be managed, monitored, and governed, (i.e. one control plane for all your API data planes, or federated APIM).
What exactly are agents, and how do they work within your API ecosystem to provide that universal overview? And more importantly, what value do they bring compared with other API governance frameworks? Read on for an overview of what agents can do and learn how Axway’s Amplify Platform is changing the game for federated API management.
What is an agent?
Amplify Agents are lightweight software applications that either run on your data plane host, or are hosted / embedded with the Amplify platform for certain SaaS-native environments.
They connect your existing API data planes, repositories, and platforms back to Amplify’s management plane. They use the target data planes’ existing APIs to perform important functions like:
- Discovering new elements (Published APIs, Integrations, APIs in dev)
- Provisioning new subscriptions and security credentials on the target system
- Providing traceability of API traffic
- Checking health of the target system
How do agents work?
One question we are often asked is, what do agents actually do?
Agents use the standard APIs of the native API gateway to collect and direct the targeted gateway to perform certain actions.
Not all gateways provide the same level of functionality, hence why federated APIM is so hard to truly achieve. What Axway has done is to map to a core set of capabilities that we can normalize across many vendor’s gateways.
The following table shows an example of functions and how those are mapped against AWS and Azure gateways.
| Function | AWS Gateway | Azure Gateway |
| Traceability | Transactions with API Key associated with Usage Plan | Transactions with Azure Product subscription associated to Credential |
| Discovery | Rest APIs in API Gateway | APIs |
| Managed Application | Usage plan | Create Product |
| Application Registration | Associated API Stage with Usage plan | Associated API with Product |
| Credential | Associate API Key with Usage plan | Associate credential with Product |
| Quota Enforcement | Quotas are attached to a usage plan. | Quota Policy associated to Product |
There are many more functions implemented in our agents, but this gives you an idea of how we can normalize managing multiple different gateways.
Amplify Platform relies primarily on two types of agents, each with their own unique functions:
Discovery Agents automate the process of finding resources deployed in an environment (for example, OAS 3.0, Async, WSDL, etc.), and sending them to the Amplify platform where they will automatically service in the Service Registry.
After they have been published, consumers can subscribe to use the discovered assets, at which point the agent helps to natively provision this subscription in the Gateway, as well as to manage credentials and quota enforcement.
Traceability Agents collect usage, metrics, and data plane transaction metadata and send them to the Amplify platform for additional insights. In the platform, API consumers and API providers gain visibility into the performance and behavior of the assets discovered in the data plane.
For more details, see Axway documentation on deploying agents with Axway CLI.
Why are agents important?
This approach allows development teams the independence to use whatever infrastructure makes the most sense for their purpose. And it is a big deal because it means that developers who are consuming APIs do not have to learn each vendor’s concepts, terminology, or subscriptions specifics. They just need to deal with one experience regardless of where the API was built or deployed.
AWS teams can use the AWS API gateway and Azure can use the Azure gateway… and the list goes on. The value is providing central visibility into all digital assets across the enterprise, without dictating change. Applications are built faster, with less duplication of API interfaces.
Other vendors’ approaches include placing a proxy gateway in the data path, or require editing of existing policies, slowing API performance and introducing unnecessary points of potential failure.
Since the agent resides on the same infrastructure as the gateway, it minimizes performance impact and simplifies installation for cloud-based gateways. Arun Dorairajan gives us a look at how this works in a recent demo:
What agents does Amplify Platform offer?
The problem with agents is that they need to be built on a per vendor basis. This is the hard work that Axway is committed to, and it accounts for our leadership in the federated APIM space.
Our list of supported agents, by category includes (new additions are highlighted in bold as of this publication):
Runtime environments (end-point gateways)
- Axway (V7 Gateway + new Envoy based gateway)
- AWS API Gateway (+ embedded)
- Apigee Edge
- Apigee X (+ embedded)
- Azure API Gateway (+ embedded)
- IBM API Connect
- Kong
- MuleSoft Mule Gateway
- Software AG / WebMethods
Service mesh
Events
- Kafka / Confluent
- Solace (vendor developed)
- Azure Event Hub (+ embedded)
Security discovery solutions
- Graylog (vendor developed)
- Traceable (vendor developed)
Design repositories
(embedded refers to the fact that they do not require any software installation, just the proper cloud credentials)
To give you a sense of how they function and how they make the API developer experience smoother, let’s zoom in briefly on a few of these agents.
Apigee X Embedded Agents: An embedded discovery agent needs to be provided with a Google Project ID, Developer Email Address and Impersonate Service Account (Client email). The agent makes it possible to bring all your APIs from Apigee in less than a minute, and it allows you to get insights into the usage of those APIs.
GitHub Embedded Discovery Agent: The embedded GitHub Agent needs to be provided with a Personal Access Token, File path, Filters, Repository name and Repository Owner. You can now bring all your APIs in from GitHub in less than one minute, and you’ll have the ability to perform compliance validation on APIs during the design phase.
Kafka Agents: Kafka Cluster Agents for Confluent Cloud/Confluent Platform enables discovery of topics (as Async APIs) and collection of consumer metrics. Arun notes we’ve received quite a bit of demand for event-driven API support as well, so these Kafka agents make it possible to discover all your event-driven APIs in a single pane of glass alongside other types.
With these agents managing the interaction with various control/data planes, we can truly tackle the API sprawl problem. And our CLI-based configuration will provide greater automation at the enterprise level.
See also: Six ways to enhance the API developer experience with an API marketplace
What’s next for federated API management?
We are targeting extended environment/infrastructure support, API lifecycle management, and mocking integration. This will provide end-to-end visibility from design through deployment, to operational status, versioning and final deprecation.
Don’t see your data plane agent on the list? Don’t worry, we are allowing customer demand to adjust our roadmap. We also have an SDK that makes it easy to build your own agent.