We changed our name from IT Central Station: Here's why

Red Hat Fuse OverviewUNIXBusinessApplication

Red Hat Fuse is #5 ranked solution in top Enterprise Service Bus (ESB) tools. PeerSpot users give Red Hat Fuse an average rating of 8 out of 10. Red Hat Fuse is most commonly compared to Mule ESB: Red Hat Fuse vs Mule ESB. The top industry researching this solution are professionals from a computer software company, accounting for 35% of all views.
What is Red Hat Fuse?

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.

Red Hat Fuse was previously known as Fuse ESB, FuseSource.

Red Hat Fuse Buyer's Guide

Download the Red Hat Fuse Buyer's Guide including reviews and more. Updated: January 2022

Red Hat Fuse Customers

Avianca, American Product Distributors (APD), Kings College Hospital, AMD, CenturyLink, AECOM, E*TRADE

Red Hat Fuse Video

Red Hat Fuse Pricing Advice

What users are saying about Red Hat Fuse pricing:
  • "This is an expensive product. It costs a lot and although it's worth the money, the explanations that we need to give to our top executives are highly complicated."
  • "Pricing has been something that we have been working with Red Hat on, year over year. We have preferred pricing with the university because we are involved in education and research."
  • "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."
  • "This is an open-source product that can be used free of charge."
  • Red Hat Fuse Reviews

    Filter by:
    Filter Reviews
    Industry
    Loading...
    Filter Unavailable
    Company Size
    Loading...
    Filter Unavailable
    Job Level
    Loading...
    Filter Unavailable
    Rating
    Loading...
    Filter Unavailable
    Considered
    Loading...
    Filter Unavailable
    Order by:
    Loading...
    • Date
    • Highest Rating
    • Lowest Rating
    • Review Length
    Search:
    Showingreviews based on the current filters. Reset all filters
    Manager at a energy/utilities company with 501-1,000 employees
    Real User
    Top 20
    Reliable, good support, saves time and reduces data entry errors
    Pros and Cons
    • "More than a feature, I would say that the reliability of the platform is the most valuable aspect."
    • "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."

    What is our primary use case?

    We have Fuse installed on our on-premises servers, and we use it as an enterprise service bus for connecting different applications. For the time being, all of these applications are installed on-premises.

    We also use cloud-based applications, but none of them is currently interacting with Fuse.

    We try to implement third-party applications, if possible, out of the box and, if not, with minimum customization. That leaves something which is very important outside. The applications in many cases have to talk between each other and this is why we need integrations.

    So, we chose Fuse to act as a membrane or glue for all of our applications to be able to interact. For that particular purpose, we hire third-party development companies that create the integrations for us, but we chose Fuse as this membrane that glues everything together because that was, when we first evaluated it, the best approach that we could select at that point in time.

    How has it helped my organization?

    The comprehensiveness of Fuse's API management is quite good, and this is important to us. From a usability standpoint, particularly for the developers that have to interact with the API, it's fairly straightforward. We don't have in-house developers. We always make use of third-party companies to develop integrations for us. We don't interact directly with the APIs. Rather, it's third-party development companies that we hire to create integrations for us.

    Having said that, most of the companies that do such integration development for us, maybe half of them have experience with Fuse, and the other half who don't have experience can handle the APIs pretty well once they are exposed to them and someone explains to them how they work. These third-party companies have been working for us for maybe two or three years and have no problem at all with the APIs.

    With respect to reducing our developer's dependency for integration and custom code, our situation is mixed. We rely on developers to create integrations so it has not changed in that regard. However, if we compare it to a non-enterprise service bus integration scheme then there is less dependency on developers.

    At the end of the day, we rely on external developers for creating integrations and maintaining them because, of course, maintenance occurs. Businesses have changing requirements so we have to adapt those integrations. In the comparison with a non-enterprise bus scenario, we have less dependency because the alternative use case is to make these applications talk between themselves instead of to a third party that stands in the middle, such as an ESB. This approach is typically more expensive. It takes a lot of time and it requires, which is most important, that developers who know both applications talk between themselves, maybe from different companies.

    In our case, when we have the situation where Application A has to maintain a dialogue with Application B through the ESB, it may have different sets of developers. One for, let's say, Company Alpha doing the maintenance for Application A and Company Beta doing maintenance on Application B. They all have to talk to the API. The two companies don't need to talk among themselves, and that is something that reduces the dependency.

    There's another use case as well. Let's suppose we have these Application A and B, and we replace B with another application called C. When this happens, we don't need to rewrite the whole integration. We only need to rewrite the integration between the ESB and Application C. So, there are some advantages down the road and overall, the dependence on developers slightly diminishes.

    There are a couple of examples where using Fuse has benefited us. We have three applications that are running on top of Fuse. 

    With Fuse, we have been able to create a bidirectional integration between two applications in order to diminish the need for end-users to input or key in the same data into two different applications. This is what was happening before we suggested implementing a solution based on Fuse.

    The benefits were immediate in the sense that there were almost zero errors because, of course, when you key in data in two different systems, chances are that you can make an error maybe in one system, maybe in the other system, maybe in both systems at the same time. When you are copying data or extracting data to Excel spreadsheets and then trying to import them into the next system, that is cumbersome. It takes a lot of time. It's manual work that can be completely avoided and the possibility of inserting errors is fairly high. So, on the data quality aspect of the equation, it has improved a lot and that was a benefit for the end-users. In our case, if we can avoid doing manual tasks, that is highly desirable. 

    We have also another case where we implemented a workflow that interacts with a repository management solution. This workflow was developed from scratch because one of the companies had a solution that was written for them because there is no package in the market for their particular business.

    The industry comprises a very small number of companies in the world so there are no general solutions. We have to write them from scratch. But at the same time, we already possessed a corporate document repository where all copies of invoices, purchase orders, receipts, and other documentation have to be stored for disaster recovery purposes. Ideally, what we needed to do was have these two applications interact, which is exactly what we did by employing Fuse.

    We have other use cases, for example, integration between an ERP and the corporate repository. For all of these integrations, instead of being point-to-point, we are using Fuse. This means that the maintenance of those applications was reduced. In fact, next year we are planning to change our ERP solution for several group companies. All of the documentation that is generated, for example, invoices to our customers, will be created by another ERP. We will only have to rewrite the communication between the new ERP and Fuse. This will result in less time to market and that all equates to savings.

    We have other similar use cases but essentially, they all involve making two different applications talk between themselves or making a certain application store things in our corporate repository.

    What is most valuable?

    More than a feature, I would say that the reliability of the platform is the most valuable aspect. We have several servers and it is highly resilient, it is always available, and it requires very little maintenance. Of course, when something doesn't work, it's highly complicated. Because of the nature of the applications that we interface with, the product is highly complex but it's highly reliable as well. This is why we keep using it.

    What needs improvement?

    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.

    For how long have I used the solution?

    I have been working with Red Hat Fuse for the last four to five years.

    What do I think about the stability of the solution?

    It is highly stable.

    What do I think about the scalability of the solution?

    Most of our use cases are about 100 users each. It works nicely for us at this scale but I can't speak about higher volumes.

    How are customer service and support?

    We haven't had the need to access technical support very frequently. If you have good developers, you don't need too much in terms of technical support.

    For the times that we have needed them, we are satisfied with the support that we received. I would rate them an eight out of ten. Nobody is perfect and when we access technical support, we need an immediate answer. Of course, troubleshooting requires time and there is a gap between our expectations and the actual time that it takes for Red Hat support to deliver the solution.

    Once you are waiting for a solution, you get a little stressed because, of course, the nature of technical support is that you have a problem, and you do not know in advance how long it's going to take them to solve it because they need to understand it, and they need to replicate it. So, it depends on your eagerness to wait or not.

    Overall, it's very good.

    How would you rate customer service and support?

    Positive

    Which solution did I use previously and why did I switch?

    Before Fuse, we did point-to-point or one-to-one integration. We didn't have a prior solution that was replaced by Fuse.

    How was the initial setup?

    This initial setup is complex. The installation and implementation for the first integration, and perhaps most applications and projects that you can think of, is complex. The first time, it takes longer because you don't have the experience. It's more difficult. Then, you get used to it and you know the inner workings of the tool. You learn to know what might show up at a certain time and place, but for the first implementation, it's complex overall.

    The first project took slightly less than one year to implement, perhaps between nine and ten months. In that case, the project required completing the installation, as well as the creation of the first integration.

    What was our ROI?

    Fuse has enabled us to deliver services faster, although this is not something that happens immediately. When we chose the platform, we decided that all integrations should occur on top of Fuse, but the ROI would show itself down the road and not in the first integration. For example, the first integration takes a while, then the second and third integrations also take time. After working with the system, implementing perhaps ten integrations that are running smoothly, then you have the velocity effect showing up. It's not something that happens in the first case. It does occur but the effect is not perceived immediately.

    With respect to ROI, we have seen it but not as much as we expected. This is because the cost of the product is too high, in more than one sense. It's expensive overall but it is also too expensive upfront. For example, if you have to pay a million dollars, let's suppose over 10 years, the first installment is $100K, the second installment is another $100K, and the next eight installments are all the same. This is not the same as paying $1 million dollars upfront.

    Let's say you save $500,000 by the fifth year, you reach the break-even point provided you pay in 10 installments. However, you will not break even if you paid $1 million dollars upfront and you see the benefits of half a million five years down the road. This is also something that has an impact.

    Of course, the licensing model requires us to pay year by year, but the implementation cost occurs particularly during the first year and that is expensive as well. Overall, with respect to ROI, it is both yes and no. We have seen some benefits, but they didn't amount to the expectations that we had.

    Of course, this is very difficult to see beforehand because you will run into obstacles over time that you cannot anticipate and it tends to be more expensive. It is something that could have been better but some of the obstacles were very difficult to anticipate.

    What's my experience with pricing, setup cost, and licensing?

    This is an expensive product. It costs a lot and although it's worth the money, the explanations that we need to give to our top executives are highly complicated. This is because the product is highly complicated when it comes to translating the benefits into money.

    Regarding the licensing model, the problem with this type of product is that you are a hostage of the vendor. In this case, it's Red Hat but it could be any other. When the vendor changes its prices or the licensing model, you don't have options. You may have invested three or four years of development on the platform and if you are not satisfied with the new models, you have to accept them because the exit cost is huge.

    We are not satisfied with the contracting aspect and we try to do our best but this, in general, happens with most of the software vendors. In particular, where you have either yearly subscriptions or when the product runs on the cloud. As things are, we are increasingly using both kinds of options. So, it's a sad fact but it's what happens. No matter whether we find it to our liking, we have to accept it.

    Also, every renewal is complicated. In general, there are changes and the process isn't straightforward. Typically, vendors try to extract more money from the customers. I'm speaking about most of the software companies in the sense that you buy a product, use it, and you have to pay for technical support. In reality, you shouldn't have to pay for technical support. If you buy a fridge and it works, you don't buy technical support for the fridge because the fridge doesn't work or it has the risk of not working. If we need technical support, it's because the product lacks quality.

    Again, I'm not talking only about Red Hat. I'm talking about any software product. The industry works in a perverse way and I can say that because I was on the other side of the counter. I worked for a world-class software company for several years and it happens the same way with all vendors. It's a problem for us as customers and the only way to change this is that agreements should be created differently, but it doesn't seem to be the case. As much as I would like this to happen, it's far away from what we can expect in the next few years. It has gone in the other direction.

    Which other solutions did I evaluate?

    We evaluated two or three other solutions.

    In general, we make decisions based on three aspects. We consider the price, performance of the solution in the sense of suitability for our needs, quality of the product, et cetera, and third but not less important, comments from other users. In some cases, we consider the availability of local expertise by partners.

    In the case of Red Hat, there are a lot of Red Hat partners overall but with deep knowledge of Fuse, there are very few in our region. That was something that caused us some doubt. The only factor that made us hesitate was this relative lack of availability of solution partners.

    When you have very few suppliers, the price tends to be high, and maybe the response time that you need is not there because there might be, for example, a handful of technical resources of a certain vendor in your region, and they are booked for the next six months. We have encountered such difficulties, but the competition that we evaluated had also the same situation in that regard. Products such as Fuse and its competition are not widespread. You might find one Fuse implementation every hundred companies, and you can find a Red Hat Linux implementation in one of every two companies. It's obvious that you will find more Linux knowledge around than Fuse. This is how life works and you have to get used to that.

    This relative shortcoming was applicable to all of the vendors because there are not too many Fuse or Fuse-like implementations overall, at least at the moment when we started, between four and five years ago.

    What other advice do I have?

    My advice for anybody who is considering Fuse is to research the market and talk to other customers. Try to make a good business case, express the expected benefits in figures, in money, as well as the costs. Try to have an honest, upfront negotiation with Red Hat, and try to estimate what will happen during the next few years. You want to understand the growth curve that might be involved and try to find use cases that are similar to yours because no two integrations are alike.

    Had we done this at the moment we chose Red Hat, we might have not changed our decision but we might have been more confident. Of course, we didn't have that evaluation done at that point in time. We have no regrets, but this is what I would suggest to a friend that asks me how to proceed in this case.

    Overall, this is a very good solution. The product quality is high. It's slightly complex upfront, but it's highly reliable. It has very good availability. It generates very few problems once you configure it properly. Of course, the configuration must be done carefully. As I mentioned, documentation could be improved and for small-scale implementations such as us, it works fine. I couldn't comment on large-scale implementations in the tens of thousands or hundreds of thousands of users because it's not what we have explored. Our implementations are smaller, but I could give a thumbs up to the solution, of course, considering its quality and what it delivers to cover our needs.

    In summary, this is a good product and other than our comments about the documentation and resource consumption, we are really satisfied.

    I would rate this solution a nine out of ten.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Flag as inappropriate
    Manager of Integration Services at a educational organization with 10,001+ employees
    Real User
    Top 20
    Highly customizable, stable, scales well, and has good support
    Pros and Cons
    • "This solution's adaptability to our use case has helped us integrate our systems seamlessly."
    • "Red Hat is not easy to learn. You can learn it but you sometimes need external expertise to implement solutions."

    What is our primary use case?

    We use Red Hat Fuse in conjunction with ActiveMQ as our healthcare integration platform. Our electronic medical records (EMR) system is called Epic, and we have to send information from it to all of our ancillary systems. The process is that we take the data coming from Epic and we send it to the downstream apps, for example, to the radiology lab. As an overview, it can be thought of as a hub and spoke model.

    The EMR sits in the middle, like the center of the universe. We have the Fuse interface and we also have APIM, both of which take information that is coming from EMR. Surrounding these are approximately 140 applications, all receiving data from these systems. We categorize these as lab, radiology, pharmacy, and materials management.

    A lot of these apps need demographic information. For instance, a patient logs into the system and needs a demographics update. This is one of the purposes that the system serves.

    It's a well-integrated platform and without the Fuse interface engine, Epic cannot talk to the downstream, ancillary systems.

    How has it helped my organization?

    This solution's adaptability to our use case has helped us integrate our systems seamlessly.

    Functionality-wise, the workflow has become more automated. When something is ordered within electronic medical records, it's easily available in the ancillary systems. When the results are in the ancillary systems, they can appear in electronic medical systems. It's one integrated system.

    From a workflow perspective, it's very quick and efficient. Doctors and physicians can see their notes, documents, and all of the information they need. The interface engine sitting in the middle makes that possible.

    What is most valuable?

    Fuse has a lot of capabilities that we use.

    There is an open-source package within Fuse called Camel, which allows you to build interface routes with a programming language using Camel extensions. We use Java as our coding language and there are open-source integration patterns included. Fuse makes the integration much easier to do.

    This product is adaptable and scalable because of the DevOps features. In our environment, DevOps made it easy to adapt and we were able to customize a lot of things for our use case.

    What needs improvement?

    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.

    For how long have I used the solution?

    We began using Red Hat Fuse in late 2017 or early 2018.

    What do I think about the stability of the solution?

    This is a very stable solution. We have been on this product for about four years, and it's been pretty stable over that time. The upgrades have been great and the rollups that I've installed have been pretty stable. We do the server patching and that's been pretty stable, as well. We have 99.999% availability of our interface engine.

    What do I think about the scalability of the solution?

    This is a pretty scalable solution. We have had probably 5,200 interface integrations that we added to Red Hat Fuse. We have been doing that continuously and throughout, it has been very stable. We didn't have to do anything extra because we had configured the solution to be optimal for growth. If it grows to 100 interfaces, we can keep adding to it.

    Overall, it is pretty stable and scalable.

    How are customer service and support?

    Their technical support is great. They have a ticket process where you put in a ticket and then they provide solutions based on the priority of the ticket.

    We paid for a Red Hat technical account manager from the start. Having that kind of expertise helped us and I would rate their support a nine out of ten. They are very cognizant of their products. They understand their product and with their expertise, they have helped us resolve issues pretty fast.

    Which solution did I use previously and why did I switch?

    Prior to Red Hat Fuse, we were on an Oracle product called Java CAPS. The CAPS solution was not stable at that point. The support was terrible with Oracle because they didn't want to support it anymore.

    How was the initial setup?

    The initial setup was not straightforward, because of the dependencies that it needed and all of the things that we wanted to do with it. We as a team were learning the product, and we had contractors to assist us.

    Once it was set up, learning the product took approximately six months. Adapting it and customizing it to our solution was complete within six months and then we started implementing the product.

    What about the implementation team?

    We didn't have too much time to implement this product. We had a very short runway so we needed the expertise of a third-party contractor to get it implemented. We hired Spico Consulting, and their experts had experience in Red Hat Fuse. There was one consultant in particular who had done work in this space.

    They stepped in and helped us build the framework, and the framework helped us to get things working much faster. We only had six months for the framework, then the next year and a half was needed to implement, integrate, and migrate to the new solution.

    What's my experience with pricing, setup cost, and licensing?

    Pricing has been something that we have been working with Red Hat on, year over year. We have preferred pricing with the university because we are involved in education and research. Something that we are trying to negotiate with Red Hat is that we need to have pricing that is stable and appropriate for an education and research environment. We want to make sure that we get the discounts that are for state education and research organizations.

    We've been negotiating that deal with them and this year, we are hoping to get more discounts available for an education/research facility.

    Which other solutions did I evaluate?

    As Oracle was sunsetting Java CAPS, they were actively trying to sell their own middleware, which was not a great product, from my perspective. We didn't go to that product. We decided to move to Red Hat because it was something we envisioned that we would be happy with.

    There were other products that we evaluated. For example, Orion has the Rhapsody Integration Engine, which we looked at but didn't want to move to a JavaScript-based product. That would have locked us into that vendor.

    We could always go to another e-integration platform that's not Red Hat Fuse because this is an open-source technology. If you lock into a vendor and the price increases for their support, then you are stuck paying the higher prices. Therefore, we needed the open-source technology in-house.

    Another one we looked at was the Ensemble Integration Engine from InterSystems. There were a total of four or five that we evaluated and ultimately, we decided that Red Hat Fuse fit the bill.

    As we transitioned to Red Hat Fuse, we wanted to keep Java as our expertise. We had developers who knew Java, programmed in Java, and wanted to continue with Java. This is one of the reasons that we chose to switch to Fuse, and we are very happy with it now.

    What other advice do I have?

    One of the things that we're planning to do is use Red Hat OpenShift for cloud availability because we want to take our platform to the cloud at some point in the future. We want to have more redundancy on the backend and doing so will also help us with high availability. Currently, we have almost 99.999%, but 100% is desired.

    My advice for anybody who is implementing Red Hat Fuse is to have an expert SME from outside of the organization, who has done the job. When you run into roadblocks such as bugs, you want to make sure that you have that support.

    If you compare other products from an open-source perspective, I would say Red Hat fits that bill. They have a lot of developers who contribute to the open-source community and it has helped us to stay on the cutting edge. It is beneficial to have open-source contributions to our solution.

    If the solution is not open-source then a company will lock itself into a vendor. That means that they will get locked into pricing that only the vendor can control, versus when you have a solution that is open-source, you can always go to other competitors. That's one very big advantage.

    Red Hat has good education packages and my developers can take advantage of that. We have a subscription for learning. Plus, when you have an open-source package, you are not bound by the vendors' learning resources. You can always research outside by going to the community and doing your own research. The advantage is that you are taking your questions and you are posting them out in the community and getting those answers. Sometimes, you are contributing to the community in the process.

    I feel that there is more knowledge, outside of the vendors, that gets restricted. If you want IBM, then you're just focused on IBM's community. When you are outside of that, you have a bigger open-source community that helps answer your questions. There's a definite advantage to having an open-source product.

    In summary, this is a great product that is scalable, stable, highly available, and has a good help desk. These are the reasons that Red Hat has been a very good solution for us and we have no complaints.

    I would rate this solution a nine out of ten.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    Flag as inappropriate
    Learn what your peers think about Red Hat Fuse. Get advice and tips from experienced pros sharing their opinions. Updated: January 2022.
    564,599 professionals have used our research since 2012.
    Woo Joo Lee
    Systems Architect at a tech services company with 51-200 employees
    Real User
    Top 20
    Containerization adds to the flexibility and power of the solution
    Pros and Cons
    • "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."
    • "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."

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

    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. 

    What needs improvement?

    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.

    For how long have I used the solution?

    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.

    What do I think about the stability of the solution?

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

    What do I think about the scalability of the solution?

    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.

    How are customer service and support?

    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.

    How would you rate customer service and support?

    Positive

    Which solution did I use previously and why did I switch?

    This is the first integration solution we have used.

    How was the initial setup?

    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.

    What about the implementation team?

    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.

    Which other solutions did I evaluate?

    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.

    What other advice do I have?

    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.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Flag as inappropriate
    VP at a computer software company with 201-500 employees
    Real User
    Top 5Leaderboard
    Default settings are enough to handle most requirements, but needs more flexibility
    Pros and Cons
    • "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."
    • "Currently, the main point of concern for us is how flexible it is to cater to different requirements. It should be more flexible."

    What is our primary use case?

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

    What is most valuable?

    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.

    What needs improvement?

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


    For how long have I used the solution?

    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.

    What do I think about the stability of the solution?

    For us, Red Hat Fuse is stable.

    What do I think about the scalability of the solution?

    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.

    How are customer service and technical support?

    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.

    Which solution did I use previously and why did I switch?

    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.

    How was the initial setup?

    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.

    What about the implementation team?

    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.

    What's my experience with pricing, setup cost, and licensing?

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

    What other advice do I have?

    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.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    JuanArtola
    Business Solution Analyst at a manufacturing company with 10,001+ employees
    Real User
    Top 20
    Red Hat Fuse could be considered a simple, robust and scalable ESB solution.
    Pros and Cons
    • "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."
    • "I don't know the product last versions. I know they are migrating a microservices concepts. We still didn't get there... but we are in the process."

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

    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.

    What needs improvement?


    For how long have I used the solution?

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

    What do I think about the stability of the solution?

    The stability is good. The response is great. 

    What do I think about the scalability of the solution?

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

    How are customer service and technical support?

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

    Which solution did I use previously and why did I switch?

    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.

    How was the initial setup?

    The installation and configuration process is simple.

    What about the implementation team?

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

    What's my experience with pricing, setup cost, and licensing?

    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.

    Which other solutions did I evaluate?

    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.

    What other advice do I have?

    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.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Senior IT Architect at a tech services company with 1,001-5,000 employees
    Real User
    Top 20
    Performs well, offers a good software development environment, and stability is a strong point
    Pros and Cons
    • "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."

    What is our primary use case?

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

    What is most valuable?

    The most valuable feature is the software development environment.


    What needs improvement?

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

    For how long have I used the solution?

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

    What do I think about the stability of the solution?

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

    What do I think about the scalability of the solution?

    This product can scale both horizontally and vertically.

    How are customer service and technical support?

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

    How was the initial setup?

    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.

    What about the implementation team?

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

    What's my experience with pricing, setup cost, and licensing?

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

    What other advice do I have?

    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.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: My company has a business relationship with this vendor other than being a customer: Partner