IBM MQ Reviews

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 are all using the file transfer or MQ FTP feature. We are also it for distributed queuing and clustering.

Currently, we are not using many advanced features. We are only using point-to-point MQ. I have previously used features like context-based authentication, SSL authentication, and high availability. These are good and pretty cool features. They make your business reliable.

For critical business needs, everyone uses only IBM MQ. It is the first choice because of its reliability. There is a one-send-and-one-delivery feature. It also has a no-message-loss feature, and because of that, only IBM MQ is used in banking or financial sectors.

It would be an advantage if they can include streaming in IBM MQ, similar to Kafka. Kafka is used mainly for streaming purposes. This feature is clearly lacking in IBM MQ. If they add this feature to IBM MQ, it will have an edge over other products.

I have been working with IBM MQ for the last 14 years.

IBM MQ is a very stable product. You also get very good support from IBM, but we rarely have to go back to IBM for support.

It has good scalability. We are using point-to-point or distributed MQ, so we are not that much worried about scalability. If we need scalability, we can use MQ clustering for a high workload. We can configure it for resiliency and high availability by using the multi-instance queue managers. If one of the nodes goes down, it will automatically failover to the other node. It also provides some advanced high availability features on top of the multi-instance queue manager.

You get very good support from IBM. If you are facing any issues that are tricky or there is any code issue where FDC files are being generated and you're not sure what is happening, you can open a case with them. They will help you with that. They are very efficient.

The initial setup is very simple. The installation doesn't take more than 15 or 20 minutes.

I have installed it myself. I'm also doing maintenance, patching, upgrades, and migrations. We have a team of 11 administrators who are working on IBM MQ. They use it on a daily basis.

The upgrade process is simple. I refer to IBM Information Center. As a part of the preparation, I go through all the steps that they have given. I correlate the information with the infrastructure that we have. According to the current infrastructure, we document the requirements, and after that, we do the upgrade. We couldn't do in-place migration or upgrade, so we had to do parallelization. We took a new server, installed the new version, created a new queue manager, and migrated all the services.

It is a licensed product. As compared to an open-source solution, such as RabbitMQ, it is obviously costly. If you're using IBM Message Broker, which is a licensed product, IBM MQ is included in the same license. You don't have to pay separately for IBM MQ. The license cost of IBM MQ is lesser than IBM Message Broker.

I have been asked to do a PoC for one of our use cases, and we used RabbitMQ for that. They wanted to assess RabbitMQ in comparison to IBM MQ.

Obviously, IBM MQ has more advantages when compared with RabbitMQ. The main reason for doing this PoC was that RabbitMQ is an open-source product. Cost-wise, it looks effective, but from a technical point of view as well as from the point of view of scalability and features, IBM MQ is very enriched.

I would definitely recommend this solution, but it also depends on your needs and business case. I have been using IBM MQ for the last 14 years. I am very much used to it, and I like it. I have used other products too, such as RabbitMQ and Kafka, but not that much. 

I would rate IBM MQ an eight out of ten.

It's the EAI for connecting all our services like transport systems, replenishment systems, and order entry systems to our supply chain warehouse systems.

The most valuable feature is that it's a very strong integration platform and it is quite a monolithic solution. It's got everything.

At the moment we're trying to be a little bit more nimble in terms of how we deliver things for the business. We need to look at using some of the cloud-first as we have invested quite heavily in Azure. So we want to move away from all our legacy data centers and at the right time, we will move into the cloud as much as possible.

It's hard to put in a nutshell, but it's sort of developed as more of an on-premise solution. It hasn't moved much away from that. But we want to use the auto-scaling and scalability of some of the cloud services. It has developed a fair bit in terms of even the database of the board and stuff like that. Over the next three to five years, we want to move totally into the Azure.

I have been using IBM MQ for fifteen years in total. 

It's very stable.

It's the old way, old school scaler, where you need to add calls and you need to add memory, you need to add compute power, and you need to add storage capacity. You need to have bigger CPUs and more and more cores.

That's the old way of doing it. So you need to think about hardware. You need to think about memory, you need to think about storage capacity, you need to think about different switches, network switches, and whatnot. Scalability hasn't been a problem. It's just the sort of older generation of doing scaling so we want to be able to scale in the cloud.

