Ok I have ACE with MQ latest version & AWS API Gateway on my hands to start integration project- Both products will be running on ( AWS ) -  Need some suggestions on how can we use both the products together for the best benefits of client. 

What are the things can be considered while making the decisions on integration solutions - either one should be done in API Gateway alone or with both API Gateway & ACE or with ACE  


------------------------------
Satendra Negi
------------------------------

Hi Satendra,

Without knowing more about your integration project, it's a little difficult to answer in more detail but i'll try to distinguish the 2 products and hopefully that should give some insight.

The AWS API Gateway is a managed service offering by AWS used for creating, securing, maintaining and publishing your APIs (with a bit of monitoring thrown in for good measure). It provides a lot of the features you'd expect in a gateway i.e request throttling, security etc while integrating closely with other AWS services (for example AWS Gateway uses CloudWatch to monitor your APIs, and allows you to set up custom alarms).

ACE (Formally IIB) is an integration platform and ESB that provides extended connectivity across multiple applications and disparate formats and protocols. While it provides the ability to create and expose APIs (with closer integration to IBM API-Connect than AWS API Gateway), it is designed for the more complex integration patterns and will probably sit in a different place in your estate than a Gateway would.

Hope this helps, if you'd like any more information please feel free to get in touch!

------------------------------
Connor Smith
Middleware Integration Consultant
Lightwell
+447500965974
------------------------------

Hi Satendra,
You're effectively asking "what does a modern ESB/microservices architecture look like". That is not an easy question to answer here and depends an awful lot on things like culture, where your services are, what it is your trying to achieve, what do you have today etc. etc. Here's a a link to a rather wordy but good read on this subject: https://www.ibm.com/downloads/cas/J7E0VLDY that may help you have some insights. It focusses on what you are trying to achieve rather than "what's the right solution". Every solution is going to be different - one size does not fit all I'm afraid. most notable in your case will be the balance between where do you do messaging and where do you do HTTP APIs I would suggest.

------------------------------
John Hawkins
------------------------------

Hi Satendra.  I'm assuming that you will be using ACE to build the integration services that get published as APIs.  There is then a general question about whether some logic can be put into the API layer, vs pushed into the integration service.  We've had a best practice for many years that you try to keep that API layer very light - generally without much work in it.  There are a number of reasons for that, but the primary of which is efficiency for the API layer to serve its primary purpose of securing and managing that front door to your solution.  

------------------------------
Tony Curcio
IBM
704-957-6031
------------------------------

I agree with Tony,
the overall best practice across the integration community (not just IBM ;-) is to keep the "front-door" (as Tony puts it so well), as light as possible. The back-end integration layers are then free to handle complexity, scalability, reliability as required. How that back-end integration layer (presumably micro-services in this day and age) is built up and scaled is the subject of the link I referenced.

------------------------------
John Hawkins
------------------------------

Original Message:
Sent: 02-26-2019 09:05 AM
From: Tony Curcio
Subject: App Connect Enterprise With AWS API Gateway

Hi Satendra.  I'm assuming that you will be using ACE to build the integration services that get published as APIs.  There is then a general question about whether some logic can be put into the API layer, vs pushed into the integration service.  We've had a best practice for many years that you try to keep that API layer very light - generally without much work in it.  There are a number of reasons for that, but the primary of which is efficiency for the API layer to serve its primary purpose of securing and managing that front door to your solution.  

------------------------------
Tony Curcio
IBM
704-957-6031
------------------------------