Red Hat AMQ Reviews

For use cases for Red Hat AMQ, let's take banking purposes. This depends upon the firm or the service or product company. For example, let's take HDFC Bank or any other bank. Whenever a customer deposits some money, they get some notification or alert. Second, when a customer withdraws some amount, they receive alerts in the form of SMS or email, or maybe both.

A different example would be a logistics or courier company such as FedEx, which is one of the biggest courier companies in the world. I actually deployed that application in that environment and now it is running successfully.

I have experience with features such as message persistence and fault tolerance because I configured high availability and fault tolerance for the client environment, including active-active and active-passive configurations. I mainly prefer active-active.

I created a security feature for user authentication and authorization in Red Hat AMQ using vault. When you enable the vault, then your whole Red Hat AMQ becomes more secure.

Management is straightforward. I configured it and created documentation. The operations team takes care of the operation part. I educate them on how to manage access, so they can easily add new people who join the company or manage the people who leave.

The benefits of using Red Hat AMQ include easy configuration and monitoring. On the portal, I can monitor how many packets or alerts have been generated or sent to the end user via Red Hat AMQ along with messages or emails. It also shows utilization in the tool. These features also come with other AMQs such as Amazon and IBM.

The areas for improvement include cost, which is a primary concern. The deployment process is simple, but the cost is very important. Additionally, the management portal should be more user-friendly for new users. There are some complications and areas where users get confused or sometimes may not understand.

The portal should add more information about servers, whether individual, standalone, or on-premise, whatever service or application is running. If someone is new to the company and there is no documentation, they might get confused about where their server is running, whether it is a virtual machine, standalone, or on-premise.

The installation is easy both on-premise and on-cloud. I also install this application using CI/CD in the container engine.

The overall solution is stable. I see stable performance without any latency or glitches.

The scalability and flexibility for both cloud and on-premise are good in Red Hat AMQ. That is not an issue.

Technical support from Red Hat is good as I've been working on Red Hat products for 16 years. I did not face any issues when there were requests or concerns with Red Hat support. I get support time to time, and that is not an issue.

Positive

The main difference between Red Hat and Amazon RabbitMQ is the pricing. Licensing and pricing are very important factors. For middle-scale or lower-scale industries, they mainly focus on pricing.

The performance in supporting protocol interoperability is excellent compared to other AMQs such as Amazon. I did not try IBM, so I cannot say for sure about that, but compared to other options such as RabbitMQ, it is somewhat costly. Amazon is much cheaper than Red Hat AMQ. Red Hat AMQ is purely based on the subscription model.

I work with Red Hat AMQ for message queue mainly. I suggested the product to the customer and deployed it in the client environment successfully.

I suggested Red Hat AMQ to two or three more clients. It's not specifically about the years, but I suggest it to my clients.

If we try to minimize the subscription amount, then I can suggest Red Hat AMQ to more customers.

I work primarily with Red Hat. For IBM, I have worked with their channel partner, not directly with IBM. For Amazon, I work with partners only.

I am working with one company as a consultant. I also have a small setup where I work as an independent consultant.

As a service provider, the advantages of this product include easy DR setup. If production goes down, it does not impact the end customer as the whole environment will start again from the DR. I designed this architecture for my client infrastructure.

My rating for Red Hat AMQ is 9.5 out of 10.

I can organize the tool with microservices, which allows me to use it across different services. It is easy to learn.

The product needs to improve its documentation and training. 

I have been using the product for five years.

I haven't encountered downtime or bugs while working with Red Hat AMQ.

We have done around 20 projects in Red Hat AMQ. 

I have two projects using Red Hat AMQ, and I can share how its scalability has impacted them.

In one project, we have a solution for authentication and authorization using SSO. We need to integrate with other systems in two ways. We use Red Hat AMQ for social data, sending messages to other queues, and integrating with business. We have two databases with the same information. The solution is good because it helps us solve problems with messaging. For instance, when messaging doesn't change, we still check the cloud and verify the information.

In another project, we have a large banking solution for the Amazon region using Red Hat AMQ for financial transactions. In this solution, business messages are sent, and another system processes them. 

I haven't contacted Red Hat AMQ's technical support. However, I know that they offer good technical support. 

The solution's deployment ease depends on the environment. It is easy with Docker and Kubernetes. 

I didn't have any problems using Red Hat AMQ and would recommend it. The documentation is good, and I encountered no issues during installation. I rate the overall solution an eight out of ten. 

We just started working with Red Hat AMQ. We selected it as the ESB (Enterprise Service Bus) platform for a new airport project. I manage the entire Master System Integration (MSI) project for one of the new airports.  

I like its flexibility, scalability, and the number of protocols it supports. And, there is the cost factor compared to IBM MQ.

We are interested in a better monitoring tool for all the messages exchanged. We expect a very good monitoring tool for maintenance.

I have been working on it for three months.

We haven't implemented it yet, but based on our meetings and discussions with Red Hat, it sounds reliable and scalable. That is the main criterion for selecting this product for one of the busiest airports in Mumbai. It has to be reliable.

It is a scalable product. 

We have support in Mumbai, so we get local support.

Positive

We used IBM MQ. The major issue was cost. That's why we chose Red Hat AMQ. 

Red Hat MQ has multiple components. The challenge is the multiple components it has. This brings a higher complexity compared to IBM MQ, which is a single complete unit. Red Hat AMQ includes several queue managers and components like Camel and AMQ, in addition to several queue components. 

We're still exploring it. Red Hat AMQ hasn't been implemented at any airport yet. This is the first time we will implement a full-fledged ESB at an airport. It will be a landmark achievement if we succeed.