The process for the scaling could be a little bit simplified.

IBM handles technical support. They are good. 

We did a selection and instead of going with some of the others, like TIBCO and whatnot, we went with IBM MQ.

We've set it up in several ways. I had it for a year. Each original implementation was with Accenture and we've had several crews come in to manage the services. There are different SIs that come in like Tech Mahindra and HCL. Over 15 years we've had a lot of independents come in and support. 

We're just building on top of the existing platform now. But we've made a strategic decision to move away from this on-premise infrastructure, the data centers if possible.

We've got 4,000 employees, it's quite a sizeable business that we take on vendors to come in. We're not an IT shop. Different managed services from different vendors.

We don't consider users for the platform. It's more about what transactions. So I think it ranges from two and a half million to 10 million messages a day.

My advice would be to rethink the cloud strategy. Make sure to have certain components that you can put into the cloud. Think about cloud-first properly so that it scales automatically. It knows how to work with some of the container services that are out there so that it scales better. It has some cloud components that are good but you still have quite a strong on-prem infrastructure to support it.

It's quite a complete solution. They have modules and stuff that they acquire and may add on as features and modules, additional modules, which is a very complete solution. It's been expensive to keep going the way we're going. And the turnaround is a bit slow, slower than we want. The business is changing quite rapidly, being in retail so we need to pivot quite quickly. And so that's why we're looking at seriously moving towards the cloud where we can simplify some of our processes and actually even our maintenance in it and the way we operate.

I would rate IBM MQ a seven out of ten.

MQ is a very affordable and easy to use messaging product. I like how fast you can write an API and send a message. Thus, its versatility, portability and easy to use functionality are valuable features of this product.

We use MQ for our insurance claims and use it heavily for CICS in the IBM Mainframe and use the IBM IMS for our applications.

Right now, with the new functions such as z/OS & distributed, I don't see any need for additional features as such. This is because everything that MQ provides, we do it. It's okay right now. Things are working fine.

The migration aspect is different and it depends on who is doing it, i.e., whether a person is doing it for the first time or a person who has done it for 18 times. I have done a lot of migrations in MQ, starting from this product version 2 and now it is on version 9. I have done a lot of migrations, so it all depends on how much experience you have, how you set up your migration task and so on. Migration is fine. I don't see any problem there.

If IBM develops a tool inside the MQ product for monitoring, then that will be better for the other IBM products available.

We have been using this solution for 17-18 years.

It's a very stable product. Being one of IBM's high-end messaging solution, it's a very robust product.

We have not had any issues. It is scalable.

I use the technical support from time to time in Hursley because MQ is developed in Hursley. I keep in contact with Hursley developers because in my organization, we use MQ a whole lot for our messaging. I am very happy with the support.

It is a good messaging product from IBM and is easy to use. It is very affordable and flexible, so I will advise other customers/companies to look into this product and use it.

The most important criteria while selecting a vendor are the customer support and easy to use the product. It is also important if the vendors can provide training to the staff and always be behind the customers to help them.

It provides scalability and it also provides secure messaging.

It is very robust and very scalable.

At a recent conference, I went to a presentation that had the latest version and it has amazing stuff that's coming out. So, I am excited to use those, specifically surrounding the web console and the fact that it's API integrated.

We have stability in our environment because of the product. We can keep adding solutions to the mixture and it still performs as is, which is again a more stable process.

It provides scalability.

I usually deal with level three support and they're pretty awesome; so, they're very good. I rate them 5/5.

There was not a previous solution. I know because of experience with my other jobs that this is a more robust technology to invest in.

Setup was straightforward. I had experience from my previous work, so I was able to bring that experience and implement it here. I was fully versed with it, so it was easier for me.

It's super expensive, so ask them if they can consolidate some other licensing costs. But, IBM is IBM, so I guess we'll pay for it.

IBM was on the top of our short list. I didn't even look at the others, because I am biased.

I would do a PoC with IBM and there's a lot of technical help out there and people who would come to help you. So, use them and also look for other customers who have used the product. Then, you will be able to see the benefits of it and try to fit it in to your department.

