Red Hat AMQ Reviews

When we started with Red Hat, we were using AMQ for asynchronous messaging between different applications. We began using 3scale and Fuse but these days, these solutions are packaged as one product called Red Hat Integration. They are bundled and you cannot acquire them separately. Now that this is the case, we use the entire package.

Vaguely, Red Hat AMQ is a wrapper over Apache Kafka and ActiveMQ, made and supported by Red Hat. There are plenty of use cases. Essentially, we use it for whatever use case you can think of for asynchronous messaging.

As an example, it is responsible for populating data lakes with relevant data.

Red Hat AMQ supports hybrid cloud deployment, and while we have an on-premises deployment at this time, this feature is important to us because we are planning to transition to the cloud. We expect that if not all, at least the majority of our applications to be on the cloud within five years.

It is very important to us that Red Hat Integration includes transformation, routing, connectors, and a distribution of Apache Kafka, all built to run on Kubernetes. All of these features are supported by Red Hat, which means that the maintenance and currency of this solution are assured. We used to question why we would buy a wrapper over an open-source product, instead of just using the open-source directly. Now, we see that the distinguishing point that gives us value is maintainability. With the full support of Red Hat, it takes much less effort and resources.

Red Hat integration enables developers to serve themselves what they need via APIs and event streams. It's a baseline technology that we build upon it for our use cases. It includes plenty of mechanisms for interacting with other systems.

The toolchain is okay but it's not great. They have enough for developers to start using these technologies effectively. However, in some cases, they are not as mature as we would like. For example, Fuse uses Apicurio. It's a different open-source product that visualizes the flows of the API implementation, including the transformations and everything that's happening inside the component. This is a feature that can be much better.

From the support perspective, they are supporting it to the maximum of their ability, but they do not have any SLAs connected to it yet because it's not their product. They're just using it extensively alongside the whole bundle.

With regards to the toolchain, they do have Fuse plugins for major IDEs. All of the interaction with 3scale goes through the web interface. Configuration-wise, the versioning is okay.

In general, the other products are a bit more mature when it comes to the toolchain. The Red Hat product allows it but requires a bit more seniority from the first adopters to get used to it, and then transfer this knowledge to others. This is in contrast to MuleSoft, where you can take junior to intermediate developers and they will make their way through. Here, it's a little bit different. You definitely need to have good Java experience at the senior level to quickly grasp how to work with all of the tools and technologies.

Also, the graphical presentation of all of the tools and flows is not as mature as you would expect from this type of framework. Because of this, a good developer, intermediate to senior level, will need to get used to these tools, and then, it'll be much easier to transfer the knowledge. That said, it was all good enough for us to get started with.

The other products have much better visualization tools available that integrate well with the platform. This gives you an opportunity to build something visually and then it will convert the code. You see more or less what's going on. With AMQ, you have the same capabilities but you need to write plenty of code.

Using this solution helps us to deliver new services faster. Fuse has prebuilt components that communicate with AMQ, which gives us an upper hand from a productivity perspective.

AMQ has definitely reduced our developer dependency on the IT department. Our DevOps engineers take care of the application infrastructure and they work with developers to resolve whatever issues they have. As an example, consider the case where we use 3scale to configure throttling or other aspects. If you compare the level of effort to configure, deploy, and maintain the API against when we were not using 3scale, it is much less when we use the Red Hat solution. This is true not just for maintaining the API gateway and API management platform, but in general.

From the build perspective, when you know the product well, it will take less time to create API products that are simple to medium level of complexity. From the AMQ perspective, 3scale and Fuse help to eliminate the headache of maintaining the platform that enables your asynchronous messaging.

The event-driven architecture enables us to decouple services from each other, and our developers can do their own integration. This is a benefit to using the event-driven architecture patterns, which can be used with any product that enables asynchronous communication.

This product is well adopted on the OpenShift platform. For organizations like ours that use OpenShift for many of our products, this is a good feature. The compatibility is good and it is well supported from an OCP perspective.

The official support from Red Hat is effective and responds in a timely manner, which is important to us.

This product needs better visualization capabilities in general.

The toolset should be improved to better support developer productivity. This is a point that would be greatly appreciated. They're moving in the right direction but it needs to improve.

The licensing structure is good but it takes a little bit to understand. As such, it should be more clear.

We have used Red Hat AMQ for approximately two years.

It is integrated with 3scale and Fuse, and we have used 3scale for one year.

We first engaged with Red Hat technical support quite a while ago, during one of our first implementations. So far, the level of support has been good and over the time that we have used them, they've been pretty effective.

All of the problems that we raised were addressed in a timely manner, as per their SLAs.

I have not had any issues with technical support but I would rate them a nine out of ten because everything can be better.

We do use open-source versions of the same solutions, such as Kafka, for other implementations and commercial products. For example, we use AWS and Kafka, but not for governmental projects. For the government, we only use AMQ.

It is helpful that we are able to switch between AMQ and Kafka. That is a good feature to have. Most of these products have the asynchronous messaging capability, so that is not something that makes a product stand out.

For AMQ, what stands out for me are the different offerings that it has. For example, it is very cost-effective compared to other solutions, such as Confluence.

This is a very cost-effective solution and the pricing is much better than competitors.

The licensing structure is a good one, although it should be easier to understand.

For our use case, we could have used open-source technologies. However, because we have governmental contracts, it is very important for our organization to have official support from the vendor for all of the technologies that we use. As such, I consider the official support from Red Hat to be an important feature, and it's what made us choose Red Hat over open-source.

For the API management aspect, we have assessed plenty of vendors. Two of these are MuleSoft and webMethods. From the functionality perspective, 3scale provides a very comparable, if not the same feature set as any leader in the market for API management and the gateway perspective, but with a fraction of the price.

