IBM MQ Reviews

We use the solution as a messenger software, in order to send messages to various applications.

The main issue we are having with the solution is due to the connection dropouts which have been going on for a long time now. Sometimes randomly the connection gets disconnected and we try to send a message, we get a failure. We then need to manually take an action on the message, which is happening quite a lot in production. We have been working together with the MQ team trying to increase the connection and some channel upgrades. We are taking steps in the right direction but the issue is not completely fixed.

Additionally, there is not any statistical messaging information being captured. We are not able to pull up any reports to determine when a message was sent. For example, how many messages during the day or during five minutes.

I have been using the solution for 13 years.

The solution is very stable. We have not had issues, except for the connection dropouts which could be related to the machine we are using.

The solution is scalable. It is flexible because, for us, we used the solutions adapter to provide the connection parameters to send a message. This has been quite easy.

We have previously used and still do, Rabbit MQ, which is open-source. It is getting quite popular because it is also stable and it has a good UI. This UI allows us to check the messages with some statistical data.

This solution requires a license and we have purchased an enterprise license.

I would recommend this solution. However, there are some emerging competitors on the market that provide a competitive alternative.

I rate IBM MQ a seven out of ten.

We are currently working on the use case. I work as an IBM system admin and part of MQ is hosted on the IBM server. We have a lot of other servers and appliances for IBM MQ that costs us a lot of money so we are currently looking for less expensive alternatives. Kafka is one of the choices on the table. We are looking to migrate to services on Google which is why Kafka was proposed for us to implement. 

We use it to integrate the backend and front end solutions and applications. 

The most valuable feature is the stability. It's perfect in this way. 

We are looking for another solution that is less expensive.

There is room for improvement. The live and portal monitoring needs improvement. 

I have been using IBM MQ for four years. 

It's very stable. 

It's scalable. 

I would rate their technical support an eight out of ten.

The initial setup was average. Not so complex and not so straightforward. 

The deployment itself, not including testing, took a couple of hours. 

It's expandable but it will add costs that should be taken into consideration. 

I would rate it an eight out of ten. 

In the next release, I would like for there to be easier monitoring. The UI should be easier for non-technical users to set up appliances and servers. 

I usually recommend IBM MQ for financial, government, and large enterprise companies. It is beneficial for handling high volumes of messages.

Using IBM MQ ensures the guaranteed delivery of messages, which is significant for my clients. It is also known for its security.

The most valuable features of IBM MQ are its guarantee of delivery, ability to handle high volume while maintaining high availability, and robust security measures such as SSL, TLS, and RBAC.

There are no improvements needed at this time.

I have been familiar with IBM MQ for roughly 20 years. It's been essential for many sectors during this time.

I rate the stability of IBM MQ as ten out of ten.

I give the scalability of IBM MQ a rating of eight out of ten.

The technical support from IBM is good.

Positive

Before IBM MQ, I was not using similar products. For comparison, I have used Kafka.

The initial setup is generally straightforward.

Part of our work is to assist customers during the installation and configuration of IBM MQ.

For an enterprise solution, the pricing of IBM MQ is very reasonable.

I have also used Kafka before.

IBM MQ has been in the market for over 20 years; it is an essential solution for most banking, financial, and government sectors.

I'd rate the solution nine out of ten.

We use it for file transfer and batch processing. We upload electronic documents to the Chilean government.

We use version M2002 Model B and our clients use version 7.5.

We use it for our factory where we have a system that uploads electronic documents for the entire country.

The high availability and session recovery are the most valuable features because we need the solution live all day.

The product gives us security.

I have been using it for six years.

We are happy with the solution. It is stable and doesn't require much maintenance. Two people maintain this solution: an architect and engineer.

We have two appliances, and that is enough for now.

There are a million end users.

The technical support is good. They respond in a timely fashion when we have problems.

We switched to IBM MQ when we consolidated our software and hardware integrations.

The initial setup was easy because IBM did the installation and integration of MQ with our appliance.

The deployment took a month.

The vendor did the MQ installation. We had a good experience with the IBM consultants.

We don't keep track of return on investment because we offer a public service.

The price is high. 

I did not choose this solution. The company has had it for over 20 years.

If you want high availability with little maintenance, choose this solution.

We don't use containers yet.

I would rate the solution as a nine (out of 10) because it is not perfect.

