IBM MQ Reviews

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 two different use cases for this solution. We use it for the interactive interconnectivity between clients into the cloud and applications communicating within our enterprise software.

I have found the solution to be very robust. It has a strong reputation, easy to use, simple to configure in our enterprise software, and supports all the protocols that we use.

Everything in the solution could be simplified a little. We have trouble with the configuration and cost which is mostly an internal issue, but nevertheless, the errors do come up when there are configuration changes across a specific version. We have slightly different versions, which may have slightly different configurations which cause issues.

It is intensive to maintain and train people to use the application. There has to be a certain amount of education going into the developers, as well as the infrastructure staff. This could be improved.

I have been using IBM MQ for approximately 20 years.

The solution is very stable.

We have found the solution is highly scalable. It is very easy to scale horizontally, we can scale across and make another instance of the application if we need to.

We have approximately 2,000 to 10,000 are using this solution in my organization.

The quality of service can vary depending on the level of support for different issues. If it is on an issue with what IBM does within their cloud that they control as an ASP it can be somewhat complicated because it is not visible to us. They only support and run the model for us. They will do the updates, manage, and make sure everything is working, it is an effective service but if we have an issue, we do not get that much of a response from them. However, when it is on-premise with us on our side and we talk directly to IBM and they support us fully for the application. 

The installation can be fairly simple, but when changes or modifications are necessary within the system for the implementation it can be a bit difficult. We standardize a lot of the process whether it is using Jenkins or Pipelines, or another solution to make it as simple as possible. However, when we make changes and more errors and configuration problems come up, it can be quite difficult to narrow down those problems. Generally, we automate most of this part which has limited the impact but the process could be improved.

Since we automate a lot of the deployment elements I am not sure the breakdown of how long it takes for each part, but typically all together it takes approximately half a day.

We do the implementation of the solution.

This solution is a message exchanges system for queuing messages. The messages come in and if they are rejected or if they fail to be received, they sometimes fall into something that is called a dead letter queue, queues that are dead, or queues that are ineffective. Those have to be maintained and monitored at all times. There is quite a lot of attention needed. It is extremely critical and the robustness is extreme when it is on the edge. When it is in the enterprise is not that bad, but if it is on the edge, outward-facing to the client, we do a lot of work to maintain and ensure that it is working at all times.

You have to license per application installation and if you expand vertically or horizontally, you will be paying for more licenses. The licenses are approximately $10,000 to $15,000 a license, it can get expensive quite quickly.

We maintain and support a lot of applications across a wide enterprise. Therefore the cost of licenses increases with each individual implementation of a client because we have to pay for licenses. We are looking for an alternative solution to reduce costs by going to an open-source messaging system because we do not need the robustness of IBM MQ.

I have evaluated Rabbit MQ.

If you want a robust enterprise application that you know is going to be around that you can trust and you are very comfortable with the concept that you are going to pay for that stability and robustness, then IBM MQ is the best choice. If you are on a lighter throughput or you do not need to worry about the robustness as much then Rabbit MQ could be the better choice. It is a fairly stable application, and it works very well but you do not have that industrialization and long-term code benefit that you receive from IBM WebSphere. If your use case and budget fit then this solution would be a great choice.

We have used the application for a long time. I understand it, how it works and therefore I feel comfortable with it. From a pure usage standpoint, it is great. It will handle anything, but you have to be willing to understand that you are getting into something you cannot go backward on very easily. You cannot easily swap another suitable or similar application out without a lot of work involved. You have to be very careful what you are trying to accomplish with your software.

I rate IBM MQ an eight 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.