IBM MQ Reviews

I like its ease of administration. We just recently moved to the MQ appliance and the high availability (HA) feature is outstanding. We're really, really pleased with it and the power of the appliance itself. When you throw more work at it, the faster it goes.

For example, when you're doing maintenance, you can fail over the entire group of queue managers in that HA group or you can fail them individually if you'd like. So, it's very helpful that way. But that's the manual fail over. The automatic fail over is what we are really interested in. We did have an appliance go down. Everything failed over and none of our clients knew of it. So it was very good. We were very pleased with that.

The user interface is good. The command line version of it, MQ CLI, is good. The web user interface is really handy; really a good feature.

It updated everything. We started with Version 7 with Linux and now, with the appliance, it seems to be bringing us more into the 21st century so to speak.

We have an M2000. The M2001 has a 3 TB SSD, which is a good feature. I wish they had had it when I started. But as we upgrade, in the future, we'll probably move to that. Everything is working properly with the current version.

The reason the migrations are an issue is, we came from Version 7.01 and Version 7.5. The security in Version 8 was a little tighter. So, there were a few things we had to learn. Be sure that we were up to speed, so that's all.

We haven’t had any stability problems at all. Stability has been outstanding. We went from multi-instance queue managers, which worked fine, except they worked often. That wasn't good for us. So it was a perceived outage for our clients. The availability has been outstanding with the MQ appliance.

I have used support on several occasions. We were an early adopter, and there are always a few bugs along the way. We did use technical support and we went all the way up to the lab a couple of times. It was outstanding as usual.

We have been an MQ adopter since 1998. We were using z/OS, so we have been using MQ along the way. Then we went to Windows, to Unix, to Linux, and now the appliance.

Actually, setup was straightforward. I'm not a hardware person and it was a first-time setup. It was what they said it was. It wasn't a 30-minute setup, but it was pretty easy.

Plan your file systems. Plan your messaging names and your network routes. You want to be ready with everything before you start and once you do that, you're in good shape.

When choosing a vendor, I want knowledge and availability. Those are the two things that are most important.

I was part of a small team that tested and used the IBM infrastructure in a QA environment. My activities included configuring and creating test environments and finding solutions to monitor the infrastructure.

Using a message queuing solution, we had a banking solution that integrated multiple branches and interbank systems. Different systems for credits, debits, CRM, and others communicated through this message queue solution. It wasn't just about communication; for instance, a CRM application needed to collect information from various banking systems, such as account balances, properties, contracts, and credit cards.

These systems were separate, and the message queuing solution combined information from all of them into one message. When a request was made from a workplace for information about a person or company, the message queue infrastructure routed the request to all connected systems, ensuring the workplace did not need to be aware of all configuration details.

The product's most valuable feature is its ability to work in clusters. This allows for creating a cluster of message brokers, providing horizontal scalability. Another important feature is the extensive command-line interface, which allows for comprehensive monitoring and management of the system. This enables the creation of complex scripts to configure, making it a complete and very powerful tool.

The tool is expensive. 

I have been working with the product for four years. 

The tool is scalable. 

IBM MQ is stable.

The tool's support is not cheap and fast. You can't expect a resolution from support. 

The setup of message queues in an enterprise trade system is complex, especially when dealing with hundreds of message brokers and thousands of message queues. Configuring such a large infrastructure isn't straightforward and requires tools for testing, validating, and identifying missed components.

We manage a large configuration file, likely an XML file containing thousands of lines. Many teams update this file to reflect changes in their systems. It can be split into multiple smaller files to manage this file, but this complicates maintaining a single point of truth and requires validating all combinations. Systems communicate with each other using these components, needing a common protocol.

The benefits of using IBM MQ include buffering your transaction flows, which is useful if you have spikes. For example, it can handle this increased load if you normally have 100 messages per second but expect 10,000 the next day. You can also build clusters of message brokers to scale horizontally.

