Define Your Own API Management Deployment Model
API Management Platforms come in different shapes and sizes: cloud based infrastructure, on-premise infrastructure, multi-tenant SaaS, single provider portals, API ecosystems, etc. Let's look at some of the considerations involved 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 on 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
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 are an effective way 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 accommodate federation across these zones.
OAuth accommodates this in many ways. One can decouple 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 zone using a federated authentication API.
The identities that applications will consume your API on behalf of may also be provided by a 3rd 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.
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 that 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 its 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 part of this blog post. Also, I will be describing in more details this hybrid model as part of my upcoming presentation at Cloud Security Alliance Congress titled Seasonal burst handling using hybrid cloud infrastructure.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)