IT Central Station is now PeerSpot: Here's why
Competitor
# Comparisons
Rating
Buyer's Guide
ESB (Enterprise Service Bus)
July 2022
Get our free report covering TIBCO, and other competitors of Information Builders iWay Service Manager. Updated: July 2022.
621,703 professionals have used our research since 2012.

Read reviews of Information Builders iWay Service Manager alternatives and competitors

Kaushal  Kedia - PeerSpot reviewer
Technical Manager at HCL Technologies
Real User
Configurable, doesn't require much coding, and has an automatic load balancing feature, but its development features need improvement
Pros and Cons
  • "One of the features I found most valuable in Red Hat Fuse is that it has a lot of containers so you won't have to worry about load balancing. In the past, there was a cut-off, but nowadays, Red Hat Fuse is moving off of that, so my team is utilizing it the most for load balancing, particularly running goal applications and three to five containers. There's automatic load balancing so you won't have to worry too much. I also found that component-wise, you don't have to do much coding in Red Hat Fuse because everything is configurable, for example, XML-based coding. Coding isn't that difficult. Performance-wise, I also found the solution to be quite good and its processing is quite fast. My team is processing a huge amount of data with the help of Red Hat Fuse."
  • "What needs to be improved in Red Hat Fuse is on the development side because when you use it for development purposes, it lacks a user interface compared to what MuleSoft has, so it's a bit difficult for users."

What is our primary use case?

We are using Red Hat Fuse for integration purposes, in particular, we are using it as an integration layer. It's for connecting through various adopters, for example, web service consumptions and other file-based interactions. Red Hat Fuse gives a lot of capabilities for various integration points. We are using Camel, then along with that solution, we are using Red Hat Fuse for all integrations, mainly for file-based and web-service based interactions, as this is how our projects were designed.

What is most valuable?

One of the features I found most valuable in Red Hat Fuse is that it has a lot of containers so you won't have to worry about load balancing. In the past, there was a cut-off, but nowadays, Red Hat Fuse is moving off of that, so my team is utilizing it the most for load balancing, particularly running goal applications and three to five containers. There's automatic load balancing so you won't have to worry too much.

I also found that component-wise, you don't have to do much coding in Red Hat Fuse because everything is configurable, for example, XML-based coding. Coding isn't that difficult.

Performance-wise, I also found the solution to be quite good and its processing is quite fast. My team is processing a huge amount of data with the help of Red Hat Fuse.

What needs improvement?

What needs to be improved in Red Hat Fuse is on the development side because when you use it for development purposes, it lacks a user interface compared to what MuleSoft has, so it's a bit difficult for users. There are good and bad points in Red Hat Fuse, but mostly the solution has good points.

There's also another similar product in the market: IB Information Builder which is a product that has recently been taken over by TIBCO, and TIBCO has a similar integration product. It's similar to MuleSoft because both TIBCO and MuleSoft have user interfaces on the development side, so if I have to define a route where one particular flow should follow a particular way, for example, service should be consumed from this point, and these are my source and target, I'd be able to do those on MuleSoft and TIBCO more easily, but not in Red Hat Fuse. The development features of Red Hat Fuse need improvement, but I feel the team has done a lot in the latest version, and now Red Hat Fuse will be removed from the market and the focus will be on OpenShift purely. There is also a new product called Red Hat Integration and there will be a movement towards Docker because a major drawback of Red Hat Fuse is that it doesn't have small containers, so every time, you'll need dedicated virtual machines on top of those you're running, but now, it seems Kubernetes will be used.

In the past, in the older version of Red Hat Fuse, you have a full container and the whole application is deployed on containers one, two, and three, so you don't have the option of splitting. It's similar to microservices, but now those things are taken care of in the latest version, and the older version of Red Hat Fuse will come to an end.

An additional feature I'd like to see in Red Hat Fuse is a direct integration, particularly with CI/CD, which can help reduce overhead because you won't need to have a big DevOps team for building, preparation, and deployment. Dockers and microservices support are also additional features I'd like to see in the solution. More successful deployments will also help make Red Hat Fuse better.

