IBM MQ Reviews

We use MQ for our transactional layer in conjunction with IBM Bus. We use MQ for our web application servers and many of our processes.

We like IBM MQ for our synchronous communications and transactional applications that require a lot of CPS.

We've been using IBM MQ for about 10 years, but we are currently in the process of migrating our IBM workload to the integration layer in AWS.

IBM MQ is highly stable.

The portion of IBM MQ that we have in the cloud is scalable, but the on-premise part isn't so much. However, we are working on sending our loads to cloud.

IBM support is good. I would rate it nine out of 10.

Positive

It's straightforward to set up IBM MQ because we can use it in lightweight modules, like containers, for example. It's not always easy for applications to connect to IBM MQ, but I think it's fine in general.

I rate IBM MQ nine out of 10. It's a good solution.

Mainly we are using MQ to pass the orders in the format of messages. We use MQ mainly for all the asynchronous messages that we pass.

It's easy to use and also quite compatible with all the language technologies where they can read messages and they can push messages to Java. It's easy to integrate and compatible with most coding languages.

The solution is stable.

I have found that the solution scales well. 

The integration capabilities could be even easier. 

I've been using the solution for a while now. It's been maybe ten or 15 years. 

The stability has been good. The performance is reliable. There are no bugs or glitches. It doesn't crash or freeze. 

The scalability is good. If a company needs to expand it, it can do so. It's easy.

We have a team of about five on the solution right now. 

We do not have plans to increase the number of users at this time. 

IBM technical support for any product is pretty much the same across the board. I have no complaints. They are okay. They are fast and knowledgeable. 

We have been using MQ for a long time. In the past we were using a custom-developed framework instead of MQ, however, that was ten to 15 years ago.

I can't speak to how the initial setup went. Those kinds of tasks are handled by the technology team. Therefore, I can't say if it was an easy or complex process.

I'm not sure, ultimately, how long the deployment process was.

I wasn't a part of the process. I can't say if we enlisted outside help or not. 

You do need to pay a licensing fee in order to use this product. We pay it on a yearly basis. 

I'm not following the versioning part. I'm not sure which version we are using currently. 

I'd advise new users to try it out as it is easy to integrate, scalable, and stable. 

I'd rate the solution, in general, at a seven out of ten.

The solution allows one to easily configure an IBM MQQueueManager. It's very easy and demonstrates comparatively better performance than that of other products. It is very good and makes it impossible to lose a message. These are very important advantages of the solution, but the greatest one is its robustness. 

It would be nice if we could use the cluster facilities because we are doing active/passive configuration use. Maybe we could implement them in cluster scenario and use the active/active nodes.

We have been using IBM MQ for around 20 years.

The onboarding processes and setup are very easy. 

We solely make use of IBM MQ and are an MQ customer. 

I rate IBM MQ as a nine out of ten. 

IBM MQ can be used as an integrated bus system in an API for message queuing.

The solution is easy to use and has good performance.

I have been working with IBM MQ for a few months.

The solution is stable.

The scalability of the solution is good.

We have approximately 100 users using this solution in my organization.

The technical support from IBM is very good, they are responsive, and customer friendly.

The installation is not difficult for IBM MQ and takes approximately one day.

We have approximately seven engineers and administrators that do the implementation and maintance.

The price of the solution could be reduced, and we are on an annual subscription.

I would recommend this solution to others.

I rate IBM MQ a nine out of ten.

IBM MQ is one of the biggest message exchanges in our company. We are in the process of migration to a cloud base environment because in some projects we are using RabbitMQ and Amazon SQS. However, IBM MQ is a big part of our technology ecosystem.

Overall the solution operates well and has good integration.

I have been using IBM MQ within the past 12 months.

We have had stability issues using the solution for some of our projects.

We have had scalability issues with some projects in the past.

The technical support has been helpful.

I have used RabbitMQ and Amazon SQS.

The installation can be easy, but it depends on the environment.

