October 8th, 2012

Define Your Own API Management Deployment Model

Category API Management
 

API Management platforms come in different shapes and sizes: cloud-based infrastructure, on-premise infrastructure, multi-tenant SaaS, single-provider portals, API ecosystems etc. For this third part in a series of posts on API Management deployment models, let’s look at some of the considerations in choosing the right approach for your API Management project.

Let’s Start With the Data
Assuming the data of the target APIs already exists, where is that data living? If the data does not exist, are there constraints as to where it can reside (certification requirements, legal obligations etc)? Bridging this data to the external world will require some level of security at the perimeter of the existing data zone, regardless of where or how the rest of the API Management infrastructure is deployed. In that case, the infrastructure model is at least part of the solution. Conversely, if the data does not exist yet and/or can freely exist in a public zone, the hosted API Management model is a great alternative. Ideally, the data or backend is located in the “same” public zone. This may seem obvious but if the same zone is not hosting both API Management and backend, you do not realize the full benefit. Backend as a service can be considered as part of the platform, especially for public deployments.
As Leif concludes in his post Do You Need MBaaS to be a Mobile Bad Ass Developer?, enterprise-focused APIs benefit less from MBaaS because the backend is too often tied to the enterprise zone.

Despite the advantages of a “near API Management”, many API providers require high degrees of elasticity, to handle seasonal peaks for example. Public providers deliver effective ways to accommodate such traffic characteristics. You want your cake and eat too? When data can be governed privately and pushed to public-side cache, API backend management is coordinated at the perimeter of each zone, to allow you to scale across multiple regions.

What About Identities?
Identity-related information is of particular sensitivity, which often makes it better suited for private. Even in situations where the data returned by APIs is effectively hosted, the authentication of subscribers can continue to involve an on-premise component. Done right, this means your API Management infrastructure will need to enable access control that accommodates federation across these zones.

OAuth accommodates this in many ways. One can decouple the OAuth authorization server closer to the source of the identity and the OAuth resource server closer to the API data. Another approach is to implement the OAuth implementation fully in each zone and delegate authentication across zones, using a federated authentication API.

The identities that applications will consume your API on behalf of may also be provided by a third party. Trends like social login and standards like OpenID Connect will enable this federated authentication to not only go across zones but integrate with social identity providers and enable a more social user experience. When building out your API Management infrastructure, be an OAuth hero, not a security zero.

Which Ecosystem?
Creating visibility for an API by joining an API ecosystem can also be a motivating factor in selecting an API Management platform. I would argue that the Internet is the ecosystem and that maintaining ownership of your own APIs and their infrastructure does not preclude you from reaching out to your target developer audience. An API marketplace may help provide the visibility you are looking for but the complete API management infrastructure will still have touch points to multiple zones, whether public or private.

In the end, there is no one-size-fits-all API Management deployment model and many considerations are relevant to design. This post does not claim to be an exhaustive list of such considerations. I’ve touched other obvious ones such as security and cost in the first and second parts of this series. Also, I will be describing this hybrid model in more detail at Cloud Security Alliance Congress when I give a presentation titled Seasonal Burst Handling Using Hybrid Cloud Infrastructure.

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment