IBM MQ Reviews

Our use cases for IBM MQ involve share markets.

In this organization, we are not using many of the features because we have a very small infrastructure. In my previous organizations, I used many of the components including AMS. However, here, we are just using it as a messaging solution and not any of the other components.

The MQ appliance has very good performance.

The user interface should be easier to use.

The user interface should be enhanced to include more monitoring features and other metrics. The metrics should include not only those from the IBM MQ point of view but also CPU and memory utilization. These kinds of features would be really helpful when we have a large infrastructure. Right now, this limits us from using the product.

In general, the user interface should be more catchy, to entice users.

IBM should promote the use of the MQ appliance because the speed and performance are superior when compared to traditional ways of using the product.

If IBM were to release as least some limited features for MQ as open-source, then it would be great because people will migrate to this solution instead of choosing open-source products like Apache Kafka or RabbitMQ.

I have been working with IBM MQ for almost 13 years across different organizations. I began working with version 5.3 and am currently using version 9.

The stability is absolutely perfect when it is running on AIX. However, I have experienced some issues with certain Linux distributions. With AIX, I have not had any problems with IBM MQ. With other flavors of Linux, there is some instability whereby the MQ configuration parameters are not giving the proper information. From this, I have concluded that the stability of MQ depends on the Linux distribution that it is running on.

The number of users in my current organization is six or seven. This is the number of applications that we have. This is not an extensive use of the product but we do plan to increase usage in the future.

In my previous organization, our use was more extensive. We had between 700 and 710 users.

This product scales and the number of users depends on the industry, as well as the financial strengths that the organization has.

The technical support from IBM is always reachable.

Internally, we provide technical support to our users. This is possible because our team is only six or seven users.

This initial setup is not complex at all. Deploying it was very easy.

Limited staff is required to maintain this solution because of its stability.

The licensing fees are paid quarterly and they are expensive. This is something that I have heard from all of the organizations that I have worked with.

I have evaluated Apache Kafka and RabbitMQ because of the open-source features and benefits. The open-source aspect is an advantage. I have found that not many users choose IBM MQ, even though it is stable, because of financial constraints.

If IBM were to release MQ or at least some limited version as open-source, it would become more popular. People would choose it instead of implementing other products, or other streaming solutions. This is what people are trying to do with DevOps.

IBM MQ is much more stable than these other products, although the rest of them work well with cloud providers such as AWS.

Overall, this is a good product. The only thing that I found complex was to build the user interface with the latest versions of IBM MQ. It was a little bit tricky to do.

I would rate this solution an eight out of ten.

Originally, we were doing this in-house, and it was a huge effort. Now, with IBM MQ, we have increased our performance, and it performs really well. The queuing system, given the size of information, is helpful.

The on-premise installation is very valuable to us, since we are working with a lot of companies which have a very high degree of compliance.

I will say that, okay, we are coming from a long history as an IT company, and we have almost done queuing systems with other solutions. Moving from that implementation to something that is out-of-the-box, and the rave reviews, it was a great asset already. We didn’t have to worry about all the specific configuration, or installation of our own queue, and queuing system, and the brokers, and so on. It was some things a little bit out-of-the-box, that's why we like it.

I believe there is too much code to be done in order to handle the elements that you develop. We choose a new feature, we would choose something that is a little more … even more out-of-the-box, and gives me the possibility to configure directly where the messages should go, instead.

Also, the IBM MQ, it doesn’t really have a connector.

I believe the stability of the product has decreased since we began using it initially.

We had some load tests, and actually it was quite straightforward to make a scale actually. I believe we are satisfied with it. We are talking about 100,000 users, and it was performing well. So I don't know if it scales well when we talk about millions. But, for our needs, it scales nicely.

We do not have a direct contact with them. We have a desk line with them, and we have some sort of agreement. They treat us very well.

I do not get involved with the setup of the solutions. But, my team member was very happy with it, and said it was quite easy to install. 

We always must consider:

• Reliability is a key requirement
• There should be a roadmap
• Support
• Development

