Apigee Provider Interaction

Problemg

Apigee was chosen as the external gateway and portal solution for our program, but its access methods are very different from the way that providers might interact with the proposed shared Delivery Infrastructure. We want to abstract as much as we can away from providers about what technology is chosen and enable self-service as much as possible, but don’t want to water down valuable features from Apigee.

We want providers to:

• Request their APIs to be exposed publibcly, this involves the following actions in Apigee:
  • Create/update an API Spec object
  • Create/update an API proxy with relevant policies — policies drive authorization like rate limits, authn/authz via OAuth, or API keys
  • Create/update an object in the API catalog on the public developer portal
• Be able to create and run reports from the metrics that Apigee gathers
• Create alerting rules from Apigee metrics
• See what consumers are using their APIs and how

Guidelines / Known Constraints

• Ideally, providers should not need to know Apigee concepts.
• The methods of interacting with Apigee should not stand out to providers as different from other aspects of DI. It should be managed the way other components are managed and work with any sign-on providers that other DI components use.
• The current plan for Providers to expose their services to users outside of the DI is a custom object managed by Istio called VirtualService and is documented here.
• We will need some form of governance before an API is allowed to be publicly exposed. What that looks like is TBD. The DI group is planning on implementing Open Policy Agent for decision-making. It may or may not be possible to write all of the policies we'd need to make this fully automated.

Management Options

A Backstage plugin

This option involves our team writing a plugin for Backstage for a provider to either request their API be exposed publicly or to expose it publicly themselves.

There are two sub-types for this option within Backstage:

1. We effectively use this plugin as a ticketing system and have a team behind the scenes managing proxies, API specs, and portal API catalogs on behalf of providers.

2. Backstage interface with a system of record for Apigee configuration — This may be Apigee itself or it could be a separate tracking API. The primary reason that it wouldn't be Apigee is if you cannot use approval processes natively in Apigee.

Both of these sub-types mean that Apigee definitions are not managed alongside all other DI configuration for applications, but are significantly more flexible in terms of what customizations can be made to accommodate different scenarios for various providers.

Sub-type 1 would be the most labor-intensive, but could be used as a stop-gap while working towards sub-type 2 if needed.

A developer group from American Airlines did a talk about their usage of Backstage, which included a few references to how they're using a Backstage plugin for Apigee here. It's unclear which of the two sub-options they used.

Kubernetes Operator

A second option is for us to write a custom Apigee operator for Kubernetes, following the Operator pattern. This is the pattern that Istio and other tools we're already using follows and it fits cleanly into the already-planned developer experience for exposing APIs. It's also the pattern that Kong, Tyk, and other API gateways on the market seem to be headed. The operator does not exist today, but there are frameworks for building operators. Apigee may write one in the future that we could migrate into as well.

Using this model, Apigee has effectively the same relationship to provider developers that Istio (and other Kubernetes components) does — they control it by creating custom objects via the Kubernetes API. From a relationship standpoint, it looks something like this:

Another major consideration to this model is that we have to translate objects from this custom definition format into something that Apigee can ingest before it can be tested. That may cause our team to take more time to develop features than if they were managed using methods that are closer to what Apigee expects.

Monitoring and Metrics Options

Providers are already expected to be using DataDog to view metrics from other services the DI provides, so it would likely make sense for metrics from Apigee proxies to show up there. There's a published integration by DataDog for this available here. This does depend upon the DI using the log management functionality in DataDog. If that's not the solution, we can also send logs to other that service.

That still information about consumers, however. We could explore writing a tool that sends metrics about consumers into DataDog on a regular basis or expose this information through a Backstage plugin that uses Apigee's API.

Alternative to everything in this section, we could also configure SAML via SSOi or some other mechanism and give providers a link in the Backstage interface to use the Apigee UI directly.

Other Considerations

The initial primary interface for the DI starter kits is going to be a CLI tool that the DI team is working on. That CLI tool could also be a candidate to swap out for Backstage in the options listed above (i.e. the CLI could make a request for access or interact with Apigee directly) or it could also help generate the YAML that's picked up by the Apigee Operator.

Additionally, the complexity and consistency of the object types are going to be a big consideration here. Creating a Kubernetes operator that can do everything that Apigee can do is a large undertaking. However, if most proxies or other types of objects look roughly the same with few options to customize, then it's a much lower lift. Apigee also makes use of a NodeJS application running inside the proxy's runtime for a lot of customization. It's likely that we wouldn't want to expose that kind of ability to providers, but it's something to make sure we're considering.

Apigee doesn't have the same type of tooling that we are used to with Kong via decK, but these items can be pieced together:

• https://github.com/apigee/apigeetool-node — a cli tool to manage some aspects of Apigee
• https://github.com/apigee/apigeelint — a linting tool for Apigee proxy bundle definitions and more
• https://github.com/apigee/api-platform-samples — a collection of example proxies, a mix between bash and python tooling to manage and develop them