Red Hat Fuse Reviews

Red Hat Fuse serves as our enterprise integration platform. We do use some of the message bus features as well, but it is not the enterprise message bus.

From implementing Red Hat Fuse, we have seen significant improvements and benefits. In the past, we had monolith applications from a quite large vendor. The problem was that we essentially encountered a massive life cycle issue every three years and the investment required was really substantial. Now because of microservices architecture, we can make our own decisions regarding which application needs to be upgraded, either at its life cycle or for feature parity or new features that we are building. The investment is probably tapered down year-on-year instead of having a big shock every three years with a massive investment for upgrade.

Other benefits of microservices architecture include a reduction in the number of issues, and our time to solve problems is pretty high because we do not have to spend a huge amount of time doing regression across applications. We can change one service that is impacting a customer and fix it pretty quickly. In cases where we originally went live with migration, we have done seven fixes in one hour, which is impressive compared to where we were with the previous application.

Red Hat Fuse is open source, so it allows us to modify the software, understand it better, and modify it to our needs. We are not stuck with off-the-shelf features and customization limitations. We can use it the way we want to use it and build our own practices on top of Red Hat's practices. The only drawback is it requires coding, but to compensate for that, we use AI to code at the moment.

The support for microservices architecture in Red Hat Fuse has helped our development team massively. We are moving away from monolith integration applications into microservices architecture. We essentially split one big application into approximately 50 different services, which is probably about 70 now. This was a massive advantage in going with Red Hat Fuse.

The big advantage now is because Red Hat Fuse is open source, we can use AI to fast track development versus some closed applications where the knowledge is quite restricted, making it really hard to use open AI because it is not quite accurate.

Regarding the efficiency gains from Red Hat Fuse's distributed development capabilities, when we flipped from the previous enterprise integration application to Red Hat Fuse, the TCO benefit was about 40 percent. Developer efficiency was very high as well. We fix issues, seven issues in one hour after go-live, because we could do it without having to do massive regression. Development efficiency was probably twofold or at least that much.

There are areas in Red Hat Fuse that have room for improvement. We were recently having a discussion with Red Hat team building agentic AI, which we call AI SDLC. Something that the team is actively working on, but I have not really seen any production-level version of it is MCP. For us to use Red Hat Fuse with AI models, we need MCP so that we can be very confident that it can deliver us a really solid outcome when developers are using it, whether it is any of the integration patterns or messaging bus patterns. I have not seen that yet. Even though Red Hat has an alternative to that, such as a plugin, it is not as advanced as some of the MCPs that we see around.

I have been using Red Hat Fuse for approximately seven to eight years.

I would rate the stability of Red Hat Fuse at ten out of ten. Even when we were doing migration, we had issues, but now it is pretty stable.

I would rate the scalability of Red Hat Fuse at between seven and eight. I am not only looking at scalability just for the physical horizontal scalability of the solution that could scale. I think there are other factors to it, such as developer experience, so that developers can scale it. I think they are probably a little bit under in developer experience. But other than that, it is probably a good product.

I would rate the vendor support of Red Hat Fuse at between eight and nine.

Positive

Back in time, the reason we chose Red Hat Fuse against MuleSoft was a couple of factors. It was open source, so we are heavily reliant on open-source technologies, because it allows us to cater for some of the custom requirements. The second thing was cost.

The process of implementing Red Hat Fuse was not easy, but it was complex enough for a moderately complex project. Migrations are never easy. I had a blog with Red Hat Fuse on this with Red Hat, and I am not sure if it is still on the Red Hat website. The journey that we took was different from what some organizations do. Some organizations have a bunch of people working on the old technology and leave them behind while implementing a brand new system, forcing them to train on the new technology after that. The approach we took was the IP was sitting with those people on the old technology, so we gave them time, about three months, to be trained on the new technology, understand it well, and define the best practices before we started the migration. There was a bunch of learnings out of that. It was not super hard, but it took a year and a half to move all the integration services from one to another.

Red Hat Fuse was a direct purchase.

The implementation of Red Hat Fuse took about a year.