The most valuable features are the transactional semantics around messaging, and some of the reliability that they have built-in, from disaster recovery and deliver-once, and at most months, schemes for messages.

One of the things we do is, we send SWIFT messages and SWIFT is built on the MQ protocols. So, that's kind of its core features.

I really need more of the API management. It's perhaps the biggest thing. I don't really care that much for the analytic side but in terms of monitoring, we have everything tied in the way we need. However, that involved a lot of work on our side, but more importantly, it is really some of the APIs that allow me to do administration and provisioning the whole time.

The migration from different versions can be very different and difficult. We build a lot of our code around it. For example, we wrap it with the APIs and we embed a lot of things into our environment. We have close to 400,000 lines of code just around that and it has to be a reviewed with every upgrade.

We have a rather large implementation. Perhaps, the largest one on the planet and from a stability perspective, it's very stable, i.e., when it's used appropriately.

We usually always get to the right people, because of the criticality of some of our problems. So, it works very well.

The setup was straightforward and we wrapped it in a very complex way.

You should read the manual.

The way we use this solution, there is nothing else that even comes close to it.

What's important is that we can team up and work together because we tend to drive the products really hard. So, that relationship with the vendor, at the technical side, is really important to us while selecting a vendor.

I am an integration developer at a bank, and we use IBM tools to develop our solutions. We use IIB (version 10), IBM App Connect (version 11), IBM MQ (version 9.1), IBM web servers, and IBM ODM. We use IBM MQ for exchanging messages between applications.

It is useful for exchanging information between applications. 

It could always be more stable and secure.

I have been using this solution for about three years.

I didn't use anything before IBM MQ.

It was straightforward. It took less than a minute.

We didn't use any integrator. We have a team of about five people who work with this solution. We have developers, a team lead, and a project manager.

I would recommend this solution to others. I would rate it an eight out of 10.

We are using the solution for taking messages off the mainframe and distributing them down to a large, high-performance computing environment supporting over 4,000 servers.

The most valuable features I have found to be the message queue itself and its ability to bridge between mainframe type services to distributed services.

The clustering capabilities have provided some difficulties when it comes to resiliency. This has been a challenge for managing the environment.

I have used the solution for approximately 15 years.

We had stability issues with the solution. I would be looking at replacing the product, but I am not in charge.

I was not on the team that was on our internal MQ for support but I know IBM support services are really good. While I have had some issues and long nights supporting IBM software in my 33 years of IT, the support personnel are good. I always say good things about them. It is not their fault that their products come up short, but they do a good job at supporting customers.

The installation was straightforward until we started to have resiliency problems, it then became more complex to have to set up clustered MQ servers. We were using Linux Red Hat cluster services, which became an extra burden. When it eventually came time to do other activities, such as updating the operating system or a specific driver, for example, a firmware driver for the bare-metal servers themselves, having the MQ's clusters being sensitive caused a challenge for service and support.

The solution costs are high, it is going to cost a fair bit for annual operating costs and support.

I would advise, if I was the person in charge, I would tell my architecture team, "Bring me three other MQ-type solutions and do a POC to see if we can get better performance, resiliency, and reliability at a lower cost."  I guarantee there are solutions out there that can do just those three things.

I rate IBM MQ a six out of ten.

There are a couple of projects where we are using MQ heavily.

It is on-premises right now. We are looking to move to the cloud in the future.

• Offers better reliability and monitoring compared to other tools.
• Integrates well with other IBM solutions. Therefore, it makes sense to use this product when a company has a large IBM solutions portfolio.

I would like IBM to improve the performance. Right now, it is lacking and can be bulky.

We have been using it for three to four years.

It is a stable product. The reliability is better than open source software solutions. MQ performs even in extreme conditions.

Scalability is lacking compared to the cloud native products coming into the market. However, IBM is working to move their products into the cloud.

The software is more suited for medium to large businesses.

The support is good. They try to resolve problems as quickly as possible.

The setup and configurations are very easy, not complex. I would give the product plus points for this. This is compared to readily available, open source products that make you scratch your head when you go to set them up because they don't have documentation.

It takes a couple days to deploy the product to production.

We are a software development firm working with medium to large businesses.

It is a very expensive product compared to the open source products in the market.

We are also using Kafka, which is an open source tool, extensively in our projects. 

This is a good product if you are looking for 100 percent stability and reliability, as opposed to implementing an open source solution.

I would rate the product as a seven (out of 10).