What is our primary use case?
Red Hat Fuse is mostly used for integration, where you have different sets, different APIs: northbound and southbound, and you just integrate them, so Apache Camel and Red Hat Fuse become an ESB container.
What is most valuable?
The features I found most valuable in Red Hat Fuse are the OSB framework, containerization, and the integration of Apache technologies such as the NQ channel, CXF, etc. These are the features that are very prominent in the solution.
Red Hat Fuse also offers flexibility, so it's another valuable characteristic of the solution.
What needs improvement?
What could be improved in Red Hat Fuse is the deployment process because it's still very heavy. It's containerized, but now with Spring Boot and other microservices-related containers, deployment is still very heavy. Red Hat Fuse still has room for improvement in terms of becoming more containerized and more oriented.
As we work with containers, it takes about a minute or so. Red Hat Fuse is much faster than the traditional web application server, but it's much slower than the latest modern technologies such as Spring Boot, so there could still be some improvement there.
Red Hat Fuse also doesn't have a UI navigator and a UI-based workforce filter, and though those are all external, they could help improve Red Hat Fuse.
An additional feature we'd like to see in the next release of Red Hat Fuse is the UI resource wizard that would allow us to easily drag and drop tools. They should have a UI-based wizard where we can just drag and drop connectors, connect them, and do the graphics. We can always do coding for deeper requirements, but having a no-code, local setup in Red Hat Fuse, where we can drag, drop and build our workflows, connection instances, and services, and also design an entire workflow would be a good addition to the solution.
For how long have I used the solution?
I've been using Red Hat Fuse for ten years. It used to be JBoss Fuse before it became Red Hat Fuse.
What do I think about the scalability of the solution?
The scalability of Red Hat Fuse is fine. We didn't encounter any problems with the scalability of the solution. Within the controls of realism and with all the concurrent connections that are allowed, Red Hat Fuse does fairly well. We did some limited automated testing of concurrent pockets which were allowed, and it was pretty decent.
How are customer service and support?
We required the help of the technical support team for Red Hat Fuse for a couple of projects. We had support licenses, particularly the enterprise version. We reached out to their technical support and they responded. On a scale of one to five, with one being bad and five being excellent, I'm rating support a four.
Which solution did I use previously and why did I switch?
We've worked with IBM Integration Bus, and switching over to Red Hat Fuse depends on the customers and their preferences. One of the reasons for switching is that being open source has a bigger advantage, especially because you just need support licenses to move to the enterprise version, and won't really need to get enterprise level licenses. That made Red Hat Fuse more affordable versus IBM or any other ESB tool.
Another reason for switching is Red Hat Fuse is built over Apache technology, so it is very well supported. Camel CXS and other similar solutions are pretty well known and there's lot of community support or developer support around those products.
As containers are built on top of products such as Red Hat Fuse, the solution also becomes very usable.
How was the initial setup?
The initial setup for Red Hat Fuse was a little bit complex, especially when compared with Spring Boot. Though there was a little bit of complexity involved during the setup of Red Hat Fuse, it was still manageable. The setup for the solution was okay.
What about the implementation team?
We did a generic deployment for Red Hat Fuse in-house. We didn't use a third party for deployment, but I'm not sure if we'll need to work with one if we have to deploy the solution in a microservice architecture with one service per container, or how we'll go about doing it. That is something that we never figured out, but now that there's a requirement for deploying Red Hat Fuse in a microservice architecture which is something that we have not seen so far, we have to decide on how we'll go about it.
What was our ROI?
Our customers have seen ROI from Red Hat Fuse. We deployed the solution for our customers, and they've experienced a reduction in their total cost of ownership of Red Hat Fuse.
What's my experience with pricing, setup cost, and licensing?
My company pays for the license of Red Hat Fuse yearly. At the end of the day, it's a low-cost solution, and its support licenses are still very decently priced versus bigger operators such as IBM, etc. Red Hat Fuse is much more affordable than other solutions. On a scale of one to five, with one being cheap and five being extremely expensive, I'm rating its pricing a one.
What other advice do I have?
My company is using multiple versions of Red Hat Fuse for multiple customers.
My company provides Red Hat Fuse services to customers. At least four or five customers use it. As for the maintenance of the solution, once it is in production, only one person is required to handle maintenance. It depends on the SLA, but Red Hat Fuse is not that maintenance-heavy. It doesn't require much maintenance.
I'm recommending Red Hat Fuse to others because it's affordable and it's built on top of technology that is pretty popular and well supported.
I'm rating Red Hat Fuse eight out of ten. It's resourceful, has a pretty decent performance, is built on popular technology, and it's very affordable.
My company is both a customer and an integration partner of Red Hat Fuse.
Which deployment model are you using for this solution?
On-premises
*Disclosure: My company has a business relationship with this vendor other than being a customer: customer/partner