When considering pricing for Red Hat Fuse, this is a pretty interesting question. When you consider cost, it is not just the cost of the software, but also the cost of development, cost of usage, and cost of maintenance. The cost of the software is probably low, but it is not a low-code platform. It requires effort into building something. AI is something we are really passionate about using to build some of Red Hat Fuse offerings, but it is not quite there yet. I am still hopeful, but it is still not quite there. The commercial that you normally get earlier in the time when you sign up is not the commercial that is going to stick around for a long time. We are in the third renewal since we migrated to Red Hat Fuse. Cost always goes up, it does not go down. I am sure it would have been the same thing if we were using any other software as well. I would normally rate Red Hat Fuse about five.

Red Hat Fuse stands out from other products and vendors on the market, but we rarely see a lot of marketing on Red Hat Fuse to be honest. MuleSoft is a popular brand. The marketing that they do is intense, with probably 50 percent of small-medium organizations using MuleSoft. When you say stand out, I think Red Hat probably could do better. Red Hat is a different organization compared to any other commercial organization. It does not stand out as good as MuleSoft.

We do not use Red Hat Fuse to support our DevOps processes or practices.

We have not used the role-based access controls in Red Hat Fuse. We have that control implemented through our own DevOps tooling. It is not a feature that we actually use out of Red Hat Fuse.

There are about 10 to 15 users who use Red Hat Fuse in our organization.

Red Hat Fuse requires maintenance, but it is fairly easy. It requires patching probably every four to five years to the newer libraries that are available or supported. The housekeeping we have done is quite stable. We had challenges in the beginning, but we do not need to actively invest into housekeeping anything as such.

The advice I would give others looking to implement Red Hat Fuse is based on the use cases. If you have the right tools, such as AI SDLC, and good Java development practices, then it is probably a tool for you. One thing with Red Hat Fuse is that most of the applications are implemented on Spring Boot and Java. There are other alternatives, but it is largely Java anyway. If you have really good Java practices, then it is probably a tool for you. Red Hat Fuse does require a lot of hands-on development. It is not a drag-and-drop development solution. Overall, I rate this review at seven out of ten.

My use cases for Red Hat Fuse include using Drools to create a bunch of rules for the Finance Ministry in Chile many years ago. I worked with another enterprise named Aguas Andinas, which is a very big enterprise of water in Chile. They use Red Hat Fuse as their primary site, a Liferay system that connects to Red Hat Fuse and manages all integration.

My role in that project was architect, and the definition of the architecture for integration involved reviewing services and creating a framework for integration. The client contacted me to improve all the integration because the problem was slow performance, which I resolved, and the client currently works with the system in cluster, in high availability.

At that moment, I worked directly with Red Hat.

I worked with VASS, and the client at that time was Aguas Andinas, who currently use Red Hat Fuse.

The benefits of Red Hat Fuse are balanced by the fact that they use it because the integration is very simple. It only requires creating a flow and then putting it in the environment, which is very simple. The creation of services was directly in Java, and all services are called from Apache Camel. Red Hat Fuse was the integration system, and it has many ways for traceability, which is a key point. They also use other tools to see reports and other things, which is part of the architecture. Red Hat Fuse remains very simple.

Regarding stability, Red Hat Fuse works well without lagging, crashing, or downtime.

As for scalability, it works for both small to medium businesses and large corporations. When I create the standalone installation, I work with one instance, but if I configure the cluster, I can put the installation inside a virtual machine or a node of Kubernetes. With that, I have the possibility to improve the whole system in Red Hat Fuse, and it's not a problem.

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.

I have been using Red Hat Fuse for approximately 20 years.

About the quality and speed of the support, if I have a problem with the system associated with the platform, I often need to contact the vendor, for example, Red Hat. In the case of Aguas Andinas, when we created a ticket, the response time was very quick because I live in Chile, where Red Hat has a team.

On a scale from one to ten, I would rate the support for Red Hat Fuse as ten.

The initial deployment of Red Hat Fuse is easy because I need to create a folder.

It's easy because we need to download a JBoss with the information for Red Hat Fuse, and this works without any problem for the creation of the system.

It usually takes me a very quick time to deploy Red Hat Fuse, as it is simple to deploy and manage when I know how the system works. There is no problem with that. The point is that for a new developer, it is not a simple tool.

