Red Hat Fuse Reviews

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.

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.

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.

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.

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

It is highly stable.

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.

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.

Positive

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Red Hat Fuse is mostly used for integration, where you have different sets, different APIs: northbound and southbound, and you just integrate them, so Apache Camel and Red Hat Fuse become an ESB container.

The features I found most valuable in Red Hat Fuse are the OSB framework, containerization, and the integration of Apache technologies such as the NQ channel, CXF, etc. These are the features that are very prominent in the solution.

Red Hat Fuse also offers flexibility, so it's another valuable characteristic of the solution.

What could be improved in Red Hat Fuse is the deployment process because it's still very heavy. It's containerized, but now with Spring Boot and other microservices-related containers, deployment is still very heavy. Red Hat Fuse still has room for improvement in terms of becoming more containerized and more oriented.

As we work with containers, it takes about a minute or so. Red Hat Fuse is much faster than the traditional web application server, but it's much slower than the latest modern technologies such as Spring Boot, so there could still be some improvement there.

Red Hat Fuse also doesn't have a UI navigator and a UI-based workforce filter, and though those are all external, they could help improve Red Hat Fuse.

An additional feature we'd like to see in the next release of Red Hat Fuse is the UI resource wizard that would allow us to easily drag and drop tools. They should have a UI-based wizard where we can just drag and drop connectors, connect them, and do the graphics. We can always do coding for deeper requirements, but having a no-code, local setup in Red Hat Fuse, where we can drag, drop and build our workflows, connection instances, and services, and also design an entire workflow would be a good addition to the solution.

I've been using Red Hat Fuse for ten years. It used to be JBoss Fuse before it became Red Hat Fuse.

The scalability of Red Hat Fuse is fine. We didn't encounter any problems with the scalability of the solution. Within the controls of realism and with all the concurrent connections that are allowed, Red Hat Fuse does fairly well. We did some limited automated testing of concurrent pockets which were allowed, and it was pretty decent.

We required the help of the technical support team for Red Hat Fuse for a couple of projects. We had support licenses, particularly the enterprise version. We reached out to their technical support and they responded. On a scale of one to five, with one being bad and five being excellent, I'm rating support a four.

We've worked with IBM Integration Bus, and switching over to Red Hat Fuse depends on the customers and their preferences. One of the reasons for switching is that being open source has a bigger advantage, especially because you just need support licenses to move to the enterprise version, and won't really need to get enterprise level licenses. That made Red Hat Fuse more affordable versus IBM or any other ESB tool.

Another reason for switching is Red Hat Fuse is built over Apache technology, so it is very well supported. Camel CXS and other similar solutions are pretty well known and there's lot of community support or developer support around those products.

As containers are built on top of products such as Red Hat Fuse, the solution also becomes very usable.

The initial setup for Red Hat Fuse was a little bit complex, especially when compared with Spring Boot. Though there was a little bit of complexity involved during the setup of Red Hat Fuse, it was still manageable. The setup for the solution was okay.

We did a generic deployment for Red Hat Fuse in-house. We didn't use a third party for deployment, but I'm not sure if we'll need to work with one if we have to deploy the solution in a microservice architecture with one service per container, or how we'll go about doing it. That is something that we never figured out, but now that there's a requirement for deploying Red Hat Fuse in a microservice architecture which is something that we have not seen so far, we have to decide on how we'll go about it.

Our customers have seen ROI from Red Hat Fuse. We deployed the solution for our customers, and they've experienced a reduction in their total cost of ownership of Red Hat Fuse.

My company pays for the license of Red Hat Fuse yearly. At the end of the day, it's a low-cost solution, and its support licenses are still very decently priced versus bigger operators such as IBM, etc. Red Hat Fuse is much more affordable than other solutions. On a scale of one to five, with one being cheap and five being extremely expensive, I'm rating its pricing a one.

My company is using multiple versions of Red Hat Fuse for multiple customers.

My company provides Red Hat Fuse services to customers. At least four or five customers use it. As for the maintenance of the solution, once it is in production, only one person is required to handle maintenance. It depends on the SLA, but Red Hat Fuse is not that maintenance-heavy. It doesn't require much maintenance.

I'm recommending Red Hat Fuse to others because it's affordable and it's built on top of technology that is pretty popular and well supported.

I'm rating Red Hat Fuse eight out of ten. It's resourceful, has a  pretty decent performance, is built on popular technology, and it's very affordable.

My company is both a customer and an integration partner of Red Hat Fuse.

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.

Mostly it's combined with API management. It is for API management switches as well as the USB portions. We are using mostly email-based USB portion but we are hosting our API so in terms of exposing the API, it had been used for API management. 

The key portion, for now, is mostly under API management software. It's for the publishing of APIs then pulling the security.

It was pretty effective in aligning the software. We also like containerization capabilities. We're interested in how this container technology will develop. We're interested in the cloud and how it will develop. We're integrating a lot of things towards that end and Red Hat is helping us effectively move that way. It's opening up the prospect for more capabilities. 

The stability has been good.

The solution can scale. 

There is definitely a bit of a learning curve. We're still on the learning curve now and still trying to figure things out. We might be understaffed to really take advantage of the solution. 

We started deploying the solution in 2020.

The old version was stable. Not everything is out in the newer version, and we haven't yet started running the newer version, however, we haven't had any issues with the performance or reliability. 

It's scalable. It's been running on the container platform and if you need to create the load to have more nodes running, it's not a problem.

The pace of adding users is slow. Our developer license only covers 15 people. In terms of the business case, we haven't pushed out the API yet. That said, we do have 15 licenses for development, maintenance, and production.

The initial setup can be complex, especially, if, like us, a company is trying to learn and understand the system. We ended up getting outside assistance. 

The deployment is taking longer than anticipated. We had planned it to be nine months and we've had a lot of delays in the project start. We're kind of disappointed it's now 2022 and the solution was appointed at the end of 2020. It's been a year and four months or so of implementing it.  

We've had an implementation partner on the Red hat side as there is a bit of a learning curve and we're still trying to work things out. 

We are paying around $24 million across five years. 

We're a customer. 

We are not using the most up-to-date version.

I would advise new users to understand the whole thing is an investment that will start to look at digitization and the underlying technology to make it easy to create and develop digitization strategies. It's a good idea to start with the integration platform that can be available and that you can really step in through to think API-wise in terms of maybe early development and management. For us, even with a delay in the implementation of the technology, it will be available for future things. We're setting ourselves up for the future for now. 

While it's still new to us, in terms of the API management and what we've experienced so far, I would rate it eight out of ten. The delays have not necessarily been the fault of Red Hat, and more so of the company, which is working with limited resources.