For 90 percent of our applications, we are using IBM MQ for a point-to-point setup, from one application to another application. It is like a passage between them. For the other 10 percent of our applications, we are using topic subscriptions.

It's deployed on-premises. We have tried it on Docker Containers as well, where we have an instance. We haven't done a cluster setup using Docker and Kubernetes. 

It is very stable. We haven't seen any failures.

You should be able to increase the message size. It should be dynamic. Each queue has a limitation of 5,000. Also, the maximum message length defaults to 4 MB. If it is more than that it should be able to increase and allow whatever the particular size of the message is into the queue.

In terms of additional features, I would like to see it be lightweight and go to the cloud easily, and dynamic scaling should be added.

I have been using IBM MQ for the last five years at my current company but I also used it in different agencies, so overall I have used it for about seven years.

It is scalable but we have to do it manually. There is no automation for scaling it.

Support is very good. It is very fast. If an issue is Priority 1 they will respond very quickly and call you.

It is pretty easy to set up. The installation takes less than five minutes for each server. People can learn IBM MQ in one week.

Even a version upgrade can be done easily. Including doing backups and installation, it can be completed in 10 to 15 minutes. Even RabbitMQ and Kafka require more steps for setup than IBM MQ. Installation of the IBM product is very simple. 

For individual projects, IBM MQ may cost more. Here, we are using it globally. It is distributed around the world for our operations, so cost-wise it is less for us. But if you go with individual licenses, the cost of IBM is much more.

We are also slowly moving forward into using Kafka.

We calculated the costs for our total environment of going with RabbitMQ, and if we went with priority support for RabbitMQ versus the cost of IBM MQ, there was almost no difference in the costs. Unless we went fully open-source, we would not save anything with RabbitMQ.

My advice to someone who is looking into using IBM MQ would depend on their budget, the application criticality, etc. If applications are less critical, you can go with open-source products. 

Apache Kafka is growing quickly. People are using it on almost every project. The future will be Apache Kafka only and there might be some RabbitMQ use as well. But I see that Kafka is gaining the most. IBM MQ won’t support large streams of data but Kafka will support large streams of data. For example, for Big Data projects, will only go with Kafka.

It's wonderful and is our primary backbone for moving data across different applications, within our company. Especially when we're talking about the healthcare and pharmacy industries, where we have patients' critical data, this is what we use to move data across. It's our backbone for data transmission.

The important thing for us at this point is the amount of data that we move, the guaranteed delivery and message affinity that it offers. These are very critical features when you talk about patient data.

It has definitely brought a lot of benefit into our organization, especial when you talk about applications talking to each other. For example, when you look at a patient's experience, i.e., from the moment the patient comes in, sees the doctor, the doctor makes a lab/pharmacy order and by the time a patient goes through the lab, the data needs to be there. It provides a lot of value in moving the patient data from the entry point until the patient gets out of the building.

One of the features to pinpoint is migration. When we want to migrate from one version to another, it takes years. So, definitely, we want to see some solution for IBM's standpoint, in order to make it easy for the customers to migrate from one version to another.

There are some operation challenges; however, it could be not because of the product but instead in terms of how we use it. We might be looking for improvements by adding some self-service capabilities, in order to go through the hoops of different teams to get the objects created. Thus, this will make it easy for the developers to access some of those things.

There were no issues in regards to the stability or scalability so far. Like I mentioned elsewhere, I've been using it for years now and it has really matured, at this point. We are really happy.

Lately, quality of the technical support is not that good, as it used to be in the past. IBM supports us from the infrastructure's standpoint to the part where they provide us product support as well. So, one of the things that we did notice recently was that the qualified people who were supporting all this stuff are not there anymore.

It is important to understand how to implement it and for what exactly you want to implement it. Sometimes, we get into a situation where you may not be choosing the right solution and may not really need MQ to support your product. You may be expecting something that MQ doesn't offer, so it is important to understand your business requirements and the features that MQ offers, in order to see if it is effective in implementing the solution.

The important thing while selecting a vendor is to help the customer go through the implementation phase. One of the typical situations that we run into are the people who you're interacting with, i.e., from a customer's standpoint, the vendor may or may not have the comparable knowledge that is required to make them move to where they want to go. That's the challenge we face across all our vendors. It doesn't have to be an escalation all the time so as to get what you want. The person you're working with should be knowledgeable enough to take the customer from the start to the end.

