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.
#APIConnect#apigovernance#APImanagement#APIsecurity#APIstrategy#APIConnect#apimgt#architecture#GettingStarted#governance#ibmapimgt#MuleSoft#ProductCapabilities#rest#soap#TechnicalStrategy