I think the pricing for Red Hat Fuse is okay; it's not expensive, and the support is good.

Regarding alternatives to Red Hat Fuse, I have used other tools such as Oracle BPEL and Oracle SOA Suite, which include Oracle Service Bus and Oracle Integration Cloud, as well as Mule, ServiceMix, and many other tools. Red Hat Fuse is not simple to connect for a person with no experience in integration because it doesn't offer the possibility to create a service with a pattern. For example, a synchronous pattern is not possible directly in Red Hat Fuse, so you need to create everything from scratch.

The maintenance required on my end, such as updates for example, is simple to use. The tool works well. The unique problem is the interface for creating the flows; that's one issue, but it's not a stopper. If the interface is complex to use, the quantity of developers who can work with it is very small. At that time, I was chief officer in middleware at an enterprise called VASS, where I had a team of around 25 persons, but only about two people had the capability to work in Red Hat Fuse, while the rest of the team was focused on middleware. I would rate this product eight out of ten overall.

Our company used Red Hat Fuse to integrate layers of numerous applications. The solution has also been used in our organization for orchestration purposes of multiple microservices over the years. In our company, we had fuse bundles and interactive domains, and the fuse was the common source where all the abstracted layers and vendor details could be viewed. 

One of the best features of Red Hat Fuse is that one single console is provided for all the applications. The routing system of the product supports Camel routing, which allows programmers to write minimal code. Red Hat Fuse is a good product for developers, deployment teams, and support teams. It's very easy to build a new environment using Red Hat Fuse because most of the processes are already automated using the fuse. 

Presently at our company, we are not giving much value to Red Hat Fuse because better tools have launched in the market. New additional features have arrived in the solution for JBoss integration. 

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 have used Red Hat Fuse. 

Red Hat Fuse is a very stable product. In our company's production environment, processes ran 24/7, multiple APIs were present, and there were a huge number of requests and responses as data was collected from more than two million devices daily; Red Hat Fuse ran in a stable manner even in this environment.   

The product's scalability is quite satisfying. My company was not in production using Red Hat Fuse initially, but once it moved to production, a couple of hundred devices were managed at the start. Soon enough, our company reached the mark of managing 2 million devices for a high-end government project. 

Support from Red Hat has always been satisfying for our company. 

The installation of Red Hat Fuse was quite straightforward in our company. The deployment process is simple enough for the product; you mainly need to reach out to the vendor, and the process can be implemented from the console. The deployment process can also be carried out from the background by utilizing a set of extremely simple scripts. 

I would rate Red Hat Fuse as eight out of ten. When the solution was being used in our organization, the JBoss or Red Hat support was great. The solution was highly stable, robust, and scalable, and our company availed itself of two or three years of extended support even after the product went into End-of-life. 

The product brings value to a company in terms of deployment, orchestration, scalability and robustness.  

Regarding use cases, the solution is not for internal consumption. It is used for our customers. The solution is an Enterprise Service Bus or ESB.

Like any other ESBs, Red Hat Fuse is one of the ESBs, and it particularly comes as a part of a suite of OCP in OpenShift. The entire security can range from containerization and the parts which have been built into the solution.

As a bundle thing, it goes well.

The stability of the solution is an area with a shortcoming that needs to be improved.

I have been using Red Hat Fuse for the last three years.

The solution's stability depends on how it has been configured and what type of applications it's been used for, so I can rate it as an eight out of ten. The solution is not completely UI driven because the command line, configurations, and all of that are still there in the solution.

My company has 3,000 users using the solution.

With a premium, one can get support 24 hours.

The initial setup is not very complex. It is a bit com, but not very complex.

The time for deployment depends upon the availability of the various environments or infrastructures. You can set it up in a day.

Since the setup process is UI based, there is nothing much. The setup process is UI based, and there is nothing much involved in the setup process, owing to which it can just be improved.

The solution can be deployed on-premises and on a cloud.

For the deployments and maintenance, we need around six technically sound people. It is not such that any layman can operate the solution.

You need to pay for the license. It's not free. I'm not aware of the exact prices. There are no extra costs in addition to the standard licensing since it is a subscription-based solution.

I would definitely recommend the solution to those planning to use it.

