Red Hat Fuse Reviews

We used RH Fuse solution for some integration between the new ERP system to our local legacies systems.

We take messages from MQ and then call a local API or leave a transformed file for a legacy system, and viceversa.

That has allowed us to reduce legacy system adaptation efforts.

The implementation of a ESB solution bring the opportunity of review the entire local integration strategy and start to rethink the company as a set of services.

We usually had used PowerCenter for master data integration (by replication). But in some cases, it was better to use Fuse for providing the master data online. It doesn't make it necessary to replicate data. So any application, especially new developments, get master data from a centralized repository (through Fuse), instead of having the master data replicated.

We decided to implement a ESB solution three yeas ago (2017) facing a big ERP migration project in order to easily extent the integration strategy bring by the IT Central Team (the core integration model is base on a asyncronous strategy over a IBM Websphere MQ Series solution).

The stability is good. The response is great. 

It's easy to scale in RH JBoss EAP solution. 

Any time we contact Red Hat for help we had got a satisficing response.

We previously had used PowerCenter, but the purpose is completely different. We are still using it for Data Integration (big volume of data). And we still have some old transactional integrations over PWC that we should to migrate them to Fuse.

The installation and configuration process is simple.

We have a mixed team. We have look external help for the developing and supporting tasks.

It has the same pros/cons that all OpenSource solutions. But here you have a big company behind. You could choose pay the subscription and get al the help you need. RH Knowledge base page has helped us many times.

We evaluated IBM Integration Bus, Fuse, and MuleSoft. At that point, MuleSoft was just beginning locally and we didn't get so much references from partners. And Integration Bus was expensive.

I would recommend Fuse. I don't think any other ESB tool makes big difference from Fuse. Many of this tools have the same problem: to publish and secure an internal service. Many tools bring other solutions to they ecosystems in order to extend to an API Gateway/Management functionality. You could reach the same adding others Red Hat tools.

Our customers have APIs and they develop them while we are using the gate for the code changes. They commit with the help of Jenkins so we pull that service and install that service on Jabber's use. After that, we create an ACL for that service and the rest is on the web server.

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.

I have been using this solution for the last four years.

My opinion is that this solution is stable. Red Hat Fuse has some dependencies, so we are resolving them one by one.

My impression is that this solution is scalable. Currently, we are working with one customer.

The initial setup process is quite straightforward. We are using a standard setup. When it comes to deployment, I just spent four or five years doing the setup, but it can take as much as eight or 10 years.

All nodes will be deployed on VMware and not on a cloud solution.

Overall, I would rate this solution an eight, on a scale from one to 10, with one being the worst and 10 being the best.

We use the solution to transform messages and integrate with backend systems for an ESB.

We're a solution integrator, so we provide solutions to our customers. 

The solution is deployed on-premises, but we might move to the cloud version. We're one version behind the latest version.

The integration layer handles all of the complexity, which results in faster implementations.

It's very lightweight. There's no need for any specialized tools in order to deploy any service for Red Hat Fuse.

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.

I have used this solution for six years.

We've had minor issues in the past, but they have been resolved.

The solution is fully scalable.

The support is excellent. We are very pleased with them.

Initial setup is very straightforward.

The solution is containerized, so deployment is quite easy. Deployment can be fully automated.

It's not difficult to maintain.

Our customers have seen ROI from using this solution.

The cost is quite competitive compared to other solutions.

We use the standard license, but you need the container platform in order to run it.

I would rate the pricing as eight out of ten.

I would rate the solution as nine out of ten.

My advice is that the solution is geared toward developers and not a citizen designer. It's not for people who want to be able to do integrations using a low code environment.

We have our web server, our app server, and our database installed using the Red Hat OS.

When comparing the database in Red Hat to that in Windows, we do prefer Red Hat based on its performance.

The installation is quite okay. We don't really change much in the configuration. Most of the time, most of the settings remain with the default and we are able to handle our needs using the default setting. But for some clients, maybe due to their connection, or due to their OEM, we need to adjust the settings a bit. 

So far there is not much concern.

Currently, the main point of concern for us is how flexible it is to cater to different requirements. It should be more flexible.

I have been using Red Hat Fuse for more than 13 years. Most of our products are implemented using the Red Hat. So it's been many years already.

We have different versions because our clients who implemented earlier may still have the old version. With new implementations, we'll normally recommend for the newer version. For example, we have a client who implemented version seven. Some clients are still using version four point something because they haven't done upgrades for many years. So it depends on when they implemented and also whether they do upgrades.

Additionally, we have clients that are on cloud and on premises, as well.

For us, Red Hat Fuse is stable.

I think we have more than 30 people working with Red Hat Fuse because we have more than 30 clients and most of our clients have Red Hat.

We definitely plan to increase usage because all our new clients and new prospects will continue to increase.

I am in touch with Red Hat support once a while. We might raise support because of the patches. Whenever we apply the patches, if we encounter any issue, we will raise the support to the Red Hat. But most of the time, after we implement, it's quite stable. So there is nothing much to raise.

We currently use other solutions, like Windows or other OSs. But the most common is Red Hat. I would say 80% or more are using the Red Hat OS.

Some of our clients already have existing servers with the Windows platform, so they don't want to change. So, we have to implement the existing platform in Windows.

The installation is okay. Because we have a team who does the OS installation for the client, we don't have much concern. Because it is handled by a separate team I don't have the details with me. We don't have much concern about the installation.

We only need one person to do the deployment who is from the DB team, so they know about the database and the server. 1% can handle the whole thing.

In terms of price, it depends on the package the client signs.

