Migration from IBM Integration Bus to Mulesoft ESB for a large enterprise tech services company
I'm a Senior Project Manager of IT Services at a large enterprise tech services company. What are the key areas to focus on when you need to plan migration from IBM Integration Bus to Mulesoft ESB?
Senior Principal Architect at Invenio Business Solution Pvt Ltd
User
2021-07-12T12:34:19Z
Jul 12, 2021
I was previously part of the Oracle SOA/OSB development team. In my current capacity I architected solutions using MuleSoft Anypoint Platform on cloud / on-premises and hybrid modes and on PCE/RTF on Self Managed Kubernetes and On-premise apart from regular CloudHub Deployment;
I am presuming you already took the decision of going with MuleSoft; Hence I wouldn't be dwelling on why migration;
I would be considering the following things:
1. ESB to API led connectivity: -- it would be a paradigm shift since its a layered approach w.r.t. the services System/ Process and Experience layers; If you are re-writing the whole stuff at a time that's one way but considering the business continuity that might not be a practical approach.
2. Deployment -- Cloud / On-Premises / Hybrid;
3. What is the type of deployment: Naked Mule / Runtime Fabric / Pure Cloud with CloudHub
4. If on Runtime Fabric -- is it self managed Kubernetes over AWS / Azure / GKE?
5. How are my previous integrations? -- Is it Monolithic? -- You need to consider the Strangler pattern to move -- start migrating few services first and the rest of them later so that you don't lose business continuity.
6. If yes, how do I break it down? -- What are business-critical systems -- how do you take care of them?
7. What is my Database / If I am moving to Microservices
-- how do I take care of a single monolithic database -- What pattern would I be using -- Shared Database per service?
-- If you have multiple data sources how would you take care? -- Like CQRS pattern?
8. Traditional ESB takes care of Transactions -- but in Microservices led world the services would be lightweight and less dependent and have disparate data sources -- you might need SAGA + CQRS patterns based on how are you managing the data.
9. Security: You need to consider based on deployment model and other deployment criteria security at different levels -- Infrastructure level i.e. firewall / Load balance level for DDoS, IP Whitelisting etc.. whereas at the API level you might look at Rate limiting / Client Id etc.. and At the Organization level you might go for SSO / OAuth with JWT tokens.
10. Microservices Architecture requires Message Queues for loose coupling -- on CloudHub you might have Anypoint MQ but in other cases you might need Active MQ or some other mechanism.
11. Batch Processes with Chron Jobs are another issue that you need to take care of. If you don't plan them properly they can eat up your CPU because they need a lot of memory. Since 4.x later streaming is supported -- orchestrate your Batch Jobs carefully
12. Transformations in Dataweave: This is another tricky thing -- if you have all your business logic here it would make your integrations non-portable-
13. Business Rule Engine Integration: -- Mule doesn't come with a BRE integrated so you have to use 3rd party BRE like Drools or Groovy-based Rule engine etc.
14. Work Flows: Mule doesn't have any workflow support that requires human intervention. hence you might look at something like Activity or Flowable or Apache Airflow to integrate a few of your scenarios.
We performed a comparison between IBM Integration Bus and Mule ESB based on our users’ reviews in five categories. After reading all of the collected data, you can find our conclusion below.
Ease of Deployment: Most IBM Integration Bus users report the initial setup to be straightforward, as do all Mule ESB reviewers.
Features: Users of both products are happy with their performance, stability, and scalability. IBM Integration Bus users say it is easy to use and flexible. Several...
I was previously part of the Oracle SOA/OSB development team. In my current capacity I architected solutions using MuleSoft Anypoint Platform on cloud / on-premises and hybrid modes and on PCE/RTF on Self Managed Kubernetes and On-premise apart from regular CloudHub Deployment;
I am presuming you already took the decision of going with MuleSoft; Hence I wouldn't be dwelling on why migration;
I would be considering the following things:
1. ESB to API led connectivity: -- it would be a paradigm shift since its a layered approach w.r.t. the services System/ Process and Experience layers; If you are re-writing the whole stuff at a time that's one way but considering the business continuity that might not be a practical approach.
2. Deployment -- Cloud / On-Premises / Hybrid;
3. What is the type of deployment: Naked Mule / Runtime Fabric / Pure Cloud with CloudHub
4. If on Runtime Fabric -- is it self managed Kubernetes over AWS / Azure / GKE?
5. How are my previous integrations? -- Is it Monolithic? -- You need to consider the Strangler pattern to move -- start migrating few services first and the rest of them later so that you don't lose business continuity.
6. If yes, how do I break it down? -- What are business-critical systems -- how do you take care of them?
7. What is my Database / If I am moving to Microservices
-- how do I take care of a single monolithic database -- What pattern would I be using -- Shared Database per service?
-- If you have multiple data sources how would you take care? -- Like CQRS pattern?
8. Traditional ESB takes care of Transactions -- but in Microservices led world the services would be lightweight and less dependent and have disparate data sources -- you might need SAGA + CQRS patterns based on how are you managing the data.
9. Security: You need to consider based on deployment model and other deployment criteria security at different levels -- Infrastructure level i.e. firewall / Load balance level for DDoS, IP Whitelisting etc.. whereas at the API level you might look at Rate limiting / Client Id etc.. and At the Organization level you might go for SSO / OAuth with JWT tokens.
10. Microservices Architecture requires Message Queues for loose coupling -- on CloudHub you might have Anypoint MQ but in other cases you might need Active MQ or some other mechanism.
11. Batch Processes with Chron Jobs are another issue that you need to take care of. If you don't plan them properly they can eat up your CPU because they need a lot of memory. Since 4.x later streaming is supported -- orchestrate your Batch Jobs carefully
12. Transformations in Dataweave: This is another tricky thing -- if you have all your business logic here it would make your integrations non-portable-
13. Business Rule Engine Integration: -- Mule doesn't come with a BRE integrated so you have to use 3rd party BRE like Drools or Groovy-based Rule engine etc.
14. Work Flows: Mule doesn't have any workflow support that requires human intervention. hence you might look at something like Activity or Flowable or Apache Airflow to integrate a few of your scenarios.
I have the same question.