If anyone is looking for an Enterprise Service Bus solution, then Red Hat Fuse is one of the options. Also, they do have various ESB solutions.

Overall, I rate the solution an eight out of ten.

We have a couple of different interfaces through SOAP, REST, FILE, and Kafka. We receive different inputs from the external interfaces, transform them, and do some kind of enrichment. Finally, we use the routing to publish to downward streams.

The process workflow, where we can orchestrate and design the application by defining different routes, is really useful.

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.

I have been using Red Hat Fuse for three years.

I rate Red Hat Fuse an eight out of ten for stability.

Around 20 users are using Red Hat Fuse in our organization.

I rate Red Hat Fuse a nine out of ten for scalability.

Red Hat Fuse’s initial setup is easy.

Once we release the incident setup, deploying the current version will take three to four days, including the verification.

Red Hat Fuse is currently deployed on-premises in our organization. We have plans to move into the cloud as well.

If you're looking for an enterprise service bus, Red Hat Fuse is one of the platforms on which you can reliably integrate. However, you need to take care of the usability part operationally. It will ensure that the business you ask for has every flexibility.

Overall, I rate Red Hat Fuse an eight out of ten.

Red Hat Fuse is used for communicating and interfacing between systems. It's used for system integration and it's also used for messaging.

What I like about Red Hat Fuse is that it's a well-established integration software. I find all aspects of the tool positive.

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.

I've been using Red Hat Fuse for the last three or four years. I'm still using it.

Red Hat Fuse is a very stable tool, so far.

Red Hat Fuse is a scalable tool.

Support for Red Hat Fuse is very good, and I would rate it a five out of five. I don't have any issues with support.

I found Red Hat Fuse easy to set up. I'm rating its setup a four out of five.

Red Hat Fuse is an expensive tool, though I cannot answer how much it costs as that's confidential.

Five hundred end users utilize Red Hat Fuse in my company.

My rating for Red Hat Fuse is nine out of ten.

The primary use case of this solution is to implement our microservices and refactor our monolith products. Not the environment, but libraries that you can build pretty sophisticated workflows

The most valuable feature is that it's the same as Apache Camel. 

Red Hat Fuse is a Red Hat version of an Open-Source platform called the Budget Camel.

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.

I have been using the solution for two years.

The solution is a Java package so there is no setup.

The solution doesn't have independent licensing. It's a part of the Red Hat integration suite or integration platform for that name. So this platform includes at least until recently, Red Hat 3scale, Red Hat Fuse, and Red Hat AMQ. Three products.

The difference between Red Hat Fuse and Apache Camel is that Apache Camel Open-Source is really not that big, not that much, and the only differentiator which was important for us, is that Red Hat Fuse has enterprise support while Apache Camel doesn't. So in our case, it was important to have enterprise support.

I give the solution an eight out of ten.

The solution is a Red Hat version of the Apache Camel which has been discontinued. The solution will be discontinued in 2024. There are already plans to move to a different product called Camel 3.

There is not that much they can improve with the solution. They're just taking another Apache product and wrapping it up, and branding it as Red Hat, by giving the enterprise support for this version of the Open-Source product.

Michael:

From a version perspective, there is maintenance, When you need to move from one version to another. And this part, usually Red Hat is giving a good heads up and tries not to break compatibility as well. Unless they're changing the versions that are not compatible, of course, some features will not be compatible. But from an information perspective, they're giving a good heads-up and a good explanation.

I am an Integration Consultant. At my company, we are using Red Hat Fuse as our integration suite so we can connect all of our different software components.

Red Hat Fuse is developer friendly. The solution has more tooling and options. Because it is based on existing platforms, it is easy to implement, as you don't need to relearn everything. It is everything I want from a full integration solution.

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.

I have been using Red Hat Fuse for three years.

The solution is relatively stable. It is not as stable as existing solutions from Oracle and IBM, however, Red Hat is fast at releasing patches if there are any concerns.

We have 15 developers in our organization using the solution.

Technical support is responsive. This is one of the product's strengths. They are helpful and willing to work through any problems or questions you may have.

As an example, we had one implementation bug, and they walked us through the steps to resolve it. It was a problem on our end. In another situation, an issue we raised was a bug in their code. They released a patch within a few days.

