Earlier I published part 1 of the ESB and API Management positioning in a blog titled, “Why an ESB is not API Management”.  But what if you took all of the API Management functionality that is not in a traditional ESB and added it to the ESB as a single product?  Would that be a good idea? Read on for another installment in our Blog Series: Top 8 API Management Considerations for Winning Digital Strategies.

 

Initially this may seem like a good idea.  A single interface could be used and integration logic from the ESB could be brought forward into the API capabilities.  Certainly having one architectural construct to deal with would be simpler than two, no? (Hint, the answer is “no”.)

 

Let’s take a look at a few scenarios and the architecture to see how this would work.  In a normal IT environment there is a DMZ where security activity occurs prior to entering the trusted zone where the Systems of Record (SoR) live.


So, in this environment, where do you put the combined API Management / ESB product?  If you place this in the DMZ where the security should be, you would also be executing ESB functions in the DMZ.  This can be extremely dangerous as business logic and SoR functionality should not exist in the DMZ for fear of security exposures to these critical assets.  So, the other option is to put the combined product in the trusted zone.  However, this is also not a good idea as the security checks and protection such as rate limiting need to all be handled in the DMZ prior to entering the trusted zone.  So, clearly the runtime for API Management (a gateway) and an ESB need to be in different architectural layers.  The only exception to this would be if all of the traffic for APIs were inside the enterprise with no outside interactions from any source such as web, mobile, partners, etc.  All of which are very common consumers of APIs.  The internal only scenario exists, but the architecture cannot grow with you as you move beyond a few initial use cases.

 

What if there were a single management component that deployed APIs to a gateway and connectivity flows and business logic to an ESB?  This solves the issue of security needing to be in the DMZ while SoR assets must reside in the trusted zone.  The problem with this approach is governance.  What is the lifecycle and management policy that will be implemented by the management layer?

  • Will this be the more controlled governance required to update SoR assets that are running the business? If so, how can APIs
    be created quickly to meet one of the primary drivers for APIs?
  • Perhaps light weight governance can be used so that APIs can be created quickly. However the critical control of changes to back end SoR assets which includes the ESB connectivity might be compromised if they are changed too quickly without proper governance.
  • So, what if two different governance models were implemented in the management layer – a light weight governance for APIs and stronger governance for the ESB and SoR assets? Well yes this works, but the value of a single management layer for API Management and an ESB seems to have gone away.  Now add the people factor to this.  How will you decide which governance model applies to which assets?  Pressure on employees to execute quickly may cause assets to be classified as an API to move through a light weight governance model when they should have been handled as a SoR change.

 


There are fundamental architectural reasons why runtimes for APIs and ESBs are in two different parts of the architecture.  And, equally important there are different governance models that enable APIs to supply the two speed IT benefits that businesses are hoping to achieve.  Be wary of one size fits all solutions to complicated IT issues.  They often don’t fit very well.

 

To understand more about IBM’s thoughts on the API Economy visit the IBM API Economy website.  IBM API Connect is IBM’s complete foundation to Create, Run, Manage, and Secure APIs.  You can find more information about IBM API Connect at the API Connect website.  And you can also experience a trial version of API Connect.

 

If you have questions, please let me know.  Connect with me through comments here or via twitter @Arglick to continue the discussion.

 

 

4 comments on"Is a Combined ESB and API Management a Good Idea?"

  1. I want to learn more about this took

  2. We have a Data Power in the DMZ that we use as a security gateway (subsequently refered to as SGW) and another Data Power in the trusted zone that we use as a light weight ESB. Requests for services coming from within the trusted zone can go to the ESB which then routes the request to the endpoint where the service is implemented. Requests for services coming from the public zone go to the SGW which only goes to the ESB which then routes the endpoint. How does this model translate when we add API Connect to the picture? Do we have an API gateway in each DataPower with ‘wrapper APIs’ that call internal APIs so the internal requests do not have to go into the scary DMZ and the external requests are forced to? Is there a simpler solution?

    • One of the challenges with these blogs is that we try to keep them short which does not allow for dealing with all the combinations and permutations that exist. So, thanks for your question which allows me to expand upon this to cover the situation you have described which is also very common.

      Many IBM customers use Datapower in both the DMZ and trusted zone. The DMZ instance for security and the trusted zone instance sometimes as a light weight ESB and other times as part of the ESB architectural construct providing internal security without going into the DMZ and back from inside the enterprise (a bad practice).

      Let’s take a look at the two scenarios you have described. First is a public zone request coming into the enterprise. Today this hits your SGW (Datapower in the DMZ) and then routes to the internal trusted zone. Many businesses are finding that API Connect can be used in this scenario to create APIs that are more consumable and also provide the necessary security. So, it is possible in most cases to create an API deployed to the API partition (created by API Connect) on your SGW Datapower that can provide this capability and then call directly into the trusted zone ESB. This logically replaces the path through your existing SGW security partition. If additional Datapower security functionality is required, you can use the API to call the existing SGW partition to provide the extra capability and then proceed into the trusted zone. A third option is to leave your existing traffic as is and gradually provide new APIs that you move to as you bring on new consumers and functionality.

      The second scenario is for internal traffic not coming from outside the enterprise. This traffic should not go to the DMZ! So, since you do have a Datapower inside the trusted zone, this can be used to host internal traffic APIs as needed. Again, existing traffic can continue to flow as is today. But if you want the advantages of an API (easier consumption, security, rate limiting, analytics, etc.) API Connect can set up an API partition on the internal trusted Datapower as well. These APIs can be very simple (proxy) to the existing partition or more complicated as necessary.

      It should be noted that the same API Connect implementation can be used to manage all of this.

      I hope this helps, even this could probably be expanded into a longer explanation.

Join The Discussion

Your email address will not be published. Required fields are marked *