IBM MQ Reviews

I'm a technical specialist and we are customers of IBM. 

This solution offers good performance as well as scalability and stability. It offers a template that's beneficial for any company.

I'd very much like to see more integration in the monitoring tools.

I've been using this solution for nine years. 

The stability is good. 

The solution offers very good scalability. 

The initial setup was straightforward. It's all about planning because we have multiple application teams involved. Deployment takes somewhere between half an hour to an hour, but for the coordination to check and perform from the application side, takes almost a full day because we have critical, multiple applications. It needs to be coordinated and we need to be sure they are able to connect perfectly with our environment or with the MQ.

We pay an annual license fee. 

I recommend this product and rate it a nine out of 10. 

We are mainly using it for communication, for connecting to multiple systems. Applications are putting their messages on MQ and, from MQ, we are reading them using IBM Integration Bus. We then process them and send back the response.

The MQ protocol is widely used across multiple applications and it's so simple for connectivity. 

Other valuable features include the 

• messaging format
• message persistence
• security features, including several connection channels and name-based and user-based authentication.

I had some issues earlier, two, three years back. I don't exactly remember them now.

I have been working with IBM MQ for eight years. We are currently trying to implement IBM MQ on OpenShift and cp4i. We have MQ on-premises and we are trying to migrate it to OpenShift, a container platform.

Stability-wise, it's very good. People have been using it for 15 to 20 years. MQ and IIB are the most stable products from IBM.

We can scale up and down anytime. There are no issues there. We have 20 to 30 internal applications connecting to middleware and all of them are connecting using the MQ protocol.

We haven't had major issues, but whenever we have had an issue we have written to IBM and they have gotten back to us on a timely basis.

The setup is straightforward. There is not much to create, it's a one-time setup, including configuring the high-availability. That is the main thing. The parameters create the queues. It takes about 10 to 15 seconds for each queue.

In addition, we had IIB, the IBM Integration Bus deployment, including message flows and DB scripts, etc. So the deployment was not only MQ. In deploying IIB flows, we had some queue creation, server connections, and channel creation. Overall, it was about 80 percent IIB deployment and 20 percent MQ deployment.

We had two people involved: one guy from the support team and one guy from admin. For maintenance, in the sense of the application support, we have four team members but we are handling multiple applications, not only MQ.

We deployed it ourselves.

Although I'm not involved with costs in our company, IBM products, in general, have high licensing costs and support costs are too high. A lot of people have started using open-source, like Kubernetes and microservices. There is also Apache ActiveMQ. There are many other products out there.

I would tell people to use this, except that the pricing and support costs are too high.

I would rate MQ at eight out of 10. 

We have a diverse distributed environment that includes Z/OS, Microsoft Windows, Solaris, Linux, and zLinux. We use multiple programming languages and different databases.

IBM MQ was found to be easy to implement and operate. It became the defacto standard, and integration problems moved from an operational issue to application solutions.

The most valuable features are the point to point messaging and the MQ API. This solution is simple and very diverse.

I would like to see faster monitoring tools for this solution.

We use MQ as part of the core of our enterprise information bus. We started that journey in 2009. We have it both on the mainframe and in the mid-range. For us, by allowing messaging to integrate with some of our third-party solutions, like for web banking and so on, we are able to create an information highway that took in the legacy events, captured ATM and credit card transactions, and integrates that into a digital web dashboard.

It provides a better customer experience and more timely access to data.

There could be better APIs around cognitive analytics, around how the messages are flowing. For example, plugins to Watson. That would be useful.

Stability is rock-solid.

It is highly scalable.

Technical support has been good.

I was not involved with the initial setup.

You need to have the right use case to support that type of data and flight paradigm. If you do, there are third-party open-source solutions that a lot of vendors have embedded into their products that you have to integrate with. This gives you a really good platform to do that. So, if you don't want to put something in that isn't as robust or scalable, you don't have to. You can rely on this to be the conduit and the glue for your messaging fabric.

It's also really good at asynchronous logging. A lot of times, when you buy these turnkey solutions for whatever vertical, they often don't have robust logging and security. So, we use MQ as an underpinning to get that for us and we have written services within our system that take advantage of those capabilities. So, even if the vendor doesn't provide it, we have it.

