My father always said, “use the right tool for the job”. Good advice which when not followed delivers
poor results. But, sometimes it is not quite clear what the right tool to use is. Once we get passed the confusion between APIs, Services, and Microservices, a good question is – what are the decision criteria for using each in an integration architecture?
Before proceeding to this topic, a baseline is required for positioning of APIs, Services, and Microservices. This is still an incredibly popular topic (based on the number of times I am asked to explain it). So, if you need this baseline or a refresh, please review some of the following blogs and videos:
Microservice Application IntegrationsLet’s start with Microservices. Today many applications are being written or existing applications rewritten as a set of microservices. From our baseline we know microservices are an application architecture, not an integration architecture. However, there are two scenarios around microservices where we need to consider connectivity.
- Microservice application internal connectivity
Almost by definition a microservice application will have several microservices included which together form the application. These microservices need to communicate or call each other. In silo applications this would be equivalent to calling subroutines. There is no need to introduce an API layer for security or policy enforcement in this scenario. Direct connectivity between the microservices is all that is required.
- Connectivity between microservice applications
With multiple separate microservice applications that need to call each other, there is an advantage to removing the integration tasks from the microservice implementations to provide separation of concerns. In this case adding APIs and a gateway to manage this connectivity provides this inter-microservice connectivity.
For additional information see:
Microservices and APIs: Defining application Boundaries by Kim Clark.
API or Application Integration?Summarizing the prerequisite reading on APIs and Services, APIs provide consumer orientation (if done well), self-service consumption, security, analytics, and speed to market through “just enough” governance. The business driver is typically revenue rather than cost savings. Services most often supply a provider orientation, with a business focus on driving reuse to obtain cost savings. Services historically were connected via an Enterprise Service Bus (ESB) that provides extensive connectivity capabilities. Recently IBM has re-architected our Application Connect Enterprise product (previously called IBM Integration Bus) which provides an
agile integration tier using smaller integration microservices in more modular integration style than a single ESB.
Many solutions have both an API component and a Service component (or Microservice) with the API providing security, consumability, analytics, etc. and the service providing a standard interface to the back-end systems. The API tier and the ESB or agile integration tier could both supply connectivity. So, the question is where in the architecture should you implement the necessary integration logic? What decision criteria should you use?
[caption id="attachment_10596" align="aligncenter" width="632"]
Sample integration architecture options[/caption]
Assume your consuming application calls an API which needs to obtain information from several back-end systems and return a response. The diagram above shows two of many possible combinations for deploying integration logic in either or both of the API and Application integration tiers.
To keep this simple think about two decision criteria for placement of the integration logic:
- Integration complexity
Complex integration patterns or a complex back-end system that needs to be called, require the integration logic to be in the Application integration tier. In the application tier you can perform complex integration patterns such as sending requests to multiple systems and waiting for only the first system to reply or executing code to perform integration logic. The API tier should perform only simple integrations. There should be no executable code running in an API for both performance and security reasons.
- System of Engagement or System of Record?
Your back-end systems that run your business are your Systems of Record (SoR). These require significant change control because errors can affect the entire operation of the company. Many APIs are created to support Systems of Engagement (SoE) – how you will engage with your customers or partners. The governance for these is “just enough” to enable the speed to market the business desires. Considering your integration logic, which of these governance models best describe what it requires? Is this something that is critical to the business and being used across all channels? Would your business have a severe outage if someone made an error in the integration logic? If so, then the integration logic should be in the application integration tier. However, if this is a new business offering being created, if this is an attempt to innovate or prototype a trial solution, if the key requirement is speed to market and it will not take down your back-end functionality, then the API tier is the correct choice for placement of the integration logic.It is also possible that both answers could be true in which case the integration logic can be split so that the part that is SoR related can be placed in the application integration tier and the SOE logic in the API tier. (This is shown in the right side of the figure above.)
What factors are unimportant? Both API and Application integration support any cloud and / or on-premise deployments. Technology such as REST or SOAP can be handled by either one. Both implementations from IBM are built on a microservices architecture and can scale individual components as required.
Integration logic placement comes down to governance. How does the integration logic need to be governed? And, how do you govern the decision-making process for this to drive to the desired results. Business pressures and schedules can drive bad behaviors causing integration to be placed in the SoE (to meet a deadline) when it should not be there. But alternatively governing everything as an SoR does not allow for the desired speed to market that is one of the primary drivers for many API initiatives. Use the right tool for the job – always listen to your parents.
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#APIEconomy#APImanagement#APIscience#APIsecurity#APIstrategy#APIvsservice#APIConnect#apimgt#apis#architecture#experienceAPIs#ibm#ibmapimgt#Integration#Microservices#MicroservicesArchitecture#service#TechnicalStrategy#think_apis