IBM MQ Reviews

We are a bank whose core banking system is not so advanced. It is still running on an AS/400 system. Credit Card system is are deployed on IBM mainframes. About 70 to 80 percent of the bank's core systems rely on IBM AS/400 and mainframes. The enterprise service bus is used in conjunction with MQ to break synchronous web service /TCP calls into asynchronous MQ calls and expose them a web services-based or API-based service for both internal and external customers. 

As part of enterprise architecture principles, we have enforced all connectivity to be service/ interface based by using ESB, MFT or API. Minimize the point to point connectivity.

We are using dedicated IBM power/pure-app servers to run IBM Integration Bus, IBM MQ, and WebSphere Application Server. These are the three components being used for the bank's enterprise service bus.

People have started using the likes of Kafka, Spark and other new messaging technologies. But when you take the likes of banks into consideration, which mostly are running on mainframes and AS/400, implementing advanced technologies are not an easy job. Getting an MQ-certified guy is not that difficult in the ASEAN market. There are a lot of certified professionals. That's one of the reasons we still use MQ for most of our messaging. We are still looking at open-source deployments but we have not yet implemented anything like that because of the knowledge GAP & dependency on the existing products. We do not have a dedicated team to take on that task yet.

With IBM MQ still in the bank, and a dedicated team which has expertise in it, we really cut down the time-to-market, from a few months to a few weeks. The development framework is already there. If business comes up with requirements, technology team already know what needs to be done. And by building the in-house team, it gives us the facility where we don't need to ask the IBM guys or other vendors in the market to help us every time we have a new requirement.

Another way MQ has improved the way our organization functions is customer notification. Whenever payments are happening, such as incoming payments to the bank, we need to notify the customer. With MQ we can actually do that asynchronously. There are requirements for notifying customers on a real-time base & also for each and every payment sometimes, once a day. These are be enabled with the help of MQ.

In addition, there are fewer failures during the end-to-end payment process. MQ comes in very handy because we don't lose messages in transit (message persistence). It gives us the ability to store and forward messages when required. We heavily rely on MQ for these kinds of requirements.

Also, we have certain applications that want to receive the messages in both production and the disaster-recovery data center at the same time. Without MQ in the picture, it would have been very difficult for us to configure that. MQ Publish subscribe capability is very helpful in that scenario.

MQ has helped to reduce integration costs, mostly by acquiring the enterprise license of MQ. We can actually set up multiple MQ servers in the same environment and each MQ server is dedicated to a particular application. We also use MQ up to a level where the messages are coming from multiple host systems and they go back to a single channel. When written back, the response goes to the exact host that had sent the request (Message Affinity). Without a tool and without a messaging architecture that is as good as MQ's, it would take a lot of time in hard-coding to achieve that. Prior to the team being set up and having these frameworks in place, it took roughly two to three months to deliver any of these integrations. Now it takes three to four weeks. It has helped reduce the effort and man-hours by half.

We have been using the normal messaging along with channel authorization. 

At certain times — although not in this bank, in my previous experience — we had used the message authorization on top of the queue. That meant that the moment a user tried to write a message it would be authorized before it was written. 

In the ESB architecture, MQ is used to decouple synchronous consumer specific web services calls from the host system calls, by implementing state management. Request and response message matching rely on MQ Message ID & Correlation ID (MQMD header properties).

Message load balancing being implemented using MQ or achieving high throughput, while Message affinity ensures response messages are propagated to the very same host system which had generated the request message.

MQ publish subscribe feature being used to for notification where multiple instance of one or more applications can subscribe to the same topic at different time. 

Message expiry features ensures the redundant or unwanted messages are expired automatically from the MQ based on the settings. This feature is being used at times to ensure no duplication of payments.

Message persistence feature ensures the message availability even after any planned/unplanned downtime.

MQMFT feature ensures files are delivered asynchronously and complete file transfers are automated.

MQ authorization can help to ensure high level of security in accessing the messages from a MQ server or sending messages via MQ channels between two or more systems. 

Day-to-day, I don't really see anything much that we are lacking, but I have never really compared MQ with other products to see what it lacks.

I am well aware of the way that IBM sells the suite of products. But I would like to see it integrate with the newer ways of messaging, such as Kafka. They might say that you have IBM Integration Bus to do that stuff, but it would be great if MQ could, out-of-the-box, listen to public Kafka.

One of the other improvements that I would like to see from MQ is for it to be containerized. It may already have that functionality.

I have worked with IBM MQ for more than 10 years. I started using it in 2006. Recently, in the last three to four years, I have not had any work in the development area. I have moved on to enterprise architecture, so I don't really get a chance to use the solution every day. I haven't used it in the last three years.

