We changed our name from IT Central Station: Here's why

Red Hat AMQ OverviewUNIXBusinessApplication

Red Hat AMQ is #7 ranked solution in top Message Queue Software. PeerSpot users give Red Hat AMQ an average rating of 8 out of 10. Red Hat AMQ is most commonly compared to Apache Kafka: Red Hat AMQ vs Apache Kafka. The top industry researching this solution are professionals from a computer software company, accounting for 29% of all views.
What is Red Hat AMQ?

To respond to business demands quickly and efficiently, you need a way to integrate the applications and data spread across your enterprise. Red Hat JBoss A-MQ—based on the Apache ActiveMQ open source project—is a flexible, high-performance messaging platform that delivers information reliably, enabling real-time integration and connecting the Internet of Things (IoT).

Red Hat AMQ was previously known as Red Hat JBoss A-MQ, Red Hat JBoss AMQ.

Buyer's Guide

Download the Message Queue (MQ) Software Buyer's Guide including reviews and more. Updated: January 2022

Red Hat AMQ Customers

E*TRADE, CERN, CenturyLink, AECOM, Sabre Holdings

Red Hat AMQ Video

Red Hat AMQ Pricing Advice

What users are saying about Red Hat AMQ pricing:
  • "This is a very cost-effective solution and the pricing is much better than competitors."
  • "There is a subscription needed for this solution and there are support plans available."
  • Red Hat AMQ Reviews

    Filter by:
    Filter Reviews
    Industry
    Loading...
    Filter Unavailable
    Company Size
    Loading...
    Filter Unavailable
    Job Level
    Loading...
    Filter Unavailable
    Rating
    Loading...
    Filter Unavailable
    Considered
    Loading...
    Filter Unavailable
    Order by:
    Loading...
    • Date
    • Highest Rating
    • Lowest Rating
    • Review Length
    Search:
    Showingreviews based on the current filters. Reset all filters
    MichaelSukachev
    Sr. Enterprise Architect at Teranet Inc.
    Real User
    Top 5Leaderboard
    Flexible, cost-effective, good compatibility with the OpenShift platform, effective and timely support
    Pros and Cons
    • "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."
    • "This product needs better visualization capabilities in general."

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

    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.

    What needs improvement?

    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.

    For how long have I used the solution?

    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.

    How are customer service and support?

    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.

    Which solution did I use previously and why did I switch?

    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.

    What's my experience with pricing, setup cost, and licensing?

    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.

    Which other solutions did I evaluate?

    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.

    What other advice do I have?

    I would rate this solution an eight out of ten.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Flag as inappropriate
    Roland Haeusler
    DevOps Solution Architect at Helvetia Versicherungen
    Real User
    Top 20
    The operator-based automation saves a lot of time and effort
    Pros and Cons
    • "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."

    What is our primary use case?

    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. 

    How has it helped my organization?

    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.

    What is most valuable?

    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.

    What needs improvement?

    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.

    For how long have I used the solution?

    We have been using it in production for two years.

    What do I think about the stability of the solution?

    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.

    What do I think about the scalability of the solution?

    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.

    How are customer service and support?

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

    Which solution did I use previously and why did I switch?

    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.

    How was the initial setup?

    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.

    What about the implementation team?

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

    What was our ROI?

    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.

    Which other solutions did I evaluate?

    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.

    What other advice do I have?

    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.

    Which deployment model are you using for this solution?

    Public Cloud

    If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

    Amazon Web Services (AWS)
    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    Flag as inappropriate
    Find out what your peers are saying about Red Hat, Apache, VMware and others in Message Queue (MQ) Software. Updated: January 2022.
    564,599 professionals have used our research since 2012.
    Director, CTO, Co-Founder at a tech services company with 11-50 employees
    Real User
    Top 10
    East to configure, lightweight on resource, simple to manage
    Pros and Cons
    • "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."

    What is our primary use case?

    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.

    What is most valuable?

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

    What needs improvement?

    There is improvement needed to keep the support libraries updated.

    For how long have I used the solution?

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

    What do I think about the stability of the solution?

    We have found the solution to be reliable.

    What do I think about the scalability of the solution?

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

    How are customer service and technical support?

    The support technical documentation is very good.

    How was the initial setup?

    The initial setup is very easy.

    What's my experience with pricing, setup cost, and licensing?

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

    Which other solutions did I evaluate?

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

    What other advice do I have?

    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.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: My company has a business relationship with this vendor other than being a customer: Integrator
    Flag as inappropriate