Senior Principal Architect at Invenio Business Solution Pvt Ltd
User
2021-07-13T02:52:19Z
Jul 13, 2021
I was previously part of the Oracle SOA/OSB development team. I was putting the product onto Cloud as SOACS. 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;
Integraiton is always a heavy one not like applilcation development as you are trying to make disparate systems to work together seamlessly. There are different kinds of solutions based on Traditional SOA, ESB which are heavy/monolithic but proven w.r.t. transaction management/coherent closed integrations which work; -- Oracle SOA/OSB or
The monolithic solutions are evolving into Microservices for agility, management and for giving more freedom to the individual business units to explore and innovate as time to market is the most imporant factor in the modern world.
I would consider the following when I am evaluating the platform:
1. What is the business use case?
-- Is it standard integration file/FTP, Batch and Dataload kind of stuff or
-- Business Transformation from legacy to Modern?
-- What is the future I am projecting?
2. What is the feature set for the product I am looking at?
-- This is driven by point no 1;
-- Do I need low code platform -- these are costly like Mule Anypoint Platform
3. Would the open-source solutions fit my bill like Spring Integration with VMware Tanzu or Apache Camel as RedHat Fuse etc.. -- These would bring down the TCO greatly when you compare them with MuleSoft Anypoint Platform or Oracle SOACS or Oracle OIC etc.. But the trade-off is you need to spend time more in development and managing your code. (What I observed in practice is Managing the code once the solutions stabilize will be almost the same on both)
4. What is my budget?
5. What kind of resources do I have?
-- What time I can give them to ramp up w.r.t. technology
-- Quality of the Resources.
6. What are the kinds of protocols I am talking about?
-- Transport -- HTTP/Websockets/FTP etc..
-- Data protocols -- Database/SAP/Salesforce
-- OOB support for Adapters I am looking for
7. Need for HA / DR
-- will my IT team be maintaining this or the PaaS provider can take care of it?
-- does my product support the same?
8. What is the RPO/RTO I can afford?
9. Does the solution require Distributed Transactions or can I close it with Microservices with SEDA / CQRS patterns?
10. If legacy to modern -- and I am choosing transformation -- does my platform/solution support business continuity in the journey of transformation?
11. Need for securing the solutions/services along with the need for RBAC etc.
Search for a product comparison in Integration Platform as a Service (iPaaS)
Consulting Software Engineer at Singhpora Consulting
Real User
Top 10
2021-01-28T14:03:40Z
Jan 28, 2021
Total cost of ownership - identify how much the platform costs to run for a given volume of messages/requests or data per unit time.
Secondly, identify how much would it cost to develop and deliver actual functionality on the platform (typically involves data flows, integration flows, message transformations, unit tests, deployment scripts etc.). Developers tend to be highly skilled on particular platforms but many can transfer skills easily. Generally, Java developers could work well with iPaaS platforms like Mulesoft or similar (e.g. an Apache Camel or Spring boot variant provisioned on a cloud platform) whereas adopting Oracle Integration cloud could take some transition unless they already work with Oracle products.
Thirdly, it helps to know what the customer's existing environment consists of - for instance, if it heavily uses Oracle products, then Oracle Integration Cloud (OIC iPaaS) might be the most suitable. Generally, developers with experience on other Oracle technologies and experience of working with Oracle support should ramp up very quickly on this. OIC is also very easy to provision and has predictable costs for generous message allowances.
In terms of features, most integration platforms offer the standard types of connectors (http Rest/SOAP, file, ftp, databases, message queues, plus a range of other connectors to somewhat ease integration with various cloud or in-house products), message transformation tools (like XSL, XQuery, XPath), and means to expose callable services like Rest or SOAP. Although principles are the same, it takes some time to ramp up developer productivity on the specific platform of choice. The actual runtime performance on any platform will depend on both iPaaS platform's quality AND how well the actual applications developed to run on it cater to non-functional requirements (like scalability, concurrency, response time, throughput, etc. etc.)
What is iPaaS? Due to the growing need for reliable and secure digital transformation strategies, organizations have begun to adopt cloud integration solutions such as iPaaS, or Integration Platform as a Service.
I was previously part of the Oracle SOA/OSB development team. I was putting the product onto Cloud as SOACS. 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;
Integraiton is always a heavy one not like applilcation development as you are trying to make disparate systems to work together seamlessly. There are different kinds of solutions based on Traditional SOA, ESB which are heavy/monolithic but proven w.r.t. transaction management/coherent closed integrations which work; -- Oracle SOA/OSB or
The monolithic solutions are evolving into Microservices for agility, management and for giving more freedom to the individual business units to explore and innovate as time to market is the most imporant factor in the modern world.
I would consider the following when I am evaluating the platform:
1. What is the business use case?
-- Is it standard integration file/FTP, Batch and Dataload kind of stuff or
-- Business Transformation from legacy to Modern?
-- What is the future I am projecting?
2. What is the feature set for the product I am looking at?
-- This is driven by point no 1;
-- Do I need low code platform -- these are costly like Mule Anypoint Platform
3. Would the open-source solutions fit my bill like Spring Integration with VMware Tanzu or Apache Camel as RedHat Fuse etc.. -- These would bring down the TCO greatly when you compare them with MuleSoft Anypoint Platform or Oracle SOACS or Oracle OIC etc.. But the trade-off is you need to spend time more in development and managing your code. (What I observed in practice is Managing the code once the solutions stabilize will be almost the same on both)
4. What is my budget?
5. What kind of resources do I have?
-- What time I can give them to ramp up w.r.t. technology
-- Quality of the Resources.
6. What are the kinds of protocols I am talking about?
-- Transport -- HTTP/Websockets/FTP etc..
-- Data protocols -- Database/SAP/Salesforce
-- OOB support for Adapters I am looking for
7. Need for HA / DR
-- will my IT team be maintaining this or the PaaS provider can take care of it?
-- does my product support the same?
8. What is the RPO/RTO I can afford?
9. Does the solution require Distributed Transactions or can I close it with Microservices with SEDA / CQRS patterns?
10. If legacy to modern -- and I am choosing transformation -- does my platform/solution support business continuity in the journey of transformation?
11. Need for securing the solutions/services along with the need for RBAC etc.
Total cost of ownership - identify how much the platform costs to run for a given volume of messages/requests or data per unit time.
Secondly, identify how much would it cost to develop and deliver actual functionality on the platform (typically involves data flows, integration flows, message transformations, unit tests, deployment scripts etc.). Developers tend to be highly skilled on particular platforms but many can transfer skills easily. Generally, Java developers could work well with iPaaS platforms like Mulesoft or similar (e.g. an Apache Camel or Spring boot variant provisioned on a cloud platform) whereas adopting Oracle Integration cloud could take some transition unless they already work with Oracle products.
Thirdly, it helps to know what the customer's existing environment consists of - for instance, if it heavily uses Oracle products, then Oracle Integration Cloud (OIC iPaaS) might be the most suitable. Generally, developers with experience on other Oracle technologies and experience of working with Oracle support should ramp up very quickly on this. OIC is also very easy to provision and has predictable costs for generous message allowances.
In terms of features, most integration platforms offer the standard types of connectors (http Rest/SOAP, file, ftp, databases, message queues, plus a range of other connectors to somewhat ease integration with various cloud or in-house products), message transformation tools (like XSL, XQuery, XPath), and means to expose callable services like Rest or SOAP. Although principles are the same, it takes some time to ramp up developer productivity on the specific platform of choice. The actual runtime performance on any platform will depend on both iPaaS platform's quality AND how well the actual applications developed to run on it cater to non-functional requirements (like scalability, concurrency, response time, throughput, etc. etc.)
Self-service
The ability of dev teams to subscribe, configure, test and then publish
The ability of consumers to subscribe
The ability to manage subscribers API keys
The ability to produce usage reports and get feedback