It allows more people to be able to support the application. They have training and we get folks to actually go in and bounce services and update services through IBM MQ because it is graphical. It's fairly intuitive on what's there. It enables us to have better and deeper support as an organization.

What I like about IBM MQ is that the ability to add applications to it is quite simple. There are a lot of extensible options for security, i.e., various things you can do. It's pretty easy to navigate. It's pretty easy to install and use from that perspective. Those are the things that I really like about it. It's our web hosting application of choice over using something like Tomcat or whatever because you can click through it, you can see things, and it's a lot easier from an administrative standpoint.

I think one of the things to improve on could be more administrative profiles which might simplify the experience. IBM MQ has a lot of settings. We're only using probably a fraction, maybe 10%, of the overall settings. Working for a large aerospace/defense firm, we have pretty tight security. There are a lot of settings that we do have but we're still only just scraping the surface of what's there. Being able to get to those sub-menus can be a bit challenging.

So there's the fact that there's a lot in IBM MQ presenting only the options that maybe somebody might do, such as a web application administrator might have to do. They don't need to see all the other bindings that are there, so it could be a little overwhelming trying to find it. So, I think if there's anything, that would probably be it.

Presenting and maybe having some different options for different user experiences based on the administrative duties that you have to do as an app manager or configure the server or security would be an improvement. For instance, in our information insurance organization, we have folks that go in and look at the security bindings that we have with our applications. Having those different roles mapped would be an asset, so you're not having to go through all the various sub-menus to find it would be something that would, I think, take it over the edge.

Stability is really good, actually. We haven't had any issues with IBM MQ .

We haven't had any issues adding applications to it and scaling up from it. So all in all, I think it's been fantastic.

I would say that technical support is average. Obviously, we are going through their PMR system. They are such a large company. I think the availability of somebody on the phone or calling somebody when you need something fixed immediately is a bit challenging for the organization. I think that's an area that they can improve on.

If we have IBM MQ or one of the applications go down, our entire plant is down. Then sometimes, it's 2-3 hours or something before someone calls us back. It would be nice if we can call somebody and have somebody you can actually work with that is knowledgeable on the product right away. That's my only gripe.

For a lot of other things, like lower priority items, working through the PMR system's been fine. I think their system is good. I just think that they need to be a little bit more responsive to their severity one tickets.

Initial setup was pretty straightforward. The more complicated part of it was the actual IBM CLM tools implemented within IBM MQ. IBM MQ itself was pretty simple.

I've heard that there have been challenges with upgrades, but we haven't gone through an upgrade cycle yet, at least in quite some time. We'll see how well that is but we haven't had that challenge yet.

We didn't evaluate any other products beforehand. It was just what IBM recommended.

Typically, what we'll do is, we'll go with the vendor recommendations because from a support perspective, if they're saying that because they support an application, we prefer to do go with that one because we know we can get the support as it goes on. That's really it.

Access to support is the most important criteria for me when assessing vendors. I think support is a key for us being in IT because we are supporting the application, so we need good support.

The second one is the ability to reach the developers on key issues and improvements that we would want to see in future versions of the application. Being able to influence the roadmap, I guess you could say. That would probably be the second thing we care about.

There are a lot of vendors that don't take that seriously. Like, you go in and you might have great features that would really broaden their product base, adoption of their tools. Some want to hear it; some don't. I think the ones that do hear that end up being more successful; they find ways to work that information back into their development stream.

That's probably the second most important criteria but, again, being in IT, I'm looking out for myself a little bit there. Support is number one.

I don't think I'd give anyone any advice at all. It's pretty straightforward to go and implement. The only thing that I would say is that perhaps if you're - depending on what you need to do - like deploying some of the IBM CLM tools, you might look maybe for a lighter-weight solution because of those various menus.

I know there are other IBM products and there are various lighter-weight solutions that are provided as part of the IBM MQ family. Going with something that's not full IBM MQ but maybe one of the other IBM products that's much more suitable for your organizational needs would be a good choice.