How to choose the right API Manager for you

A lot of my customers are currently deciding which API Manager to use in their estate. With so many of them to choose from and a confusion of terminology this is not an easy task. I see RFP with long lists of criteria but I often think that the choice should be based on some other, softer, questions. I'll outline here some of how I help my customers choose which API Manager is right for them.

How useful is an RFP?

I get involved in a lot of RFP ("Request for Proposal") for API Management. Often, they consist of a very long spreadsheet with technical criteria - "does the API Manager support CORS", "Describe what security policies your API Manager supports". All valid questions if you need to know the answer to something very specific. However, often customers are searching for a way to quantify which choice to make. It's only during deployment of the solution that they find the actual nuances of the product.

I've done in-depth analysis of 6 (and growing) API managers that I come across regularly and, not surprisingly, I could answer the average RFP for each of those vendors and they would look pretty much the same. As I was analysing the API Managers, what struck me most was the different ways they implemented the same function. This, to me, seems to be a more important question when considering API Managers.

When is an API Manager not an API Manager...?

When it's an ESB ! (not funny, but true :-)

A lot of API Managers are actually just the vendor's old ESB under-the-hood. The vendors wrapper their ESB with API-focused user interfaces and these UI help create the ESB configuration. 

The above figure shows that the API manager is just configuring the vendors ESB. The API Manager then exposes the API in the API portal. The running API gateway (or ESB as we now know it) sends statistics to an analytics engine and these stats are displayed in an analytics portal.

This wrappering of the old ESB function is done to give simplicity and rigour to the API development process. A consequence of this is that it *should* take less skills than the average ESB developer has to deploy complex APIs. Alongside this skills-reduction also comes less time to create, deploy and manage the APIs.

Essentially, what API Management is doing for us is moving us away from, what was usually, a badly governed, tightly-coupled Web-Service and ESB architecture into a better governed, easier to develop, deploy and secure, REST architecture.

Therefore, one of the criteria that I apply when reviewing API Managers is the simplicity of creating the API.

API Developer or ESB Developer ?

At the end of the day most APIs need some kind of orchestration, aggregation, manipulation or logging done i.e. what an ESB does. It's very rare to find an API that is a pure proxy for a back-end service without any of those being needed. 

Once we've recognised that we still need ESB skills in the API Management domain it then becomes a question of much we need the ESB skills. In my opinion, ideally, we would like to abstract as much of the work away from the ESB developer as possible and keep it as close to the LOB (Line Of Business) as we can. The closer we can keep solution development to the LOB the better the solution is likely to be for the  LOB (so the theory goes - and, personally, I believe that).

This is where a big differentiation occurs between API Managers. Quite a lot of API Managers put a very thin veneer over their underlying ESB. For instance, many of them provide a rudimentary UI that allows the more LOB user to create just the skeleton of the API but, very quickly, the API developer drops into the underlying ESB development tool. At that point, it's back to being an ESB development team and not an API-Management team.

For me, at that point, API Management has lost the plot. If one of the key benefits of being an API Developer is ease of creation of APIs then making me write ESB flows is not what I wanted to be doing. 

A good API-Management product helps avoid repetition of the mistakes we make when writing our ESB estate by abstracting that flow creation into a simple API centric environment where I can re-use code easily, using policies, and then govern the deployed APIs.

What about my current ESB?

Once we recognise that the API Manager gateway is  often an ESB, the natural question to ask is "what do we do with our current ESB"?

It depends. For example, IBM allows their ESB to play nicely with their API Management Platform. This means, for IBM at least, you can reuse the assets you've previously deployed to your IBM Message Broker within their API Management Platform (IBM API Connect). You can expose the HTTP interfaces as REST APIs, secure them at the external API gateway, and advertise them in the IBM API Portal. IBM's message broker is a rarity in this regard. 

Not many ESB/API Management Platforms can do this so easily. If your current ESB doesn't allow such easy integration and you buy a different vendor's API solution, then exposing the ESB services through API proxies is as good as you are going to get. However, don't lose sight of the fact that API Management gateways are just ESBs under the hood—so try not to reproduce function you already have in your ESB.

Security, Security, Security

One of the promises of API-Management is that security is now much-easier. If we consider the standard ESB architecture model (left hand-side of the figure below); a flow would get deployed to an ESB. This ESB lies inside a trusted security zone and a security gateway exposes the flow interfaces through a security gateway, probably lying in a DMZ.

How much ESB work versus security work got done in the Security gateway versus in the back-end ESB was a very conscious decision.

ESB to API-M: architectural similarities and differences

The Right Hand-side of the figure shows the API model. This time it's the API-Gateway that's in the DMZ. This model shows us that the API-developer could potentially be liable for security as well as development. Something that would have been unthinkable not too long ago.

This mix of security logic within API management logic emphasises why a good API Manager needs good, easy to use, policies. The more complex the policy to implement, the more open the solution is to security risks.

I've done reviews of API-Security in my previous blog entries.What I found was that the average API development environment does not support some of the more of the complex security problems which security gateway developers are used to fighting. So, if you rely on your API-Developer to solve your security problems as well, you could be in for a shock. 

Community Support

In an ideal world we would never need help and the whole API cycle would run smoothly. In the real world we all rely on the communities that are working with the same products. How easy the access to these communities and how active or large those communities is extremely important. This does not change with API-Management and I would take it into consideration when choosing my company's API Manager.

Conclusion

I've attempted to show here that API Management Platforms are often Enterprise Service Bus functionality with a simpler API interface layered over the development, security, management and analytics.. 

A major factor in purchasing an API Management solution is just how much it helps us simplify our old ESB mentality or whether it keeps us developing and maintaining an ESB like environment.

This recognition should help us see that the purchasing decision around what API Management Platform to buy has a lot to do with the simplicity of the key elements of API Management:

• ·        Development
• ·        Security
• ·        Management
• ·        Analytics

These are usually not functional requirements that can be analyzed in an RFP, but subtler requirements that can only be worked through with partners who have lots of experience with many API Management Platforms.

.