Welcome!

Francois Lascelles

Subscribe to Francois Lascelles: eMailAlertsEmail Alerts
Get Francois Lascelles via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, SaaS Journal, Telecom Innovation, Java in the Cloud

Blog Feed Post

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. In this 3rd part on API management deployment models, lets 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 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 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 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.

Image

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.

 Image

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.

Image

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.

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 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.


Read the original blog entry...

More Stories By Francois Lascelles

As Layer 7’s Chief Architect, Francois Lascelles guides the solutions architecture team and aligns product evolution with field trends. Francois joined Layer 7 in the company’s infancy – contributing as the first developer and designing the foundation of Layer 7’s Gateway technology. Now in a field-facing role, Francois helps enterprise architects apply the latest standards and patterns. Francois is a regular blogger and speaker and is also co-author of Service-Oriented Infrastructure: On-Premise and in the Cloud, published by Prentice Hall. Francois holds a Bachelor of Engineering degree from Ecole Polytechnique de Montreal and a black belt in OAuth. Follow Francois on Twitter: @flascelles