I do read up on the new features when I get a chance to read, but I don't exactly have hands-on now-a-days. I now guide the team when they have issues, on things like how to set it up, how to have particular architectures on MQ. I still consult on it and I'm still familiar with it.

It is stable.

We have only had issues with the IBM GPFS File System, but that is a different product. We had an issue when we wanted to have an Active-Active deployment architecture across our production and disaster recovery site. We wanted the same MQ server to fail over to the disaster recovery site and come up from the state in which it went down on the production site. To achieve that we need a synchronous file system that is able to replicate the same data on the other side.

We haven't had any scalability issues with MQ. We are running on a scalable hardware platform with a goal of virtualizing deployment up to multiple cores, and it can add on more and more compute and RAM when required.

For at least the next five years we are sticking with the existing implementation, while we are looking to implement new features, such as containerization.

Our in-house support members are all certified. Most of them have 5 to 10 years of hands-on experience. They don't fall back on IBM for day-to-day support/issues. But if there is a Severity-1, they do log a problem ticket for further expert advises from IBM.

We have only had one issue that I can recall from the last four or five years, to do with the file synchronization. To figure it out, it took a few days.

Overall, the support has been good. As IBM doesn't have a lot of resources in Malaysia, they rely on India or Singapore region for support sometimes.

I am MQ version 6, & 7 -certified solutions architect & system administrator. So I find the setup to be very easy. I have been using MQ since very early of my career, and I was also with IBM for quite some time. So for me, it's very straightforward. The installers come with a nice, quick-setup guide, and most of the time, after the training, users can go set up their own MQ.

The amount of time it would take to bring it to production depends on the scope of the services. If I just have to install MQ, it is not more than an hour. But if I have to install MQ for specific servers, I would probably have to take account of the log size, its location, and what the volume is per day or per week, availability aspects, so it would take a bit longer.

Most of the time, when we implement MQ, we implement it along with other products. It depends on the use case. If you just want to query the server to get the information, I would recommend that to be asynchronous because inquiries are huge in volume. If the use case is payments, it could be defined as synchronous mode, and within the flow we could still break it into two or three parts.

From the design point of view, it is still pretty straightforward, depending on what licensing model you want to go for. If you want to use one MQ server with multiple clients it's doable, but if you have more critical systems running, then you should go for multiple MQ servers so that you have a dedicated server for each particular application. Those are the guiding principles that we use internally for projects to follow.

For deployment, we have written our own scripts. We are mostly relying on AIX/ Linux server. Our scripts are pretty much standard to do things like create/ change queue, channels and it's properties, shut down, restart the MQ services. All these are already scripted, so for our support team it takes them a few minutes to run through them, one after the other, and wait for scripts to be executed.

We have a fully dedicated team in-house to support MQ. There are teams that can help. TCS is one of them and IBM itself is one of them. And there are a few local vendors in the market that are quite proficient in it.

We have a support/ maintenance team of four pax and we are running 200 to 300 services on MQ. The solution doesn't exactly provide a user interface to the business user. The solution is more of a technology layer to support applications and we have 15 to 20 applications that are connected via ESB & MQ.

We have a multi-year OIO (open infrastructure offering) with IBM and if there is any additional licensing required it gets deducted from the OIO. We have been using IBM's other services as well.

We have been looking at some competitors; for example, TIBCO Messaging and MuleSoft from Salesforce. One difference I have seen is that TIBCO is already a containerized edition. I have yet to discuss with IBM MQ if it is available on container. Another thing TIBCO has is that its messaging framework comes with a package for Kafka support as well as plugins for MQ connectivity. It allows you to connect to MQ or to Kafka for messaging.

We are also going to look at the IBM API-led integration. We have been running IBM products for some years so we may want to compare & see how these gets compared with their counter-parts.

Overall, MQ is good, capability-wise. You still need a messaging platform and MQ is quite a reliable messaging platform. I have not seen hiccups using MQ across multiple environments in the bank. I have been using it since 2006 and I have never experienced any issues with the product itself. The guidelines of the product, the way it is used, the way things are done, are pretty self-explanatory. There are multiple blogs/ online helps available and there is a lot of help available from experts around the world.

Have a look at the features. If they complement the requirements you have, go ahead with it. If you are very technical and want to understand more about the open-source tools and features, that may require a notable learning curve.

The product has been around for a long time. It's probably time to see what MQ is going to add to its features. We have not started using IBM Cloud Pak with Red Hat OpenShift yet. We are also looking at using containerization but probably it may take some time.

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.

I worked as an employee for a bank where we recommended IBM MQ, and we used it.

It's for real-time messaging, an exchange between applications.

On the IBM side, we use Message Queue, all the Message Queue products from IBM. For six years, we used it for a bank, an international bank, and we integrated all the applications synchronously using Message Queue.

IBM MQ is highly scalable and has a reconciliation mechanism. These are the two main reasons we use IBM MQ. 

