IBM MQ Reviews

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 using the solution for taking messages off the mainframe and distributing them down to a large, high-performance computing environment supporting over 4,000 servers.

The most valuable features I have found to be the message queue itself and its ability to bridge between mainframe type services to distributed services.

The clustering capabilities have provided some difficulties when it comes to resiliency. This has been a challenge for managing the environment.

I have used the solution for approximately 15 years.

We had stability issues with the solution. I would be looking at replacing the product, but I am not in charge.

I was not on the team that was on our internal MQ for support but I know IBM support services are really good. While I have had some issues and long nights supporting IBM software in my 33 years of IT, the support personnel are good. I always say good things about them. It is not their fault that their products come up short, but they do a good job at supporting customers.

The installation was straightforward until we started to have resiliency problems, it then became more complex to have to set up clustered MQ servers. We were using Linux Red Hat cluster services, which became an extra burden. When it eventually came time to do other activities, such as updating the operating system or a specific driver, for example, a firmware driver for the bare-metal servers themselves, having the MQ's clusters being sensitive caused a challenge for service and support.

The solution costs are high, it is going to cost a fair bit for annual operating costs and support.

I would advise, if I was the person in charge, I would tell my architecture team, "Bring me three other MQ-type solutions and do a POC to see if we can get better performance, resiliency, and reliability at a lower cost."  I guarantee there are solutions out there that can do just those three things.

I rate IBM MQ a six 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.

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.

We use it for application-to-application integration.

Reliable messaging and throughput are the most valuable.

We are looking at the latest version, and we hope that resilience, high availability, and monitoring will be improved. 

It can have some more improvements in the heterogeneous messaging feature. The current solution is on-premises, so good integration with public cloud messaging solutions would be useful.

I have been using IBM MQ for 20 years.

Its stability is great.

Its scalability is okay. The inside scalability is great. We are hoping that the outside scalability is improved in the latest version.

Most of the users are just using the applications, and they are using IBM MQ without realizing it. In terms of the number of people really dealing with IBM MQ on a global scale, there are probably around 30 users. They are actually working with the product. There are thousands of developers who are using applications with IBM MQ.

I am an architect, and I talk with the architects of IBM. The engineers talk with technical support when needed.

The basic setup is simple. The deployment is fully automated.

We received the software from the vendor, but we deployed it on our own. We also do the maintenance ourselves. 

There is real money involved here. As compared to RabbitMQ, IBM MQ is on the higher side in terms of cost.

I would recommend this solution for similar companies. I am very fond of IBM MQ because of the reliability and throughput part, at least on a single server. On the consumer and application side, RabbitMQ seems a bit easier to consume. It is a bit ahead in terms of the scale-out feature.

I would rate IBM MQ an eight out of ten.

We develop applications for 20 companies in the insurance industry. We have about 20 different product systems that use the same MQ layout. 

We are also using it for testing and educational purposes.

Our customer base is in the closed market of Switzerland and Liechtenstein.

We just switched versions from 8.0.0.6 to 9.1.

Most European companies have MQ, though we just added it four years ago. MQ changes the way people think about their applications. E.g., they are more integrated. We see synergies with the tool, but there is a long path to changing people’s minds.

The MQ layout is quite easy.

It is very stable. We don't have many issues.

We have had an issue with the migration. Most of our applications are running on Java and WebSphere. We have a project to get rid of an old .NET application since we are experiencing a loss in connection during the migration to 9.1. The problem appears to be more on the .NET side than the MQ side though.

The technical user interface is outdated in terms of the language used. I think this is inherited from the mainframe. This is more of an engineering issue. It is running on a Windows platform, and I don't like having Windows being the backbone of our company.

I don’t like legacy view of MQ.

Four years.

We don't have a problem with stability.

We have not had any large scalability issues. The business that we have is not that big. In Switzerland, we have around 3,000 people working with all our systems. We don't have that many transactions. For our 20 customers, we have four servers in production with two on standby and two that are active. We need scalability mostly to run large printing jobs for MQ, where we need disk space. Overall, we don't have any scalability issues.

This solution has improved and influenced the communication between different applications, then standardized that communication. Before, we had a lot of different interfaces, which were partly handwritten. Now, we have two or three manned technology with MQ that are automated. Therefore, we are focusing and reducing the amount of technology.

For some special parts, we also had something previously in place. We ran around 100 to 1000 PDFs in a batch mode.

We have a standardized way in describing our servers, services and rights because we have our own infrastructure. We just generate the MQSC scripts, then push it to the right server.

The time it takes to deliver a new integration varies. From our point of view, we are really fast, but we do not develop applications on our own. We are a type of project management and system provider company. This means that most applications are written by different companies. E.g., we have IBM as a software supplier.

Two people from our company maintain the solution along with a consulting company that we have. All this is done part-time.

Our costs haven't increased but they also have not improved.

We are happy with it. I would give it an eight (out of 10). 

We are not using containers.

IBM WebSphere MQ is deployed on a Windows machine, as well as almost all of our infrastructure. Windows services read and write to the MQ server - this is the way that we interact with it. All the messages that we put on the queue are also stored in an SQL Databases. A Windows service reads that message from the SQL Database storage and puts it on a queue on a certain channel; these Windows services are running indefinitely, on a loop so any message is read instantly. 

The solution is very easy to work with.

The solution is very stable, it also offers transaction management and support.

The solution offers very good integration with other services. It's one of the great advantages of the service.

We have had it for a long time now - version 7.1, which is not the latest. 

The admin interface of MQ Explorer that is used to interact with the server seems a little bit dated. It makes it somehow difficult to interact with it. It needs a major update to make it more modern and easy to navigate, maybe a web version.

The solution isn't free. There are other solutions, like RabbitMQ, which are open source and absolutely free to use. This open source solution we use it for non-critical processes.

IBM offers a special version that you need to get if you want to transfer files, especially large files. Maybe it should be included in any version.

We've been using the solution for a very long time. It's been at least a decade - about ten years.

The stability of the solution is good. We've never run into any issues.

IBM MQ offers clustering. We don't have this yet, as it hasn't been implemented, however, I know that you can install it in a cluster of servers. 

My understanding is RabbitMQ is also easier to scale. I'm unsure as to how well IBM can scale in comparison.

I've never contacted technical support in the past. I can't speak to their level or service due to the fact that I've never directly dealt with them.

We're also using RabbitMQ. While IBM is more stable, RabbitMQ is easier to work with. 

We've been trying to change our architecture, and RabbitMQ is more appropriate for us as it's easier to put together with microservices.

While I was part of the process for implementing RabbitMQ, which was very simple and straightforward, in the case of IBM, I didn't install it myself. Unfortunately, I cannot explain how easy or difficult it was as I was not part of the experience. My understanding is it's not too difficult.

In terms of maintenance, we have two people from the support team handling that aspect. They can restart the server or look into the queues. They aren't working in shifts, however, if there are issues, one of them is normally available to troubleshooting.

In comparison, for RabbitMQ, we had only one developer that installed it and created the publishers, workers etc. I believe the support will be the same as for IBM. In both cases, there aren't too many people needed for maintenance.

I'd recommend the solution. It's a very stable solution and very resilient. 

If there is not essential data that needs to be transported between services, then I would go for a RabbitMQ, because it's easier in style, and it's free to use. On top of that, you can have it to wrap around everything in a straightforward way.

That said, I'd rate the solution nine out of ten. We've used it for a number of years and it's always worked very well for us.

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.