Actually, we are doing R&D on Red Hat Fuse. We are looking to move some of our application framework to use Red Hat Fuse. But we haven't decide yet. It's still in the decision stage.

On a scale of one to ten, based on our earlier Proof of Concept, I would give Red Hat Fuse a seven. Because the Proof of Concept was done two years ago we are now going to resume again and we are now at the decision making point. We still find that we need some customization in order to meet our clients' needs. Even if it is more compliant, there are still some customizations required in order to meet our clients' requirements.

Our primary use case of this solution is to connect our servers and external locations that we are dependent on for solution monitoring. We mainly use it for integration to our other systems. The reason we chose this is because it is good support for Camel which we use to some extent in our solution. Developers like to use Camel in their solutions. It has performed very well.

The most valuable feature for us is the close connection with Camel because we already used it. That's really why we chose Red Hat Fuse.

The web tools need to be updated.

We never have any failures caused by the integrations. It's really stable for us.

I haven't contacted tech support for this solution.

Previously we used Cicerone integration, and as hardware it is old. It is not as widely known or used and it was quite expensive. The main reason for management was that they weren't particularly clean and it was more costly. Both internally and in sales, the cost was too high, which was a big part of our total cost considerations.

The reason we chose RedHat Fuse is that it was a combination of technical bracket and for economic reasons.

The initial setup was pretty straight forward and there were quite good guides on the internet. The web guides were pretty straight forward. I found it was quite easy to set up and implement.

We found other solutions were more costly.

Criteria for us was that the vendor needs to be stable and the product should be quite widely used for us to consider them. We truly value stabilty more than whether it is the best solution. We need stability and reliability. That doesn't always mean the most developed or the most high tech solutions.

The shortlist for us was, Mulesoft and RedHat Fuse. In the end, it was between those two.

In our case it was much easier to implement a new integration on that platform than on the previous platform we had. Furthermore, it's open source, it doesn't charge us anything. The other one was a quite an expensive platform you would use in custom development. We saved money and time. Honestly, it fulfills the needs we have at the moment. 

I am using Red Hat Fuse to implement microservices.

I was asked to implement an application that was supposed to protect a lot of information in XML format. After I analyzed the business case, I proposed the VPN Red Hat Fuse as the solution to implement for the application. We also analyzed what was needed to use Java for implementation, but using Red Hat Fuse simplified the look of the application. It integrates very well with XML, with JSON, MongoDB, and relational databases. It was a perfect choice.

The solution offers competent modules that help you to integrate with other platforms and it allows you to write applications in a few lines of code.

The pricing model could be adjusted. The price should be lower.

The solution is stable. We have gone for months or years without any issue. There are no memory restarts, so from my point of view, it's very stable.

The solution is deployed using containers which makes it very scalable.

I've never had to contact Red Hat for this particular solution, though I have contacted them previously in regards to other solutions, and they were very helpful.

I have tried other options, but only for short periods of time.

The solution is easy to set up and use if you understand the philosophy behind the framework. Deployment was not a problem because it uses use containers, so I was able to use the source image feature integrated into Openshift. 

As long as you have the source code on GitHub or GitLab or a Git repository it can be deployed in five to seven minutes.

I did the implementation myself.

We have a yearly subscription. You don't need a license. It's not an overly expensive solution.

We are using the private cloud deployment model with Openshift as the provider.

I would advise those considering implementation to play with the framework. If you try to understand the philosophy behind the framework it will make it easy to use.

I would rate the solution ten out of ten.

I use Red Hat Fuse for integrating systems.

Red Hat Fuse's best features are that it's very easy to set up and maintain.

The main issue with Red Hat Fuse is the outdated and scattered documentation.

I've been using Red Hat Fuse for about four years.

Red Hat Fuse is very stable with Apache and Linux but not with Windows. We faced a lot of issues regarding the production setup with Windows - there are a lot of settings that need to be changed to avoid interactions between Fuse and Windows services that Fuse doesn't support.

There is no clustering in the on-prem version of Red Hat Fuse.

In the past two years, Red Hat's technical support has been very helpful and responsive.

Red Hat Fuse is very easy to set up.

Our license for Red Hat Fuse is around $27,000 per year, which is very expensive.

I would give Red Hat Fuse a rating of seven out of ten.

We are a solution provider and Red Hat Fuse is one of the products that we have experience working with. 

The most valuable feature is the software development environment.

Our clients would like to see the user interface improved so that it is more user-friendly.

We have been using Red Hat Fuse for two or three years.

Red Hat Fuse is very stable and this is one of the strong points of this product.

This product can scale both horizontally and vertically.

I have not been in contact with technical support. The tool is not very hard to use.

I find the initial setup to be easy. However, some people look for other tools because they don't like the command-line interface. The typical deployment takes about two weeks. This includes getting the machines.

From the point where we have the machines and understand the requirements, it takes no longer than two hours to set up and deploy.

Our in-house team is responsible for deployment and maintenance.

This is an open-source product that can be used free of charge.

I would recommend it to people because it is very good for starting with an ESB project. Depending on the size of the installation, it may not be necessary to use another tool. I would suggest starting with the documentation to see if it meets the requirements. I think that doing a proof of concept is a good idea because you will get a real perception of what the tool offers.

Another thing that I suggest is to try and find the connector that you want to use and make sure that it is supported by Red Hat or another company.

Overall, I think that this is a good tool. It is very versatile, although compared to other tools on the market, it doesn't have the appearance, or look and feel, of one that is very professional. You can do everything on the command line, but some people feel that it just doesn't look good. For me, agility and performance are more important than it being eye-catching.

I would rate this solution an eight out of ten.