Red Hat Fuse Reviews

We use it because it is easy to integrate with any other application, and when we tried to do an upgrade, it was really easy for us to do that. Plus, it is compatible with other programming languages. Then, to learn and to upgrade ourselves to this platform was easy to train people who were working with us on this platform was not something new or out of the box kind of a thing. It was something people were familiar with, so that is the reason. That is one of the reasons for choosing it. Additionally, we are getting support, specifically continuous support, which is always there for us.

Feature-wise, it was easy to integrate with cloud platforms, especially other cloud platforms which are already available. Also, features like containerization are there in the solution. So, it is not necessary to go with the trend since Red Hat Fuse has already provided us with an option where if you don't want a container, you can have it as a stand-alone, or if you want a container, you can do it container-wise. So there were multiple things that we could correlate, and then we were okay going ahead with the solution.

We are still trying to learn so much from it. So, I am looking for my improvement since it is always one step ahead of me. So, yeah, I'm trying to learn so much from it.

It is always a surprise to get new features, but it is not something on top of my head where I could suggest a new feature.

For improvement, they can consider the way we collaborate with other applications, if that is something feasible, considering the way it has provided us stand-alone support and continuous like CI/CD support. So, if there is something on which the whole team can collaborate onto. So, when we merge our tools, we don't have to go to Azure services since we can just have everything under one umbrella. Right now, in Red Hat Fuse, everything is not available under one umbrella. So, I'm sure it must be something very huge and big to ask, but if there is something that can be done to bring everything under one umbrella, then it would be great.

I have been using Red Hat Fuse for four to five years. I am using Red Hat Fuse 7.0.

Right now, it seems stable with the newest upgrade. But, again, you don't know how traffic and everything will be managed, so we are still in between how it will work out. Maybe in the next couple of three months, we will know exactly how stable the current platform is before forming an opinion. Currently, we don't have any issues with the platform.

Scalability-wise, I rate the solution nine out of ten. We are still migrating from the old platform to the new one. When I say the old platform, we have been upgrading from the older version to the newer version. So, we still need to see the feasibility and how much it has helped us. So, one point is not given, considering the need to check how the solution will help us in the next six months. The solution which currently has been provided to us is, like, equal to the speed at which the world is traveling, so I definitely feel overwhelmed working on this platform. Since it is an excellent product, I rate the overall product a ten out of ten.

Whenever we needed support from Red Hat, they were always available. They were just one ticket or email away from us. They offer support twenty-four hours and seven days a week. I rate the support a ten out of ten.

Positive

When I say deployment process, like, initially, we were using OCP directly to, like, finish when we do any development work on a local, we put the service on to JAR file, and after having it packed into a JAR file, and then on to an OCP platform, we upgrade since there is also an option with Red Hat Fuse which allows you to combine it to the cloud platform like Azure. So, we did that with Azure, Red Hat, and OCP, and now we have got CI/CD. So, all you need to do is, like, buttons. You don't even need to get into the server and look into the health. Everything is lined up for you. You can easily have it on one board. So that's how it has helped. I'm not sure if Red Hat has any CI/CD platform, while currently, Azure has it, like a board system, and onto it you can have Agile, like, to create where the team can create the task and all, like a Kanban board. And each task can be assigned to pull any activity you are doing. If you are deploying anything, you can simply map it to the task assigned. So, not everybody is technical in the team, but people do understand terminologies, so if a developer is doing any deployment work, at least he can inform the whole team what has happened. They don't need to know the nitty-gritty of how it is happening. Also, you don't need to drop an email or tell anyone personally that, yes, I have done it. It is already there on both, like, to set one place, you don't need to write down anything to anyone.

It is always good to try something new, and it is like, you don't know what will come out of it. After using it, I realized how good the platform is, and if I see how I was when I started off five years ago and where I am today, it has definitely improved a lot and helped me a lot. Even with the scaling and performance part, it has really helped from a developer's perspective. So, it has helped us to provide improvised solutions to our end customers.

I rate the overall solution a ten out of ten.

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

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

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

Red Hat Fuse doesn't have UI really. It's a package that is used for development purposes. The UI is coming in place during the development process, you can create a skeleton of your orchestration when using the solution, and it'll generate your code. So basically we can have an ID with a plugin for the solution, and this will generate a skeleton or a simple flow. But of course, it's not enough for real sophisticated implementations, however, it works as a starter. A visualization plugin feature would improve the solution. Perhaps it is less connected to the solution itself, but to another tool that is connected to Red Hat Fuse.

I have been using the solution for two years.

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

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

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

I give the solution an eight out of ten.

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

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

Michael:

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

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.

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

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

When we access the container, it crashes and then we have to kill that container, restart, and log in again. The solution should work on preventing this. 

In the next release, I'd like more stability and more security overall.

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

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

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

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

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

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

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

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

In the future, I would like to see more up-to-date documentation and examples from Red Hat Fuse. It is fairly new, so there is not a lot of information on the web about it right now.

I have been using Red Hat Fuse for three years.

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

We have 15 developers in our organization using the solution.

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

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

Positive

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

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

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

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

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

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

We primarily use the solution in financial operations and banking. 

The solution has improved the way our company works on a variety of levels. 

Overall, it is a very, very good platform.

The support training that comes with the product is amazing. 

There are a lot of engineers that know the platform. In Argentina, it's very popular.

It offers a very simple setup.

The capabilities it has to integrate and communicate with other systems are impressive.

We have not found we are missing any features. 

While it's a good platform, the pricing is a bit high.

I've been using the solution for five or six years. 

The solution is quite stable. We haven't had issues with bugs or glitches and it doesn't crash or freeze. It's reliable.

We have about 100 to 150 users on the product right now. We do plan to increase usage in the future. 

Technical support has been very good in general.

We did not previously use a different solution. 

The solution is very straightforward and simple to set up. It's not overly complicated or complex. 

I'd rate the overall ease of deployment at a three out of five. We deployed over the course of one year.

For maintenance, we have two or three people that can handle anything related to that. We don't need any more than that. 

We have a reseller consultant who can assist with the initial setup.

We've absolutely seen an ROI.

The solution is fairly expensive. It's more suited for enterprise-level companies and not necessarily small or medium-sized ones. You do need to pay a bit more to handle consulting and implementation. 

We did look into OpenShift before choosing this solution. OpenShift required us to integrate with other solutions. 

I'm not sure which exact version of the solution I'm using.

We are a Red hat partner. 

I'd rate the solution seven out of ten. It's a solid, stable platform.