The license for IBM MQ is commercial and not cheap. You get a multi-platform solution, which is important because it lets you connect systems on mainframes, personal solutions, Unix, Linux, etc.

Applications produced and consumed messages, with the IBM infrastructure serving as the transport and storage for these messages. Messaging was based on IBM MQ, and several other IBM products were involved, though I can't recall their exact names. These products were used for transforming messages, validation, and routing. The infrastructure could route, validate, split, and combine messages.

I rate the overall product a ten out of ten. Our goal was to measure the performance of the integrated system, not just individual components. This involved external systems as well. We used various command-line tools, such as IBM MQ, to collect detailed information about processes and systems. Measurements had to be aligned with configurations, meaning we couldn't use a universal solution. Instead, we had to adjust based on specific requirements and configurations.

We use the solution when connecting with the external system to process messages in a queue-based flow. When the solution receives a message, the flow is triggered to cycle through routing, mapping, and logic to create a pipe delimited, XML, or other formats that send to the end system. 

We created the queue-based flow to receive messages and connect them to end systems using a pop-up concept to classify messages by subscription topics. 

The solution is fast with end data compared to other messaging tools. 

With integration tools, the node is connected with the queue manager so there is some dependency. In the solution's latest version, the dependency was removed which allows us to create servers without any interdependencies.

The solution should offer a freeware version, free vouchers, or certifications for learning purposes and building a knowledge base. When creating an account to download software, you must provide user details like credit card information. If you exceed the allotted hours or days while trying to learn the solution, your credit card is charged for additional time which is what happened to one of my colleagues. 

Learning the solution is not as simple as MuleSoft or APG. Some developers left the market because they didn't know how to learn the solution. Other products provide free vouchers or certifications or learn programs but IBM currently doesn't do that. 

I have been using the solution for ten years. 

The solution is an older product and very stable. Our product teams never have issues with it.

We have experienced some issues with scalability because there is a known lag when scaling.

Technical support is rated a ten out of ten because we receive support very quickly but rarely need it. 

Positive

The initial setup is easy with no huge steps. 

There really isn't any deployment. Creating queues does not take much time and we use them with channels and subscription topics to push and pull messages

The implementation was completed in-house with integration developers doing the important work. 

If you want to route messages through a queue-based app, definitely take a look at this solution and research the cost. 

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 use to connect the core banking system to several other systems in our environment. We are working on an IBM server with multiple clients sending XML messages through the IBM environment using MQ. 

The end users are working on front-end services that are communicating with the servers. We are installing MQ on the backend system to act as middleware. Mainly the users are coming from somewhere else.

The monitoring could be improved. It's a pain to monitor the throughput through the MQ. The maximum throughput for a queue or single channel isn't clear. We could also use some professional services by IBM to assess and tune the performance.

I started using MQ around eight to 10 years ago.

MQ is stable, but we face some limitations with redundancy.

MQ is scalable. 

I rate IBM support eight out of 10. We've never had problems with support. 

Positive

We previously used different protocols like TCP socket connections. Now, most of the services use MQ. 

Setting up MQ is easy. We had a "grow as you go" implementation strategy. We started with a single channel and progressed to multiple queues and channels depending on the systems and integrations with other systems. It was a gradual deployment and expansion as we grew the services interacting with the core system using MQ. Maintenance requires two or three admins. 

The MQ license is a bit high.  I rate IBM MQ six out of 10 for affordability. 

We are exploring other solutions, including the Kafka platform. There are other services that can do the same thing but maybe offer some additional features, especially on the monitoring side. It may be faster as well.

We are using Confluent Kafka for some other services, and it's a good event-streaming platform. It does almost the same thing as message queuing, but we it has some other features and can do some things better than MQ.

I rate IBM MQ seven out of 10.

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.

The product does not allow users to access data from API or external networks since it can only be used in a closed network, making it an area where improvements are required.

I have been using IBM MQ for fourteen years. My company is a customer of the product. I don't remember the version of the solution.

Stability-wise, I rate the solution a ten out of ten.