We also considered Apache Kafka as a solution. The main difference is that Kafka is an open-source platform. 

For us, it's basically just our messaging bus. We pretty much use it just for events that are limited to various applications that we have in our company. That is pretty much the use case that we have with respect to the IBM MQ.

Also, the stability and reliability of the tool system is what makes it really easy to be able to work with.

Technically, it has made our lives a lot easier. Prior to having MQ, we were basically developing these custom in-house solutions, where we were running into a lot of issues. After bringing MQ on board, along with its integration and flexibility that it has provided us with, it has basically shortened the amount of work we had to do in order to get it set up and to get the communications happening in between.

Maybe it should have something with respect to being able to provide a graphical view of the data elements that we are processing. For example, how many messages are being processed by a certain queue or for how much time each message is staying in the queue, and so forth. If there's a way that IBM can provide this tool that can have this out-of-the-box dashboard feature, it would be helpful.

Right now, we are trying to build custom solutions so as to gather that information. We are using Dynatrace, which is one of our monitoring solutions. We try to use it to analyze how many messages this queue has processed today and then we are trying to calculate the data for how long did the message stay in the system before the application picked it up. If there is a tool that can actually provide an out-of-the-box solution of this kind, then it would be really efficient for us.

We have not experienced any stability issues. We have been running this for almost about five years now. I don't think, up to this day, we've had any server down issues primarily because of MQ, i.e., the product itself. It's very stable.

With respect to scalability, we're not such a big shop where we are continuously scaling up, but it's a pretty standard system for us. We did not really have to do a whole lot. It runs on very bare resources; it's pretty good.

We have had a few scenarios where we were trying to develop some custom security solutions that required MQ to be authenticated, when they are trying to push our consumer messages out. It was not really an issue but more of an enhancement that we were trying to do. That's when we tried to approach IBM and get their inputs on the best way to do this.

They certainly were very helpful. They provided us with the necessary guidance and showed us some technical documents that were available for our reference and basically, to get the project completed.

Actually, when I joined this company, they already had the solution.

First, assess your requirement. Basically, understand what you want to do and that's where it all starts. Doing the right analysis, finding the right solution; that's where success and failure happens.

• Ease of use
• Access to support resources
• Access to new release information in a timely manner
• Easy to digest

It is easy to use and seamless with our existing technology. It's a trusted name we know that we've used for years. It performs and it has very low downtime, if any.

With MQ, we always have trouble with the initial priming call failing. It would be nice if we didn't have the little wake-up service. Maybe if it self-monitored, had it's own health monitor, to fire those off upon startup, so we don't have to pay the price for it.

We are happy with the stability.

We have not had any scalability issues to my knowledge.

Our admins have used support in the past. As far as I know, they are satisfied with it. It's pretty solid and it's kind of the backbone of a lot of our stuff.

The initial install was a long time ago.

Stick with the out-of-the-box requirements, unless something tells you to go in another direction. And if so, definitely work with the vendor to make sure that they give you the adequate tools to do that, or help you scope that out.

When selecting a vendor, support is the most important criteria.

We mainly use it for exchanging messages between application servers, back applications (e.g., databases), etc.

The message is delivered. This is the most important thing.

Overall, I have been satisfied with the solution's stability and scalability.

They could integrate monitoring into the solution, a bit more than they do now. Currently, they have opened the REST API so you can get statistic and accounting information and details from MQ and build your own monitoring, if you want. IBM can improve the solution in this direction.

15 years.

It is very stable.

It's highly scalable. It provides various ways to establish high availability and workloads. E.g., you can spread workloads inside of your clusters.

We have 20 engineers, admins, and integrators using this solution in our company. 

I would rate IBM technical support as a four (out of five) because they are a big company. If you want to get through all the technical support levels, then you need to spend some time. However, this is normal for such a big company.

The initial setup is straightforward, but you need to take the platform into consideration. If you are talking about Linux, AIX, and Windows, then the setup is really straightforward. However, z/OS or iSeries from IBM are not so straightforward so you need to be familiar with those platforms.