I would rate the pricing a six out of ten, with ten being expensive. There is room for improvement. 

Overall, I would rate the solution a seven out of ten. 

Red Hat AMQ is a platform for asynchronous messaging and underneath, under the hood, it implements Apache Kafka and Active MQ. They employ two, open-source technologies to implement different cases of asynchronous messaging and they're giving kind of a unified integrated interface to both of them.

The most valuable feature is stability. The solution is a pretty stable product because it is an independent installation. Stable product, relying on stable technologies and is pretty quick. Again, we're talking about the messaging services, which are by themselves known for very quick performance, let's say, features. Performance and handling loads of data, as well as... A difference between Red Hat AMQ, let's say, and underlying technologies, you can actually deploy Apache Kafka and Active MQ by themselves and use them. So here, you are deploying those two technologies as part of the set, and there is probably easier handling of which technology will be used for which case.

It's pretty much a Red Hat thing to take the open-source technology, and wrap it up.

The turnaround of adopting new versions of underlying technologies sometimes is too slow. The solution is always running a number of versions behind the latest version. They need to run plenty of tests and have confidence in the version to give their commercial support for it. If the solution can release new versions quicker, it would be great, because the features are not coming quickly for Red Hat AMQ.

I have been using the solution for two years.

The solution is pretty stable.

The initial setup of the Open Shift operator is very convenient for standard deployment. Everything else needs to be customized.

The implementation is completed by our development teams.

The solution is open-source.

I give the solution an eight out of ten.

The solution is maintained by Red Hat.

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 use AMQ's event-driven architecture to exchange messages, and I can connect the AMQ Broker through various integrations. 

AMQ is highly scalable and performs well. It can process a large volume of messages in one second. AMQ and OpenShift are a good combination.

AMQ could be better integrated with Jira and patch management tools. 

I have used AMQ since 2019.

AMQ is a highly stable solution. I've never had problems in my production environment. 

The scalability is excellent.

Red Hat support is excellent.

AMQ is effortless to set up. You can copy it to an OpenShift container and configure it in a few minutes. 

The ROI is excellent. 

AMQ is fairly priced, especially when you purchase it OpenShift. When you're buying OpenShift, you have the option to get AMQ as an add-on. 

I rate Red Hat AMQ 10 out of 10. I recommend AMQ if you are looking for an event-driven messaging solution. 

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.

We use this solution for message queuing.

We have been having a great deal of trouble with this solution. However, I have to point out that I do not really trust our infrastructure, as I have just discovered that it is worthless. This leaves us with the question as to which degree these problems are AMQ's or our own.

There are several areas in this solution that need improvement, including clustering multi-nodes and message ordering. There should be better support for having messages be ordered per bucket.

Technical support for this solution needs improvement. 

This solution is completely unstable. We lose messages.

We have not yet had to scale this solution because we don't have a lot of messages. My impression is that it is average in terms of scalability. Limited, to a certain point.

This is a backend product so there are no users, but we have approximately twenty applications that we let it work with.

Technical support for this solution is below average. They didn't really solve the problem and it took a lot of time. For six months, we were going back and forth. Their response was not something like "Oh, you have that burning problem? We will send you some consultants who are going to solve that for you, with you." It was more like, "Yeah, you open a ticket. You get a reply." Then, the reply isn't really saying much and it's a big back and forth.

A couple of months later that have something that could be a fix, that kind of stuff. Ultimately, they did not help us out a lot. That said, I think that many of the problems were really very strange to them because our infrastructure has network issues. This may have been the reason that they could not give us a straight answer.

When you deploy a product somewhere in an environment, on hardware, and your hardware is not functioning properly, then you might experience the weirdest kinds of bugs that people just aren't familiar with. I can imagine that people sitting remotely were scratching their heads when they saw our problem, and couldn't get them reproduced. I don't want to be too harsh on them, but if I didn't know that I had infrastructure problems, I would rate technical support quite below average.

Prior to this solution, we used HornetQ. It is no longer supported, which is why we switched to this solution.

I did not perform the initial setup of this solution, but from my understanding it is average.

With the trouble that we have been having with this product, we have reinstalled many configurations of it and we're still experiencing issues. We did multiple reinstalls, had bugs, tried to do other configurations, etc.

One person is enough for deployment and maintenance.

We deployed this solution with our in-house team, and we requested assistance as well.

I was not here when this solution was chosen, but I can say that the person who selected this option was gone two months later. I think it must have been a very average evaluation. It may have been chosen because it's supported by Red Hat, and I'm working at a Red Hat-minded company. Everything is Red Hat. It was an obvious choice for many reasons.

My advice to anybody who is implementing this solution is to make sure that you get the clustering configuration right and that it actually works, and beware of message ordering problems. Simply, for us, there were a lot of features that did not work properly because of the clustering configuration.

Unfortunately, that was not mentioned in the manual, or anywhere else, so we had to find out that certain things simply don't work when you go and cluster and when you scale it out.

If I knew for sure that the technology didn't work and that was the cause of our problems then I would rate this product a three out of ten, but I know there are also other factors involved, so I can't really say that it's the technology.

I would rate this solution a four out of ten.

I primarily use Red Hat AMQ for asynchronous communication and ticketing.

Red Hat AMQ's best feature is its reliability.

Red Hat AMQ's cost could be improved, and it could have better integration.

I've been using Red Hat AMQ for a couple of years.

Red Hat AMQ's stability is good.

Red Hat AMQ's scalability is pretty good.

The initial setup was really complex because we had to manage it ourselves.

Red Hat AMQ's pricing could be improved - I would rate it as six out of ten.

I would recommend Red Hat AMQ for those looking for an industrial product. I'd give it a rating of eight out of ten.