API Management Everywhere: Apigee and Pivotal Cloud Foundry

AnantCarlosEdJeff

May 12, 2016

APIs are everywhere, so, by definition, API management should be everywhere, too. Ed Anuff, Apigee’s head of product strategy (and a contributor to this post), talks about how the in “A” in APIs stands for “application,” and how APIs are the way new code connects to existing apps.

Consequently, one can think of APIs as connecting front ends to apps, apps to backends, third parties to apps, internal apps to apps, and, if one explodes an app, then APIs are even inside the app itself, in connections between microservices:

A consequence of this explosion of APIs is that they exist in multiple locations and on multiple platforms. Our view is that a heterogeneous API management layer (such as Apigee’s) is ideally suited to manage all of these APIs.

Making API management seamless

Apigee has long been employed to manage heterogeneous APIs. For someone writing a new app in one of these clouds, this means logging in to Apigee, creating the right sets of API management policies against the APIs behind the new app, and configuring the requests to the app to be routed through Apigee. It all works beautifully, but it does require the app developer to learn the Apigee way of doing things.

But what if we could make adding API management seamless in the context of where the app is being built—say, in Cloud Foundry? For this to happen:

The app developer should not have to login to Apigee, or use an Apigee console (this creates unnecessary friction); API management capabilities should be easy to add with configuration files, for example.

Routing to the Apigee layer—and routing back from the Apigee layer—should be transparent.

We set about doing the former by eating our own dog food. Not only does Apigee manage an app’s APIs, it has its own management APIs, which enable all Apigee functions to be invoked through APIs. This makes it completely headless (you don't need the Apigee UI to complete any Apigee function), and embeddable in any other environment.

For the latter requirement, we have to depend on the environment providing the right sets of routing capabilities.

Helping developers focus on building apps

That brings us to Pivotal Cloud Foundry. PCF, which recently has enjoyed a significant increase in popularity with companies that choose to create their own private clouds, enables developers to focus on writing their apps. The details of operational scaling and the underlying infrastructure are abstracted away.

Developers use a command line to simply “push” their app to PCF. They also have access to many third-party services via the PCF Service Broker API. Below, we highlight a clean mechanism for adding API management functionality to any API call for applications running on PCF.

If you’re a developer, you assume that someone has already used PCF’s BOSH module to create an environment for you. You are then handed control of an org in which you deploy your application. Now you’re ready to leverage the PCF Service Broker API, to invoke the many third-party services your app needs.

Introducing API management to a PCF app

Apigee Edge is now available as a service that is invoked from the Service Broker API. You can introduce API management to a PCF app in two easy steps (assuming that an administrator has already registered Apigee to the Service Broker API).

First, through the Apigee Edge Service Broker, a developer creates an instance of an Apigee Edge proxy (and associated policies, in an Apigee org) that’s scoped to the developer’s PCF org. The app developer does not have to touch the Apigee console or interface in any way.

Then, the developer uses PCF’s Route Service feature to redirect all inbound API traffic to Apigee. Apigee Edge processes the API call by executing the relevant policies, and eventually invokes the original target of the PCF API.