Many of our customers are currently deciding which API Management Platform to use in their organization. With so many of them to choose from and a confusion of terminology, this is not an easy task.
I see RFPs 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 thought processes I use to help our customers choose which API Platform is right for them.
How Useful is an RFP?
I get involved in a lot of RFPs ("Request for Proposals") for API Management. Often, they consist of very long spreadsheets with technical criteria, including items like: "Does the API Manager support CORS" or "Describe what security policies your API Manager supports." These are all valid questions if you need to know the answer to something very specific.
However, often organizations are searching for a way to quantify which choice to make. Often, it's only during deployment of the solution that they discover the actual nuances of the product.
I've completed an in-depth analysis of six (and growing) top API Management Platforms that I come across regularly and (not surprisingly) the RFP responses for each of those vendors would look pretty much the same.
As I was analyzing these solutions, what struck me most was the different ways they addressed the same function. This, to me, seems to be a more important question when considering API platforms.
When is an API Management Platform Not an API Management Platform?
When it's an ESB! (Not funny, but true :-) )
Many API Management Platforms are actually just the vendor's old ESB under-the-hood. The vendors wrap their ESB with API-focused user interfaces, and these UIs help create the ESB configuration.
The above figure shows that the API Platform is just configuring the vendor’s ESB. It 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 “wrapping” of the old ESB function is done to give simplicity and rigor to the API development process. A consequence of this is that it *should* require less skills than the average ESB developer has available to deploy complex APIs. Alongside the reduction in skills required also comes less time needed 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 Management Platforms 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 completed (i.e. what an ESB does). It's very rare to find an API that is a pure proxy for a backend service without any of those being needed.
Once we've recognized that we still need ESB skills in the API Management domain it then becomes a question of how much we need 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 Line of Business (LOB) 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 I believe that).
This is where a big differentiation occurs between API Management Platforms. Many of these solutions put a very thin veneer over their underlying ESB. For instance, many of them provide a rudimentary UI that allows the 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 in the hands of 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 Platform 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 reuse code easily using policies and then govern the deployed APIs.
What About my Current ESB?
Once we recognize that the API Management 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 gets done in the security gateway versus in the backend ESB is a very conscious decision.
ESB to API Management: architectural similarities and differences
The right-hand side of the figure shows the API Management model. In this case, 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 emphasizes why a good API Management solution needs good, easy to use, policies. The more complex the policy to implement, the more open the solution is to security risks.
I've completed reviews of API Security in my previous blog entries, and I found that the average API development environment does not support some of the more of the complex security problems which security gateway developers are accustomed to fighting. So, if you rely on your API developer to solve your security problems as well—you could be in for a shock.
In an ideal world, we would never need help and the whole API lifecycle 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 are extremely important factors. This does not change with APIs and I would take it into consideration when choosing my company's API Management Platform.
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:
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.
About John Hawkins
John Hawkins is the CTO for Lightwell.
He has extensive experience in the middleware and integration stack having worked at IBM, IBM Business Partners and WSO2.
During his time as an IBM MQ architect he led IBM's Cloud strategy and architecture for next generation, Cloud Centric, Messaging.
John is an innovator and naturally "sees the big picture" which he has demonstrated not only through his work at Lightwell and previous roles, but also his large patent portfolio.