Red Hat Fuse Reviews

Our company provides IT services. Some of the projects that we do are integration projects and we use Fuse to help customers solve their integration problems.

In our latest project, we integrated one legacy system with a new system they were implementing. We used Red Hat Fuse and AMQ to solve the integration situation. One system did not have a modern API, and the only thing exposed as integration points were database tables. The other system had more options, but to connect it to the database interface, we decided to implement a Fuse application to translate things and make it reusable and modular. 

It's deployed on-prem, as a stand-alone, on Red Hat Enterprise Linux, with an AMQ master sight configuration and two clustered Fuse nodes.

Because it was relatively easy to get set up, it saved us a lot of time in building the solution. 

In terms of functionality, it's influencing a key piece of integration, one that actually allows our company to operate. It makes possible a core part of our business.

The most valuable part of Fuse is the fact that it's based on Red Hat Apache Camel. It is really good that it already comes with so many different connectors. That makes it relatively easy to use. We use their XML definition to define the routes, making it really easy to define the routing.

Because Apache Camel is widely used, it was quite easy to find examples for use cases that are similar to ours. We were able to get it set up and do a proof of concept quite easily, without relying on the external consultants too much. The fact that we could download it with the developer license and set up a test environment and try things out, before we committed to purchasing an actual subscription, was also very helpful in getting us set up quickly. 

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.

I used it from 2018 through to April of this year. I will likely start using it again in the next month or two, as part of my consulting work for the IT services company I work for. We use Red Hat Fuse with Red Hat AMQ.

It's been very stable. Since we put it into production, there really haven't been any issues. It has been reliable.

It's very scalable. We haven't had to utilize its full potential. While I was using it, I found out about the possibility of containerizing it. That seems great. In the future, I think I'll continue to use it in other projects. For our use case, we didn't need to employ all of that, partly because the organization that we were doing the project for wasn't ready, and their infrastructure wasn't ready. But I'd rate it as very scalable.

I believe we used Red Hat technical support once because we were using the partner. My impression at the time was that it was a good experience, but the response was not as fast as I would've liked.

Positive

This is the first integration solution we have used.

Once I understood how to do it, it was straightforward. You just download EAP, start it up, download Fuse, build an application, and deploy onto it. Those things are quite easy to do, but there were some fundamental knowledge gaps that I had to close, before I could do that. When I first got started using Red Hat Fuse, I hadn't been really deep into the open source Java ecosystem. I was familiar with bits of it, but there were some things it seems they assume you know, things that help you set it up easily. 

It's hard to measure exactly what our deployment time was because we've made a bunch of improvements along the way. But from the time we decided to use it until we got a proof of concept set up—a minimum viable product—was about a month.

It would have been helpful if there were a prerequisite list, along the lines of: in order to use this, you need to know these concepts. Once I got the prerequisites, it took me a month to download it, find some examples, do a little tweaking, build a simple application, put it up, and do a basic test.

We did engage a Red Hat partner a little bit, Section6, to refine the design by designing some of the finer parts of it.

Our experience with Section6 was mostly good. Some of them were ex-Red Hat employees. They were professional. They knew what they were talking about, although there were varying levels of experience within their team. Some of them were really great and some of them were not as great. But overall, the experience was good.

We looked into MuleSoft a little bit. After doing some Googling and comparisons, the main standouts were MuleSoft and Red Hat Fuse.

One of the big factors in our decision to go with Fuse was the licensing cost. It was cheaper to go with Fuse. And from a developer and system architecture point of view, I liked Red Hat better because it is open source. There were a lot of examples online, and there was a wider ecosystem. I could pick and choose among all of the possibilities and the different projects that Red Hat was managing. I liked that part of it. An aspect of that had to do with containerization. I could see that, in the future, it would be really easy to put things together and evolve the solution later, if necessary.

My advice to somebody looking into this product would be: Be prepared to do a lot of reading. But the tool is quite flexible and quite powerful.

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

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.

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.