It takes half a day to fully configure MQ on Windows and Linux, and a bit longer on AIX. For z/OS and iSeries, it takes about five days to fully configure their environments.

There is a different platform price between Windows, z/OS, and iSeries.

I would definitely recommend IBM MQ to other people who are looking to implement this solution. They are going in the right direction. Everything is really in place and can be fully obtained. For me, the solution is a perfect product.

I would rate this solution overall as a nine (out of 10).

We use it for message transfer, mostly for a queue of the messages. Sometimes, we also consider using the topic space solution. But it is mostly for transferring messages between two applications. The applications are located in a different country, so it is also used for communication of MQ to MQ. 

What I like the most about IBM MQ is the 

• reliability
• robustness.

What could be improved is the high-availability. The way MQ works is that it separates the high-availability from the workload balance. The scalability should be easier. If something happens so that the messages are not available on each node, scalability is only possible for the workload balance. That's a big difference. And the application must be prepared to consume from each node so that it doesn't lose a message. Otherwise, you lose the ordering of the messages.

I've been using IBM MQ for more than five years. We're currently using version 8 and we are switching to version 9.

MQ is known for its stability.

The technical support depends on the kind of request you have. IBM is a big organization, and sometimes it takes time, while other times it's very quick. But what is great is the documentation and they even define some bugs. They have a willingness to describe these as an APAR (authorized program analysis report) on IBM pages and they're easy to find for the solution.

The installation is easy but the configuration could be complicated because you have to specify a lot of stuff, like queues. It could be a little bit complicated to configure if you have some specific scenarios. For a simple scenario it's easy, but when you have somewhat more complicated scenarios — for example, when you have a hybrid or you need to support some specific security requirements which you use to implement custom components — then it's not easy.

The time it takes to deploy depends on what type of clusters you need. For deployment for testing purposes, where you do not need any cluster, it can really be done in one day, maximum. It's not that difficult. But if you need to deploy a cluster, like a Veritas Cluster, and to prepare the workload balance, it can take days, with system testing etc. You have to combine a lot of other components.

I would recommend it. If you're looking for a traditional queuing system, IBM MQ is the right choice because of the stability and the performance. And from the support perspective, it's enough to have a really small team. It depends on the number of instances, of course. But MQ is not difficult to support. It's mostly to solve communication issues for applications and to determine what type of communication you prefer: the traditional MQ or via JMS, where you have to put it into the headers. But if you pass it, it is very stable after that and has very good performance.

Everything looks fine. It is 

• stable
• reliable 
• scalable.

I am not involved with it at the architect level. I am providing entry-level support for the product. But perhaps if they could come up with monitoring dashboards that would be good. We are using external monitoring tools, apart from our IBM MQ, to monitor IBM MQ. If we could get monitoring tools or dashboards to keep everything simple for the user to understand, that would be good.

The stability looks good.

The scalability is good. I don't have any issues with it.

The initial setup is not complex. It's very simple. I didn't find any difficulty with it.

Apart from IBM MQ, we are using IBM Integration processor. We are pretty satisfied with the product.

I would strongly recommend the solution, depending on the elements and architecture you're using. If you want to keep your data safe, I would definitely recommend using IBM MQ. We are satisfied with the service provided by IBM MQ. We don't have any issues.

I would rate it at 10 out 10. It's the best.

We can do the authentication and authorization of incoming requests using IBM WebSphere and DataPower. That's important to us because we can confidentially send the data with restrictions to other platforms.

In terms of benefits, our customers are happier since we are doing a good job.

In the next release, we would like to see more authentication capabilities embedded and included in the existing product.

I don't know about the stability.

We are good with the scalable data in the product.

I haven't used the technical support.

I was not involved in the initial setup.

I'm not sure about alternative solutions considered.

I definitely recommend them.

When selecting a vendor, we are looking for timely interaction. In case there any issues, we need to get support immediately.