When selecting a vendor, stability and security are the most important. Price is also important. But, in banking, because it's mission critical and highly sensitive, stability is probably way up there. If messaging fails, we don't make money.

For the IBM MQ solution, the most valuable feature is the interconnection of data between the different systems. In our company, we use mainframe, Windows, and Unix and it provides communication with different plans like associations and the federal employee plan. That's what we're looking for.

The main feature right now that we're looking for is open source and that is where we see more challenges coming up with the product. This is because a lot of the applications are going with open source such as cloud and providing connection with the cloud. We have Amazon AWS cloud services or Microsoft Azure services and the applications are deployed there, so connectivity with those type of applications is necessary.

IBM MQ has broadened a lot of communication between interconnecting the applications. It's more fault tolerant, since we have the message delivery guaranteed. We have high availability for the application and it's not stateful. It has provided the features such as the application to process messages from the mainframe as well as from the web, so we can increase the throughput of the system.

The response time could be improved because that's our main concern. Once our system is down, then it impacts our business since we have another partner who is dependent on us.

There is need for more integration with cloud. That's what we're looking for, because that's what the company is moving towards.

The stability is very good, actually. In our organization, we saw almost 99.9% uptime for the product.

The scalability is really good, because only your system limits the functionality. We can add more storage / more memory and we can always scale up.

We have used the technical support, but we are more concerned about the response time. For example, we have severity 1 issues and the system is down, but we still see time gaps and they don't respond.

Previous, we were using the Oracle Tuxedo solution and it had a lot of limitations. It was not able to interface with a lot of the other systems, i.e., the interface was only with C-based operating systems/programs that use only Windows. That's why we switched to IBM MQ, since it brought a lot of benefits.

The setup was complicated because when I started and there were around 400 queue managers. We have four companies that we communicate with, so we changed a lot of the architecture, i.e., we went from the local queue managers to centralize and to reduce issues, in order to have a more manageable system.

Actually, we looked at IBM and Microsoft. However, IBM had a wider scope of the product, and compared to it, Microsoft provided limited platform support. That's why we chose IBM.

The factors that we look at before selecting a vendor, are how the product supports integration with other companies and the overall support they provide to us.

Definitely, you should use IBM MQ because it is a stable product and provides a wide interface with different systems. You can talk to mainframes on other systems as well, so I would highly recommend this product.

So far, it's helped us with our Maximo integration between the users and the database administrators. I know we kind of lagged behind on some updates, which caused us problems. We recently upgraded, which had made things a lot easier, got rid of some of the issues we had with the older versions.

It helped us with some of our security, on some of our roles, if I remember correctly. It helped us integrating; we’re trying to move a bunch of different things, like trying to move EZMaxMobile into our Maximo and a few other things. Part of that was bringing up WebSphere to the newest version for all the integration.

Off the top of my head, I can't really think of any features I’d like to see in future versions. Right now, I don’t have any improvements to the version we’re using. We just upgraded two or three months ago, and we're still getting it all set up.

The configurations were not difficult, but like I’ve mentioned, again, I believe when they went through the integration, they talked to IBM to make sure that we're going to go through OK. So, there was some interface back and forth during the upgrade.
We’re happy with the user interface, so far.

Getting more analytics coming out of MQ is something we're working with across the board with everything, with our Maximo data, with all the applications we have. We get tired of having to pull reports and somebody has to manually crunch the numbers. We need something behind the scenes tabulating everything and coming up with answers, so we don't spend all our time just collecting everything. If there would be an integrated tool that would give us reports, that would be amazing.

With the newest version, we haven't really had any stability or scalability issues. I guess that's a good thing.

With the previous versions, it was just that we were a version behind on what the version of Maximo and everything we were using, so it was causing a few little glitches and buggy issues.

We frequently use technical support. They have been pretty good, so far.

We knew we needed to invest in a new solution mainly because of the issues we were having with the old version; it was pointed out that they were going to be fixed by the new version, so that was kind of a simple thing.

I was not involved in the initial setup with this current version.

We were already using WebSphere MQ, so we didn’t look any other solutions.

Don't be afraid to call. If you're worried about tackling it all on your own, don't be afraid to call IBM or call somebody that's already gone through the process and get some help, because we're all willing to help; you just have to ask.