For how long have I used the solution?

In the past, I wasn't directly using Red Hat Fuse because I was a technical architect, but the development team and the support team uses it. In the last three and a half years, I've been using Red Hat Fuse. I'm using a version of it that's quite old, so my team is migrating from the Red Hat JBoss Fuse version to  to OpenShift. My team is working on a migration plan.

What do I think about the stability of the solution?

Red Hat Fuse is a stable solution.

What do I think about the scalability of the solution?

Red Hat Fuse is a scalable solution.

How are customer service and support?

The technical support team for Red Hat Fuse is very helpful. I'm rating support a four out of five because the team gives a lot of support. Support is good. Even during migration requests, the support team helps my team, so support-wise, there is no problem.

How was the initial setup?

The initial setup for Red Hat Fuse was difficult. It was a bit complex and it was not as smooth as the initial setup for OpenShift which was very straightforward. On a scale of one to five, with one being the worst and five being the best, my rating for the initial setup, integration, and deployment of Red Hat Fuse is three out of five.

What's my experience with pricing, setup cost, and licensing?

In terms of pricing, Red Hat Fuse is a bit expensive because nowadays, if I'm just comparing it with OpenShift with Kubernetes, so Kubernetes and OpenShift, are similar, and Kubernetes is open source, so Red Hat Fuse is quite expensive in terms of support. I don't know the exact numbers because I don't deal with that area. Commercial teams are different.

I just work on the technical side, but I believe the solution is quite expensive. When you have to secure your production and you need to build confidence though, you cannot directly go for OpenShift or an open-source solution. When my team was planning the migration, in terms of development effort, you need to do the same things for OpenShift and Kubernetes, but if you look at it from a long term perspective, you'll see the support, so my team didn't go with open source and we went with Red Hat Fuse instead. Red Hat Fuse provides value for money because it provides good support. If you want to get something, you need to pay for it. My company is also not product-based as it provides service to clients, so clients need to have confidence in the service or the solution from my company as well, for example, if something happens, there's support from Red Hat, so there's two-layer protection.

Which other solutions did I evaluate?

I evaluated MuleSoft and Information Builder.

What other advice do I have?

There are no direct users for Red Hat Fuse because it's all in the backend systems. I have three applications integrated with the solution. It's a single instance which means there are three clusters against each. There's a total of nine: three applications, three clusters with three nodes each. In a production environment, there's nine, and apart from that, there's four or five against a load environment.

In terms of user roles, I have a development team with twelve developers and a platform development team that handles the deployment and also supports production with three to four people.

My team is planning to move away from Red Hat Fuse, but the next product is from a partnership with Red Hat, particularly with new technology. My team contacted Red Hat and the suggestion was to go for OpenShift for now, and if the team decides to move to the cloud in the future, probably Red Hat has OpenShifted and could provide my team with cloud-based managed services, but for security reasons, my team is not moving to the cloud at the moment, and the Red Hat team was very open in terms of sharing the roadmap which is what my team is following. The Red Hat team was very much updated with the latest technologies and suggested to move to small containers or dockers supported by OpenShift. The Red Hat team has technology for Dockers only and there are some dockers prepared and there are some changes to the base application. My team is getting a lot of support and whatever product Red Hat is launching is also in line with new technologies, so I'm quite happy with Red Hat.

At this time, in my current role, and from the processing side, I don't see any issues with Red Hat Fuse. The only challenge was with its configuration and that it doesn't have a direct integration with the CI/CD, so you need to build different components. Otherwise, everything was good with Red Hat Fuse. For a legacy system, I'm unsure if the solution is compatible with the latest technologies or not, but for me, particularly for my application, the solution works well, so I'm rating Red Hat Fuse seven out of ten overall.

Disclosure: My company has a business relationship with this vendor other than being a customer: partner
Flag as inappropriate
Buyer's Guide
ESB (Enterprise Service Bus)
July 2022
Get our free report covering TIBCO, and other competitors of Information Builders iWay Service Manager. Updated: July 2022.
621,703 professionals have used our research since 2012.