Positive

Coming from proprietary languages like Oracle and IBM, Red Hat Fuse is more developer friendly. There is more retooling and more options. It is also based on existing platforms, so it's easier to implement.

The initial setup is straightforward compared to other solutions on the market.

Deployment of Red Hat Fuse takes three days to set everything up from scratch.

Red Hat Fuse saved us money. It is a lot easier to license for cloud deployments.

As long as you are a Java developer, Red Hat Fuse is easier to learn than other integration solutions on the market. It's a Java framework first, making it quite easy to pick up and go.

I would rate the product an eight out of 10 overall.

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.

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. 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.

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.

Red Hat Fuse is a stable solution.

Red Hat Fuse is a scalable solution.

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.

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.

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.

I evaluated MuleSoft and Information Builder.

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.

My current project is using OpenShift Container Platform (OCP), which is a container-based application run by Red Hat. We have deployed the Red Hat Fuse and 3scale applications, the API management stuff, and ESB stuff on OCP containers. In my last project, we were using on-prem enterprise systems and applications as well as the container version of Fuse. Now, it is SaaS-based.

It is deployed for our client organizations. 

One of my clients is a postal and telecommunications client. We do some internal systems integrating with them, some scheduled jobs from one system to another system, and data transfers. There are some of the data integrations, postal integrations, and their integrations with different banks on payments. Therefore, we are using Fuse ESB for this. On top of that, we use the 3scale API Management platform, which is also an acquired Red Hat, open-source, SaaS platform for the API management layer. This is basically the use case for data transfers and data transformations from one system to another. In every other project, the use cases are similar in nature.  

For some security layers on systems, we use OpenID. For integrations with banks, we always use SSO-based integrations.

Our client is using the private cloud with its own data center, but interim projects are managed by the client. The services run on 3scale, so the ESB is managed and supported by Red Hat. 

Red Hat Fuse offers hybrid, on-prem, and cloud versions. The cloud version is managed by IBM Cloud, which is well-supported, but you can set your infrastructure in any cloud version, such as GCP or AWS. Basically, Red Hat-managed infrastructure is on IBM Cloud.

Because we have been doing Red Hat Fuse projects for three years, and over time we have matured, we can employ similar use cases and make use of accelerators or templates. It gives us an edge when we deliver these services or APIs quickly. 

Red Hat Fuse is an ESB. The most important feature of any ESB is its connectivity to diverse systems or endpoints. This is one of the key features that every ESB provides. 

We can expose APIs and consume them.

Red Hat Fuse incorporates all the latest ESB features.

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.

I have been using it for three years. At the start of my career, I did an integration on Red Hat Fuse. My current project is also on Red Hat Fuse.

It is stable enough and works on Java. We have implemented Fuse ESB for two or three clients' scenarios, and it is working totally fine. In the case of stability, Fuse ESB is good. 

Scalability depends on the deployment model. If you are implementing it on IBM Cloud or any other cloud, the scalability is easy. In the case where you are using your own data centers or on-prem systems, then you will need to scale the data applications yourself, using local answers. That is also a type of grind on the developer or DevOps team.

Small- to medium-sized companies deploy Fuse in their environments because it is cheap. For example, a giant corporation in America that has a lot of money will not use Fuse services, they will use MuleSoft for their integration. 

In Asia and the Middle East, Red Hat Fuse and IBM are the market leaders. IBM acquired Red Hat, so they have two ESB solutions: an expensive one and a cheap one.

Red Hat gives support for Runtime Fabric. 

In the case of clients, their support should be increased or more enhanced to encourage and attract bigger clients from the market.

The response time is a problem in the case of Red Hat Fuse. Most of the Red Hat Fuse technologies are new to the market. For example, if we take 3scale, the API management product that is also a product of Red Hat, it is missing the API management layer on top of Red Hat Fuse. It is a relatively new product for Red Hat. 

Sometimes, Red Hat engineers do not understand what the problem is and we have to sit with them for hours to detect a problem. Once the infrastructure is on their side, it is their duty to figure out what the problem or issue is, but they are saying that they don't know what the issue is because it is a new product. One of the support members even said, "It's a new product. I don't know what the issue is."