I have not given it a perfect rating because there's always room for improvement. I can't give them the improvements; they have to figure that out. It works really well but like I’ve mentioned, with the way everything's changing and developing every day, you always have to be on the lookout for what's coming up next.

In general, when I am looking at vendors, the number one criteria is responsiveness. Number two is time frames and that they meet the schedules. Those are our two biggest things. We've had issues with other vendors in the past with those same things.

The major thing we like about it is zero transaction loss. The other thing, which is a plus point, is first in, first out (FIFO). You can be pretty sure that if MQ goes down for whatever reason, the transactions will still sustain; they won't be lost. There is a drawback when, once a transaction touches the other point, it is lost, in the sense that if you don't process it, but that is fair enough.

There is a good user interface. It is a very good way of interfacing two systems. For example, in our case, the central bank clearing systems interface our systems using MQ. It is seamless. I did not face any problems. Initially, when you do the setup, you have to be careful and configure it properly. Once you do that, it is OK.

It should be able to keep a copy, so that if there is an accident, we would still be able to record the transactions. Maybe processing could be faster, in terms of EPS.
If you consider migration from one version to another, that is an issue and then initial configuration is challenging; when we change the version or change the server.

We never had stability issues. The issues are there only when you are configuring for the first time. Once you get the right configuration, then you can actually forget about the fact that there is MQ.

We have not had any scalability issues.

I have used technical support once in a while, such as when we are upgrading or when we are going to change the server or something like that. They are pretty good. In our part of the world, it's pretty good support.

Interfacing is required in any situation when you have two systems talking to each other. So, there are not too many options. One, is that you can have a file handoff. You can have MQ messaging. Or, you can have an API. So, we currently prefer API, so MQ is slowly losing its position.

Sometimes I am involved in the setup. But, now my people have become experts setting it up. There are issues that happen once in a while. For example, last year it happened when we changed the server. For whatever reasons, the configurations were in fact reset. So we brought IBM in. Those were complex configurations. For whatever reason, a couple of parameters could not be reset. Or, they didn't remember which parameters to reset.

As far as MQ, we only looked at IBM. There are many open-source products available now, like IBM MQ Plus. IBM is coming out with something called IBM MQ Plus Plus. Obviously we have not gone for it, but those are the competition.

MQ is also closely integrated with the broker; internally, it is now an API. There is a close connection.

When selecting a vendor, full scale support is important and technical acumen. If I'm asking a new question, he should be able to resolve it or at least give me direction. I also want timely support. If my production goes down at 12 o'clock in the night, there should be someone to talk to me. I think IBM has very reasonable support, so it helps. Worse-case scenario, you could call and expect an answer within the next one or two hours.

Do the first configuration really well. Maybe involve IBM right from the beginning.

Our primary use case for IBM MQ is as an enterprise messaging between applications. So when applications need to transmit data from one to another, they use a messaging broker, the IBM MQ, RabbitMQ and ActiveMQ.

We have found the MQ messaging topologies valuable mainly the published, subscribe and direct messaging. A feature that no other market could offer at the time was data-addressed encryption.

The clustering model can be improved to allow consumers to consume from all brokers simultaneously. Currently, the issue is that they're using a very old clustering model where several of the individual brokers in the same cluster still behave as individuals rather than behaving like a cluster. They call it a cluster, but it's just a group of brokers not working as a cluster. It doesn't properly share the resources between all of the member clusters. Compared to other solutions like Apache Kafka, or RabbitMQ, this is a huge drawback.

We have been using the solution for approximately nine years, deploying it on public, private cloud and on-premises.

The solution is stable.

The solution is not easily scalable. 

Technical support is tough to connect with because the training and documentation from IBM are awful and the technical support from IBM is also poor. So it's easier to solve your issue using Google rather than calling support at IBM.

The initial setup was a bit complex. The installation itself can take anywhere from half an hour to four hours, and the configuration could also take a couple of hours, depending on the complexity of the design.

The solution is expensive.

I rate the solution an eight out of ten. The solution is good, but the clustering model can be improved. My advice to others considering the solution is to check other products on the market and ensure their product of choice complies with everything they need. They should go for IBM MQ but ensure they carefully read the terms and conditions and view the price beforehand. Alternatively, if they want to go with a more lightweight solution that is just as reliable, they should review RabbitMQ.