Scalability-wise, I rate the solution a nine out of ten.

Around 15 to 20 people in my company use the solution.

The product is used whenever there is a need to use it in the development phase. Once the tool is deployed on a particular site, we don't need to use the product until and unless any issues or errors are reported.

I rate the technical support a nine out of ten.

Positive

Before IBM MQ, my company used to use normal point-to-point APIs. My company started to use IBM MQ because we wanted to introduce standardization in our processes.

The solution is deployed on an on-premises model.

I rate the product price a four on a scale of one to ten, where one is low price and ten is high price.

IBM MQ streamlined our company's application-to-application communication since it is a rigid and robust solution that allows you to transfer data from one system to another system using the tool's adapters. In general, the product is very robust.

A scenario where IBM MQ reliability was critical for our company's operations includes an incident involving three to four of our clients who use the product, among which a few are airports situated in regions like Delhi and Bangalore in India. All the big airports use IBM MQ as an integration platform, so it is considered a tier-one application. In the aforementioned areas, there is a need for a tool that offers scalability and robustness.

The feature of IBM MQ, which I found to be most instrumental for our messaging needs, stems from the fact that my company never lost messages when we were using the product. The product has a queue manager, and the message doesn't go anywhere until and unless you read it. The best part of the product is that it ensures that there is no data loss.

IBM MQ's security features have enhanced the data transmission process in our company since it functions in a very secure manner. Nobody can get unauthorized access to the product.

The product offers very good scalability to support business growth.

IBM MQ's integration capabilities with other systems are beneficial since we have developed many interfaces for many airports. Many systems use IBM MQ to send data from one system to another, so it has helped in a great way when it comes to the integration part.

I rate the overall tool an eight to nine out of ten.

The solution is primarily used for business transactions. It's used for financial transactions as well. Those are the two main use cases. We exchange information with our in-house applications before we supply information to our customers and so on.

The messaging queue is the main feature that we use. We use other products like publish and subscribe, which are very useful to us as well. 

We can share data and other people can subscribe to it. 

The solution is very stable.

The solution can scale well.

We've found the installation to be extremely straightforward and well laid out.

It's easy to maintain, easy to administer, and easy to see what's going on there. Overall, it's a good product.

Technical support is excellent.

The way the solution provides us with the product and the way we use it gives us what we need. We don't actually have any issues with it. 

There could be a better front-end GUI interface for us, where we can see things more easily. However, apart from that, it works well. 

The pricing is definitely could be cheaper. Also, the support model, even though it's very good, could be cheaper as well.

I've been working with the solution for about 25 years or so. It's a good amount of time. I have a lot of experience.

The product offers good stability. There are no bugs or glitches. It doesn't crash or freeze. It's very reliable in terms of performance.

The product scales well. If a company would like to expand, it can do so. It's not a problem.

It's hard to say who exactly is working on the solution at this time. We have around 30,000 people working on it, in some way or the other.

We've got to keep using it for the foreseeable future. We don't see any reason not to as it provides us with a good solid platform. We have no reason to change anything.

We have found the technical support to be very good. They are responsive and knowledgeable. They are also very friendly. We are satisfied with the level of support we receive. As soon as we raise any issue, they get in touch with us and sort it out. It's great.

We did not previously use a different solution. We started with IBM MQ a long, long time ago and we stuck with it.

The initial setup is not complex. It is a very simple installation. I've been provided with instructions that make the whole solution extremely easy to download and install.

The entire process is very fast. It only takes about 30 minutes to deploy.

We have different departments that can handle deployments. We have about 100 people on our team that can handle this type of assignment.

This is a licensed product. We do pay for it.

While, of course, it would be better if it was cheaper, the service they provide with it, including the maintenance facilities they provide, is very good. We're quite happy. Most people have to use what IBM provides, however, it could be a cheaper license.

We're just a customer and an end-user.

I'd recommend the solution to any organization.

I'd rate it ten out of ten. It really provides everything we need.