IBM MQ Reviews

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.

I work for a company that has an ESB backbone built on the MQ. It's the enterprise bus for the whole company. I was a trainer for IBM products long ago, but I moved to different companies and now I'm a senior developer supporting MQ and IBM. 

I like the MQ's simplicity and rock-solid stability. I've never experienced a failure in two decades caused by the product itself. It has only failed due to human error. 

I started using MQ on a mainframe, so I understand the thinking behind it. However, there's a lot of legacy stuff lagging behind. I think a start-up company might find the approach to be outdated. 

IBM could revamp the interface. The API is huge, but some developers find it limiting because of the cost. They tend to wrap the API course into the JMS, which means they're missing out on some good features. They should work a little bit on the API exposure.

Support utilities are almost non-existent. MQ is dependent on third-party companies. I write everything I use, like a Linux-based command line interface for all admin stuff. 

I started using MQ in 1999, so it has been around 24 years.

I rate IBM MQ 10 out of 10 for stability. I can configure the topology on my laptop and copy identical stuff into a multiple mainframe configuration.

Setting up MQ is straightforward. Generally, installing MQ isn't a big deal. It's a simple product. The magic happens when you go configure the topology and do some performance tuning.

I work for a huge company, so the deployment is done by DevOps. We're on the application side. The installation was dodgy in versions 5 or 6, but now you just drop a container.  We try to automate as much as possible, so we wrote extended Jenkins jobs to flash install all the virtual machinesWe don't deploy MQ on the cloud, but I'm thinking of migrating it to Azure. I see no benefit in a private cloud. 

IBM could lower the price because many companies are abandoning MQ from Mickey Mouse products like RabbitMQ and Kafka. Kafka is horrible but free. 

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 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.

We are an integration company, so we deal with many software systems that aren't necessarily online all the time. Using MQ helps us by keeping a storage of the messages sent from one party to another so that once the second party comes back online, it will take from the queue. It is used for integration and middleware purposes.

I really like the SSL support in MQ, which allows us to include certificates so the queue is fully secured and prevents man-in-the-middle attacks. It is easy to create a new queue, and the queue manager connecting to the remote queue works smoothly once the IP and port are included. These features benefit us by ensuring integrity and security.

The software has many complications, especially with authorization on the queue. I had many issues with unauthorized errors and editing this authorization and giving users the right authorities on the queue was really hard. 

Another improvement could be the inclusion of more advanced queue features where you can configure a queue to push messages to consecutive queues automatically. 

Better error handling, such as a default dead message queue for errors, would be beneficial.

I have been using it for about three months now.

I have used IBM MQ with IBM ACE, and sometimes there are issues with messages in the queue not being taken by the message flow. I am unsure if this is a problem with ACE or MQ, however, it sometimes affects stability. Thus, I would rate stability at six out of ten.

It is very scalable since it handles the concepts of message queues, the most scalable technique in integration development. 

It allows for scalability and reliability by adding multiple queues and ensuring messages don’t get cluttered. It is very scalable, ten out of ten.

I didn't need to contact technical support. 

Positive

The usual solution was HTTP requests, and MQ is much better. It is more complex, however, we get persistent storage and the messages don't get lost if the other party is not online.

The pricing is very high, but if it's going to be used by an enterprise or a large company with thousands of users, it will be very convenient. However, for personal use, it's not a good idea.

I would recommend IBM MQ for companies. If we get a new IBM client, we will definitely recommend MQ because it will facilitate a lot in its request handling. For a legacy IBM client who is not using MQ, we encourage its use because it will improve architecture significantly. 

Overall, I rate IBM MQ at nine.

We mainly use IBM MQ when creating the integration buses for different customers. For example, for creating external API for the internal systems, we use IBM MQ quite extensively.

The interface is good, and we work using API functionality in the main part of our projects. The solution is easy to understand and even medium developers can easily start using it.

More documentation would be good because some features are not deeply implemented.

I have been using the solution for more than ten years. 

It is a stable solution. I rate the stability nine out of ten.

The solution is highly scalable. We have a number of projects with more than one hundred thousand users. I rate the scalability ten out of ten.

The initial setup is easy. If the required access and permissions are provided, the deployment takes one day or less. But in most cases, we wait for some permissions or access to systems to finish the deployment on the customer site. One DevOps employee is enough for the deployment.

I rate the initial setup an eight out of ten.

The pricing seems good according to the functionality that the solution provides.

It is a very stable and scalable product and is a market leader in its appropriate sector. I rate the overall solution an eight out of ten.

The primary use case of this solution is for the general merchandising and retail market.

From the infrastructure point of view, it's a great improvement and it's more flexible to the latest hardware. Also, it is flexible for whatever is coming or whatever is available for on-premises and cloud integrations.

The most valuable features are RDQM and queue sharing.

There has been a lot of improvement in architecture. It handles better with the new architecture such as Cloud, and Cloud-on-premises integrations.

Also, how Kubernetes can be deployed is helpful.

I would like to see message duplication included. We don't have a mechanism for duplicating a message.

There is a different model where you can have multiple subscribers and not publish the stored data to multiple subscribers. 

Duplication is the most important for sending the same data for different applications.

We have been using IBM MQ for 15 years.

We are using 9.0.0.6 and in the process of upgrading to 9.02.

In terms of stability, IBM has proven to be very rare. It's a very stable product.

We test in very large volumes.

We tested ActiveMQ and it's nowhere close to IMB MQ.

Scalability is an area that has improved a lot. The scalable data is different. 

The way the cluster handles and cluster load balancing is different than what it used to be.

Now with the uniform clusters, it's much better. There is a lot of competition especially with messaging. With streaming, people are using it for messaging also. 

It's very flexible to scale.

We have been using it for a long time. We have a team of 15 people who are using this solution. There are more than 5,000 integrations that are using this solution in all platforms, such as Mainframe, Windows, and Cloud environments.

Tech support is very good. I guess other support groups if someone is looking for ADP accounts it lacks but in general technical support is good.

I would rate them a nine out of ten.

Previously, we did not use any other product. I am not familiar with other technologies.

I'm learning and doing some experiments, but we have found a  product for the volume we have.

The initial setup is straightforward, it's easy.

If someone knows its basic structure, it is easy, but the open-source is much easier than IBM MQ because you just have to install it and start working on it. With IBM MQ you have some installation procedures.

The open-source version needs route access which could be security compliance and could be complex.

IBM is expensive.

I would recommend this solution and suggest you start using it if you have the budget. It's very stable and robust. It's a proven technology, so no one needs to worry about that.

It all relies on the budget, that where all of the problems are. People want to use open-source, and businesses do not have a budget.

It's a good product to use.

I would rate IBM MQ a nine out of ten.