Technology Manager at a consultancy with 1-10 employees
Real User
Top 10
Dec 8, 2025
The downsides of Red Hat Fuse that I encountered were related to the Java virtual machine I worked with, which was Oracle, as the client did not create good services. In the integration, they had many steps with a loop and several bad uses of the integration with many steps and a bad pattern of design. That was the problem, and then I resolved that. The user interface is not good, and it is a very technical tool. In comparison with other tools such as Oracle Integration Cloud or Oracle BPEL, Red Hat Fuse is more complex. However, the integration in low code is more simple because there is the possibility to create services directly in Java and call them at a high level from Apache Camel and expose them with Red Hat Fuse.
Containerization is one key area where the product can improve, but it probably has already improved in JBOS integration. On a few occasions, our company's production team faced an issue with Red Hat Fuse; the screen displayed that the containers had gone down while, in reality, they were running in the background. The user interface and the back-end code were not in sync in the aforementioned situation, which our organization frequently faced while using Red Hat Fuse. But at our company, we were using an older version of Red Hat Fuse in which we faced the issues. From the JBOS end, the product was very frequently changed from Red Hat, and it was difficult for our clients to keep investing money in every upgrade. Six or seven years back, Red Hat Fuse was one of the best solutions.
I haven't experienced the online part of Red Hat Fuse. Red Hat Fuse doesn't have a lot of administrative control like other applications. Using administrative control, the operational user can view the process flow, do improvisation, and analyze where the problem is. Then, they can show it in a real-time, graphical representation. On top of that, they can do additions and generate reports. These are really valuable for business or IT ops purposes that the solution must take care of.
The testing part, specifically when running it in the cloud, could be improved. It's a little bit complex, especially considering its cloud nature. Apache Camel has many components that are challenging as well. For example, Apache Camel K is difficult to test because they are dedicated to cloud infrastructure.
DevOps Engineer at Simple Logic IT Private Limited
Real User
Top 10
Mar 9, 2023
When we access the container, it crashes and then we have to kill that container, restart, and log in again. The solution should work on preventing this. In the next release, I'd like more stability and more security overall.
Principal Solutions Architect at a computer software company with 501-1,000 employees
Real User
Jan 10, 2023
The monitoring experience should be better. I would like the ability to monitor the flows and be able to retrieve runtime information about their execution. The UI could also be improved.
Sr. Enterprise Architect at a tech services company with 501-1,000 employees
Real User
Top 20
Nov 14, 2022
Red Hat Fuse doesn't have UI really. It's a package that is used for development purposes. The UI is coming in place during the development process, you can create a skeleton of your orchestration when using the solution, and it'll generate your code. So basically we can have an ID with a plugin for the solution, and this will generate a skeleton or a simple flow. But of course, it's not enough for real sophisticated implementations, however, it works as a starter. A visualization plugin feature would improve the solution. Perhaps it is less connected to the solution itself, but to another tool that is connected to Red Hat Fuse.
Integration Consultant at a financial services firm with 1,001-5,000 employees
Real User
Jun 17, 2022
In the future, I would like to see more up-to-date documentation and examples from Red Hat Fuse. It is fairly new, so there is not a lot of information on the web about it right now.
There is definitely a bit of a learning curve. We're still on the learning curve now and still trying to figure things out. We might be understaffed to really take advantage of the solution.
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.
My company doesn't have any experience with other messaging tools, so it's difficult to mention what areas could be improved in Red Hat Fuse, but it could be pricing because I find it expensive. An additional feature I'd like to see in the next release of Red Hat Fuse is a better UI to control all configurations better.
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.
Red Hat has the latest, cutting-edge features, but the learning curve is difficult due to its configurations. For the client, it has a good cost, but for developers, it is a bit of a grind. If a new company is doing Red Hat Fuse development for the first time, there is a bit of a learning curve. They will need to spend time on getting some things ready. As its learning curve is quite steep, developer dependency will always be there in the case of a Red Hat Fuse development. This should be improved for developers. There should be some built-in connectors so the grind of the developer can be reduced. Developers for Red Hat Fuse are scarce all over the world and the community is not well-built. That can be a problem for big companies.
Manager at a energy/utilities company with 501-1,000 employees
Real User
Nov 25, 2021
The documentation for Fuse can be improved because, while it is very detailed and extensive, it is not too intuitive for someone that has to deliver some kind of troubleshooting services. In particular, for installation, re-installation, or upgrades, I find that the documentation can be improved. In some cases, resource consumption is an issue. It depends, of course, on the amount of bandwidth, memory, CPU processing power, et cetera, that you have. But time and again, we require more resources. An improvement in this area would be desirable.
Manager of Integration Services at a educational organization with 10,001+ employees
Real User
Nov 9, 2021
The current solution depends heavily on fabric profiles, which we want to disconnect from and be more containerized. This is why we are implementing Kubernetes, whereas now, it is Karaf-based. The initial setup and configuration could be more straightforward. Red Hat is not easy to learn. You can learn it but you sometimes need external expertise to implement solutions.
Systems Architect at a tech services company with 51-200 employees
Real User
Nov 8, 2021
Some of the official Red Hat documentation could be improved a little bit. It was a little difficult to find exactly what I was looking for. I was eventually able to find it. It's there, but it was hard to find. It might help if, in the documentation, there were a comments section or some kind of community input. I might read a page of documentation and not fully understand everything, or it might not quite answer the question I had. If there were a section associated with it where people could discuss the same topic, that might be helpful because somebody else might have already asked the question that I had. We deployed Fuse on JBoss EAP and the user interface could be improved with some type of dashboarding. That would be useful because, when we got it set up, there wasn't anything that we could readily just turn on to monitor its performance. It turned out there actually was, and I eventually found it, but it wasn't quite handy. It would have been really great if, as part of deploying Fuse on JBoss EAP, we could easily get to measuring performance and have the ability to monitor things, without having to dive into configuration or to deploy other stuff.
Red Hat JBoss Fuse is a lightweight, flexible integration platform that enables rapid integration across the extended enterprise - on-premise or in the cloud. JBoss Fuse includes modular integration capabilities, an enterprise service bus (ESB), to unlock information.
The downsides of Red Hat Fuse that I encountered were related to the Java virtual machine I worked with, which was Oracle, as the client did not create good services. In the integration, they had many steps with a loop and several bad uses of the integration with many steps and a bad pattern of design. That was the problem, and then I resolved that. The user interface is not good, and it is a very technical tool. In comparison with other tools such as Oracle Integration Cloud or Oracle BPEL, Red Hat Fuse is more complex. However, the integration in low code is more simple because there is the possibility to create services directly in Java and call them at a high level from Apache Camel and expose them with Red Hat Fuse.
Containerization is one key area where the product can improve, but it probably has already improved in JBOS integration. On a few occasions, our company's production team faced an issue with Red Hat Fuse; the screen displayed that the containers had gone down while, in reality, they were running in the background. The user interface and the back-end code were not in sync in the aforementioned situation, which our organization frequently faced while using Red Hat Fuse. But at our company, we were using an older version of Red Hat Fuse in which we faced the issues. From the JBOS end, the product was very frequently changed from Red Hat, and it was difficult for our clients to keep investing money in every upgrade. Six or seven years back, Red Hat Fuse was one of the best solutions.
I haven't experienced the online part of Red Hat Fuse. Red Hat Fuse doesn't have a lot of administrative control like other applications. Using administrative control, the operational user can view the process flow, do improvisation, and analyze where the problem is. Then, they can show it in a real-time, graphical representation. On top of that, they can do additions and generate reports. These are really valuable for business or IT ops purposes that the solution must take care of.
As a bundle thing, it goes well. The stability of the solution is an area with a shortcoming that needs to be improved.
The testing part, specifically when running it in the cloud, could be improved. It's a little bit complex, especially considering its cloud nature. Apache Camel has many components that are challenging as well. For example, Apache Camel K is difficult to test because they are dedicated to cloud infrastructure.
When we access the container, it crashes and then we have to kill that container, restart, and log in again. The solution should work on preventing this. In the next release, I'd like more stability and more security overall.
The monitoring experience should be better. I would like the ability to monitor the flows and be able to retrieve runtime information about their execution. The UI could also be improved.
Red Hat Fuse doesn't have UI really. It's a package that is used for development purposes. The UI is coming in place during the development process, you can create a skeleton of your orchestration when using the solution, and it'll generate your code. So basically we can have an ID with a plugin for the solution, and this will generate a skeleton or a simple flow. But of course, it's not enough for real sophisticated implementations, however, it works as a starter. A visualization plugin feature would improve the solution. Perhaps it is less connected to the solution itself, but to another tool that is connected to Red Hat Fuse.
The main issue with Red Hat Fuse is the outdated and scattered documentation.
In the future, I would like to see more up-to-date documentation and examples from Red Hat Fuse. It is fairly new, so there is not a lot of information on the web about it right now.
We have not found we are missing any features. While it's a good platform, the pricing is a bit high.
There is definitely a bit of a learning curve. We're still on the learning curve now and still trying to figure things out. We might be understaffed to really take advantage of the solution.
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.
My company doesn't have any experience with other messaging tools, so it's difficult to mention what areas could be improved in Red Hat Fuse, but it could be pricing because I find it expensive. An additional feature I'd like to see in the next release of Red Hat Fuse is a better UI to control all configurations better.
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.
Red Hat has the latest, cutting-edge features, but the learning curve is difficult due to its configurations. For the client, it has a good cost, but for developers, it is a bit of a grind. If a new company is doing Red Hat Fuse development for the first time, there is a bit of a learning curve. They will need to spend time on getting some things ready. As its learning curve is quite steep, developer dependency will always be there in the case of a Red Hat Fuse development. This should be improved for developers. There should be some built-in connectors so the grind of the developer can be reduced. Developers for Red Hat Fuse are scarce all over the world and the community is not well-built. That can be a problem for big companies.
The documentation for Fuse can be improved because, while it is very detailed and extensive, it is not too intuitive for someone that has to deliver some kind of troubleshooting services. In particular, for installation, re-installation, or upgrades, I find that the documentation can be improved. In some cases, resource consumption is an issue. It depends, of course, on the amount of bandwidth, memory, CPU processing power, et cetera, that you have. But time and again, we require more resources. An improvement in this area would be desirable.
The current solution depends heavily on fabric profiles, which we want to disconnect from and be more containerized. This is why we are implementing Kubernetes, whereas now, it is Karaf-based. The initial setup and configuration could be more straightforward. Red Hat is not easy to learn. You can learn it but you sometimes need external expertise to implement solutions.
Some of the official Red Hat documentation could be improved a little bit. It was a little difficult to find exactly what I was looking for. I was eventually able to find it. It's there, but it was hard to find. It might help if, in the documentation, there were a comments section or some kind of community input. I might read a page of documentation and not fully understand everything, or it might not quite answer the question I had. If there were a section associated with it where people could discuss the same topic, that might be helpful because somebody else might have already asked the question that I had. We deployed Fuse on JBoss EAP and the user interface could be improved with some type of dashboarding. That would be useful because, when we got it set up, there wasn't anything that we could readily just turn on to monitor its performance. It turned out there actually was, and I eventually found it, but it wasn't quite handy. It would have been really great if, as part of deploying Fuse on JBoss EAP, we could easily get to measuring performance and have the ability to monitor things, without having to dive into configuration or to deploy other stuff.
Currently, the main point of concern for us is how flexible it is to cater to different requirements. It should be more flexible.
Our clients would like to see the user interface improved so that it is more user-friendly.
The pricing model could be adjusted. The price should be lower.
The web tools need to be updated.