Red Hat Fuse Reviews

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

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.

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 used for communicating and interfacing between systems. It's used for system integration and it's also used for messaging.

What I like about Red Hat Fuse is that it's a well-established integration software. I find all aspects of the tool positive.

My company doesn't have any experience with other messaging tools, so it's difficult to mention what areas could be improved in Red Hat Fuse, but it could be pricing because I find it expensive.

An additional feature I'd like to see in the next release of Red Hat Fuse is a better UI to control all configurations better.

I've been using Red Hat Fuse for the last three or four years. I'm still using it.

Red Hat Fuse is a very stable tool, so far.

Red Hat Fuse is a scalable tool.

Support for Red Hat Fuse is very good, and I would rate it a five out of five. I don't have any issues with support.

I found Red Hat Fuse easy to set up. I'm rating its setup a four out of five.

Red Hat Fuse is an expensive tool, though I cannot answer how much it costs as that's confidential.

Five hundred end users utilize Red Hat Fuse in my company.

My rating for Red Hat Fuse is nine out of ten.

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.

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

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

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

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

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

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

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

Some of the official Red Hat documentation could be improved a little bit. It was a little difficult to find exactly what I was looking for. I was eventually able to find it. It's there, but it was hard to find. 

It might help if, in the documentation, there were a comments section or some kind of community input. I might read a page of documentation and not fully understand everything, or it might not quite answer the question I had. If there were a section associated with it where people could discuss the same topic, that might be helpful because somebody else might have already asked the question that I had.

We deployed Fuse on JBoss EAP and the user interface could be improved with some type of dashboarding. That would be useful because, when we got it set up, there wasn't anything that we could readily just turn on to monitor its performance. It turned out there actually was, and I eventually found it, but it wasn't quite handy. It would have been really great if, as part of deploying Fuse on JBoss EAP, we could easily get to measuring performance and have the ability to monitor things, without having to dive into configuration or to deploy other stuff.

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

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

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

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

Positive

This is the first integration solution we have used.

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

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

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

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

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

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

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

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

We are mainly using it for integration with external solutions. The interface is satisfactory. Mainly, we are using a few integrations with Red Hat Fuse, specifically on OpenShift. Because recently, they renamed it.

The AMQ strings are the most valuable. Also, it's Apache Camel compliant. There are a lot of components, but one component, in particular, stands out.

The testing part, specifically when running it in the cloud, could be improved. It's a little bit complex, especially considering its cloud nature. 

Apache Camel has many components that are challenging as well. For example, Apache Camel K is difficult to test because they are dedicated to cloud infrastructure.

We have been using this solution for over six years. We are using the latest versions.

It is stable. We didn't have any issues with stability. I would rate it a ten out of ten. 

I would rate the scalability a ten out of ten. We are an enterprise business. 

The customer service and support team is good. We didn't require any specific support for this solution. But I had one issue ticket, and the response time was quick. 

Positive

From my point of view, the installation of Red Hat Fuse is relatively easy. You just need to open OpenShift Operators and install it. It's easy to install.

We have it on the cloud. OpenShift is considered a cloud product, although we have it installed in our own data centers. It's like a private cloud.

The deployment depends on what you are installing and configuring. But typically, it can be done in a matter of hours. For end-to-end things like Kafka, it depends on how you install it because it requires a specific kind of storage. It's not difficult to install Kafka, but you need to prepare the storage beforehand.

If you don't need very high performance, you can do it in less than one hour. But if you want to have highly performant storage, it takes more time to prepare the storage.

In our project, I deployed the solution. However, maintenance depends on what you install and configure. If you have any issues, it's possible to involve some maintenance. If there are changes in your application or business model, you may need to adjust some parameters, like Kafka topics, for example. In general, the only maintenance I do is to update to a new version.

Maintenance is very application specific and how you evaluate them in terms of settings.

It is a good price. It is not expensive. We have a yearly-based license. There are no additional costs to the standard license. 

From my point of view, it's a very good option, especially if you are considering a flexible integration approach. It can be run on-premises or in the cloud, but running it in the cloud is the right choice, in my opinion.

I would rate it a ten out of ten. 

I use Red Hat Fuse for integrating systems.

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

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

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

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

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

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

Red Hat Fuse is very easy to set up.

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

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

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