I was working a lot with MuleSoft before 3scale, and both solutions are very effective. They're great. Our problem when it came to adopting MuleSoft was budgetary limitations. When we found 3scale and Fuse, it was good because the government requires that we have vendor support for products used in their contracts.

Fuse is simply a wrapper over Apache Camel, which is an open-source product by Red Hat. Apache Camel is a very good product by itself but with the additional support, it suits our situation much better.

With respect to 3scale, we evaluated it against our needs and it satisfies 95% of them. Together with the price, it is a very competitive product.

Overall, Red Hat is a more flexible model that you can use to design your gateways and API management. 3scale has a number of components that can be scaled independently, which is a feature that is very good in terms of flexibility. By comparison, MuleSoft works a little bit differently and does not have the same level of flexibility at the component level.

Red Hat is different from other similar products in that they don't market the integration platform and API gateway as separate applications. Instead, they are marketing it as one product, altogether. From my perspective, this is good because if you have more knowledge of the product then you can scale it more effectively.

The downside is that it takes a little longer to get used to and learn. There is a bit of a steeper learning curve and in order to understand it well, and use it to the maximum potential, you need to have knowledge of specific technology.

All of these things together led us to adopt the Red Hat solution.

I would rate this solution an eight out of ten.

Our main use cases are data synchronization between systems, real-time data synchronization, and event-driven microservices.

It is important to us that Red Hat Integration includes transformation, routing, connectors, and a distribution of Apache Kafka, all built to run on Kubernetes. This is one of the core use cases that we are implementing.

We have a hybrid environment, where we have on-premise and cloud technologies in our company as well as synchronous and asynchronous integration needs. This is a key component why we choose the technologies that we choose. For us, it is a very valid use case to be operating in this area. 

The event-driven architecture enables us to decouple our services from each other and empower our developers to do their own integration. The decoupling allows for a better user experience, more stable systems, and faster applications. It allows us to isolate the back-end systems and keep them safe.

The most valuable feature for us is the operator-based automation that is provided by Streams for infrastructure as well as user and topic management. This saves a lot of time and effort on our part to provide infrastructure. For example, the deployment of infrastructure is reduced from approximately a week to a day.

There are some aspects of the monitoring that could be improved on. There is a tool that is somewhat connected to Kafka called Service Registry. This is a product by Red Hat that I would like to see integrated more tightly.

We have been using it in production for two years.

The stability is good, but it is not excellent. Every now and then, we have had minor glitches. However, on an operating level, we have had no service downtimes since we went into production, which is excellent.

Scalability is good. It has a very flexible design and works very well.

There are between 100 and 500 technical users, which means about 100 to 500 projects are using it.

We have been steadily increasing usage and continuing adoption within the company.

The support is excellent and very fast for the Red Hat AMQ Streams solution. I would rate it a 10 out of 10.

We were previously using a different asynchronous integration technology, not Kafka, which was IBM MQ. The reason that we switched was that we needed the new technology. Since we were running on an open-shift Kubernetes infrastructure and already Red Hat customers, AMQ Streams was the best fit for our requirements.

The initial setup was straightforward. We were using most of the default configurations with the security enabled.

The actual deployment of the AMQ Streams infrastructure was done within a week. We then added some self-service capabilities around it on our own, and that took half a year to complete.

We deployed it with some help from Red Hat support. Our experience with Red Hat support during the deployment was very good.

We are providing business value by providing modern applications.

AMQ Streams has enabled us to deliver new services faster. We went from days to hours.

We evaluated mainly Confluent and a SaaS provider called Aiven. We opted for AMQ Streams because it has a very good technological, partner-wise fit. We decided against the SaaS solution at the time because it was unclear if the business model of the SaaS provider was sustainable.

The Red Hat AMQ Streams solution is the best that I know of on the market for self-operated systems, not SaaS solutions.

We are not using a Red Hat product for Change Data Capture (CDC). We are using a different product. We have made an assessment of the Red Hat technology for CDC, and it was not suitable for our needs. It was not good enough because we are running on an IBM database.

The self-service aspect is very important for us. This is one of the cornerstones of our strategy. However, we are not using Red Hat Cloud Suite for our self-services. We built it ourselves.

I would recommend trying it out. It is quite easy to set up. It takes a bit of knowledge of the Kubernetes stack, but it is something that can easily be tried out. Also, there is an open-source upstream, which is also very helpful.

Change Data Capture technology is very important for us because this technology allows us to quickly add streams of data from our databases for processing in our streaming hubs. As one of our main use cases is data synchronization between systems, Change Data Capture is one of the technologies that we use to affect that.

We use Change Data Capture technology to access data from legacy systems. We use CDC to access data from legacy systems and provide it within Kafka topics.

We are quite happy with this solution. I think it is the best out there. I would give it a nine out of 10, because I don't know if it is the best financially.

We are in the early stages of evaluating Red Hat AMQ for an OpenShift container platform because it can provide a very good Kubernetes platform using asynchronous data communication.

The solution is very lightweight, easy to configure, simple to manage, and robust since it launched.

There is improvement needed to keep the support libraries updated.

I have been using this solution for approximately one and a half years.

We have found the solution to be reliable.

The solution is highly scalable. This is the main reason why we are using this solution.

The support technical documentation is very good.

The initial setup is very easy.

There is a subscription needed for this solution and there are support plans available.

I have evaluated Kafka. Red Head AMQ solves the producer-consumer problems and Kafka is used for streaming mainly.

This solution is very mature and can be very useful depending on the use case. For what we use it for, it has worked perfectly. For some other use cases, this solution might not be the best to use. Most of my clients are using other Red Hat solutions combined with this one, such as Ansible and 3scale.

I rate Red Hat AMQ a nine out of ten.