IBM MQ should have more extensive documentation because I couldn't find a lot of information on the system API side to help us monitor the message queuing. 

I would like to see more documentation.

I have been using it for six years. We used it for a bank, an international bank, and we integrated all the applications synchronously using Message Queue.

It has been a stable solution. 

It is a scalable solution. 

The customer service and support have always been great.

Positive

I know there are competitors like RabbitMQ and Dell Boomi. I believe RabbitMQ is built on open source and they have a licensed version as well. I don't know much about RabbitMQ or Dell Boomi at this point.

IBM MQ is highly stable and quite customizable to integrate with our systems.

We definitely installed using a service provider, and it's not that complex. It's easy. It took three to six months to start implementing the first use case. 

Around six to ten people were involved in the deployment. It is easy to maintain and stable.

The ROI is  good, but we only used it for a few use cases like banking customers. It's quite stable, so we got the value out of the installation.

I would rate it an eight out of ten. It's expensive, not cheap.

I would like to rate it as a seven out of ten. It is quite stable, but it needs to have more documentation, and that is why I rate it as a seven out of ten. 

At this moment, we don't see a use case for implementing AI, but it is definitely in our roadmap. We will definitely try to find a use case to implement any new features that get announced.

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.

IBM MQ could improve capacity, monitoring, and automatization.

I have been using IBM MQ for approximately 22 years.

IBM MQ is a stable solution, it is used mainframe computers and it is secure.

The scalability of IBM MQ is good.

We have approximately 100 people using this solution in my company.

The support from IBM MQ is good.

IBM MQ has a complex setup. The time it takes for deployment take approximately two to three months.

We have a special contract with IBM MQ that give us a certain price.

I am satisfied with the solution overall.

We have five to six people for the maintenance of this solution.

I rate IBM MQ an eight out of ten.

IBM MQ is used to ensure that transactions are properly handled.

The most valuable feature of IBM MQ is transaction processing.

I have been using IBM MQ for approximately 10 years.

IBM MQ is stable.

The scalability of IBM MQ is good.

We have only customer transactions using IBM MQ.

I have used the support from IBM MQ. There is some room for improvement.

I rate the support from IBM MQ a four out of five.

Positive

I have not used another solution prior to IBM MQ.

The initial setup of IBM MQ is complex.

The price of IBM MQ could improve by being less expensive.

I rate the price of IBM MQ a three out of five.

I choose IBM MQ over other solutions because of personal comfort.

I would recommend IBM MQ to others that are using major transaction processing.

I rate IBM MQ an eight out of ten.

I use IBM HQ to communicate with subsystems within our plants e.g. the supply chain.

I've been using IBM HQ for eight years.

IBM HQ's stability is great - we send six million messages a day, and we're very satisfied with HQ's ability to handle that volume.

IBM HQ's scalability isn't the best.

IBM's technical support is great.

The initial setup was straightforward and took around half an hour.

We used an in-house team and a system integrator.

I would absolutely recommend IBM HQ to others as a very robust, reliable, responsive product. I would give IBM HQ a rating of nine out of ten.

We use this solution locally and work in port authority where we deal with multiple parties like warehousing, containers, customs and Egyptian customs. Therefore we can communicate with each other and achieve middleware goals. We use the MQ Server and MQ client in each party and control it with the MQ server in port authority.

The product has allowed our organization to deal with all parties, like containers and warehousing. As a result, we can deal with these parties, exchange messages, and achieve our goals.

We have found the security and monitoring capabilities of the product most valuable. The product helps us monitor messages with other queues, view duplicated messages and control undelivered messages so they can be stored in pack-out queues and restored. We like more than one feature in MQ as the product is secure. For example, we can exchange messages between all parties with a stake and have control of undelivered and unrouted messages. Furthermore, with a scheme of validation, we can report access.

The dashboard is handy because we use it to monitor the messages and know how many messages are delivered to parties' dashboards. For example, we can notice how many letters are delivered, how many messages are undelivered, and how many messages are brought incorrectly by the dashboard. However, it would be great if the dashboard had additional features like a board design or picture management features.

We have been using this solution for over six years and are currently using MQ version nine.

The solution is stable.

The solution is scalable. Over ten parties, with 10,000 people, are using this solution in our organization, and two employees are required for maintenance. One employee is a system analyst, and the other is an integration developer.

I rate technical support a ten out of ten.

Positive

We did not previously use any other solutions.

The initial setup was straightforward. It was easy to install and configure.

The deployment was done in-house.

The product is good, and our organization has used this product for more than ten years.

The licenses for our company are according to port authority contract sales and we buy a license for six months or one year. I don't know the exact costs of the licenses.

I rate this solution a ten out of ten because we have no issues with it. The solution is good, but improvements could be made to the dashboard.