Their support and documentation need to be enhanced. When IBM acquired Red Hat two or three years ago, it improved the documentation. However, the documentation needs further improvement. They need more demos on the Internet and blogs as well as build up a developers' community, where the questions can be answered immediately.

There are some critical issues in the community that have no answers to them. That is why the learning curve is steep. This is where, as a Red Hat Fuse developer, I face problems. I go to the community page and post a question there. But, if I get answers after two or three weeks, then that is a problem for me because of time to market.

I would rate Red Hat's support for Fuse as five or six out of 10.

Neutral

The initial setup is of medium complexity. However, compared to MuleSoft, it is the most straightforward thing. You need to do minimal installations. You just need to set up Java on your system and install Anypoint Studio to work on. 

In the case of Red Hat Fuse, you need to also ensure that you have Java installed and will need to install CodeReady Studio. There might be some dependency issues, which you will need to resolve. That is why it is of medium complexity to set up. 

Red Hat Fuse deployments are time-consuming, because of the learning curve.

If you are not implementing CI/CD, the deployment time will be minimal. If you use hot deployment methods, you can copy your JAR file or WAR file to the on-premises' host folder, then it will deploy immediately. Or, you could use some CI/CD stuff for deploying them, where you are running tests and using pipelines to check in from the source control management systems, but that will take some time. 

The deployment time does not matter. Every other tool is basically built on Java. In the end, all the deployables are running on a JAR or JVM. So, the time is the same for every other ESB.

Compared to other ESBs, the delivery time will not be faster. The delivery time will be more in the case of Fuse, depending on the use case. With a complex use case, you need to do more custom development for Fuse. It is a give-and-take scenario because it is the cheapest ESB available in the market. 

You can follow any of the API or SOA architecture. In our case, we use API-led connectivity, which is proposed by MuleSoft and Red Hat Fuse mimics that API-led approach. So, you can decouple your services and make an application for the same thing, e.g., we are taking the MuleSoft-proposed model and implementing it on Red Hat Fuse. It is easy.

The most important feature of Fuse is the cost. It is open source and a cheap option for an ESB. So, most of the clients in the Middle East and Asian countries prefer this ESB. Other ESBs, like MuleSoft and IBM API Connect, are pretty expensive. Because it is open source, Red Hat Fuse is the cheapest solution, providing almost every integration capability.

This solution is similar to other technologies with one main difference. IBM Integration Bus, IBM API Connect, or MuleSoft give us the built-in capabilities and connectors to do different architectures as well as asynchronous or synchronous calls. In the case of Red Hat, we always have to handle the asynchronous calls and stuff inside the Java code and do some custom development, which is a bit of a grind for the developer. However, everything that we can do in the latest, most expensive tool can also be done in Red Hat.

If we take good, expensive ESBs, like IBM Integration Bus or MuleSoft, they will have built-in connectors. Therefore, their time to the market and delivery time will be minimal. In the case of Red Hat and open-source stuff, the delivery time is a give-and-take scenario and the development time is more.

MuleSoft is the best ESB tool in the market. The delivery time for MuleSoft API into the market is minimal. With a medium-complexity-type API, it will take you a week or five days for its development and deployment on production. The same API in Red Hat Fuse might take two or three weeks for a medium-complexity API or service. However, if a company implementing Red Hat Fuse has already developed some accelerators or templates, and they have professional developers as well, then the delay can be minimized.

MuleSoft pricing is huge. If the business has critical integrations and their budget is low, we will propose Red Hat Fuse to them. Everything that can be done in MuleSoft can be done in Red Hat Fuse, but the delivery time and learning curve are a bit of a problem. Whereas, MuleSoft is the best solution in every aspect, except cost. Overall, my rating for MuleSoft is higher than Red Hat Fuse.

Mostly, the cost factor is the deciding factor when businesses consider using Red Hat Fuse. There is a huge cost difference in subscriptions between Red Hat and MuleSoft. Red Hat Fuse is significantly cheaper than MuleSoft.

If your integration needs are not that complex and you have plenty of time for your integration projects to go live, then you can go with this cheap ESB. It does everything that other ESBs do.

On a scale of one to 10, where 10 is best, I would rate Red Hat Fuse as seven.