I recommend others use a more cloud-native approach to messaging.

I rate IBM MQ a seven out of ten.

We have various strips statements, and we use IBM MQ to pass those strips statements to different systems within our organization.

Encryption and the fact that we have not had any data loss issues so far have been very valuable features. IBM MQ is well encrypted so that we are well within our compliance and regulatory requirements, so that is a plus point as well.

I would like to see their cloud feasibility with other vendors. I know that they are very much tied to their own cloud right now, but I don't know how they are supporting AWS and Azure.

With IBM products, there's less marketing. If they do more demos and more seminars on their products, it will be very useful. On a given day. I get seminar invites for many vendors and products, but for IBM, I may get an invite once or twice a year.

Documentation is easily available to people who know about IBM products. However, if you're not familiar with the products and because there are no popups about seminars and product news, you will not be able to easily find the documentation. So, I think that there's a gap in IBM's marketing, which needs to be improved.

It's been a pretty reliable and well structured solution so far.

It's very good and scalable. Currently, we use it within the EMEA and APAC regions, and we have a few regions in the Middle East as well. We haven't had any issues so far in terms of scalability because we started with APAC. Usually, we start with only London and then slowly start extending to Europe and APAC regions. So, it's scalable because we started with one region, and now, we already have four or five regions.

We have a middleware team of 45 to 50 people in APAC and EMEA who use IBM MQ, but the usage is not limited to the team. We have users across all our venous functions everywhere because this is for backend transmissions connectivity. We use Message Queue everywhere.

At the moment, there are no plans to increase usage, but I think we'll soon be looking to do so. By the first quarter of 2022, we will be moving most applications to the cloud. We know that IBM MQ is very well supported in the cloud and that it will be easier. Right now, our infrastructure is very much on-premise dependent, and we have some legacy dependencies there. So to get to the cloud for us is a big journey, and once we are at that stage, then we'll be able to look into increasing usage.

We setup IBM MQ about four or five years back. I think the setup now would be much easier than the one we did then.

IBM MQ was the first product that I got introduced to when I started my journey with IBM. This is my 14th year in this industry, and I see that this application is still very much useful and applicable. So I always recommend IBM MQ, and this is one of the most popular IBM products.

I would rate it at seven on a scale from one to ten.

I think the whole product is useful. Their database and all is very good, and the product is fine. The fact that it ensures message delivery is probably the most important thing. I also like that you're able to trace and track everything. If it doesn't arrive at the destination, it will go back to the queue, and no message will be lost.

They probably need to virtualize the MQ flow and allow us to design the MQ flow using the UI. It would also help to migrate to the cloud easily and implement AWS Lambda functions with minimum coding. If you have to code, then just with NodeJS or Java. 

Many things should be done out of the box, like MQPUT directly to databases or MQGET to link to the main database. MQ should be able to connect to any language and just do it whether you're using mobile apps or web apps. It should be possible. 

The other probably more key thing is that to get IBM on-premise is hard because there are no freely available videos and courses. Technical support in Australia could be better.

I used to be an MQ specialist 20 years ago, and now I'm a solutions architect and consultant who sometimes recommends this solution to clients.

I think IBM technical support isn't too bad. IBM support can be a bit slow. Someone should be able to check on the problem straight away. 

I know that IBM in the States is very good. You can get good IBM staff and engineers and architects 24/7 or from 09:00 to 05:00. They have highly skilled and highly experienced staff there. Here in Australia, it feels like it's run by an account manager and run by salespeople. It should be run by architects and engineers and not by the account managers and sales teams.

I think IBM needs to look at its pricing. The prices of IBM products should be simple. The old way of pricing should now be moving on to the cloud to be pay as you go, a plan-based kind of pricing.

To become competitive, they actually need to move to AWS and Azure. If they really want to be highly available, they can have a highly available location, and charge another price.

On a scale from one to ten, I would give IBM MQ an eight.

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.