What is our primary use case?
We have a core banking application. If any system or application wants to talk to the core banking application, the request and the response will go through the MQ servers. The requests and responses are in the form of XML.
We have a VMware environment with Windows and Linux.
How has it helped my organization?
We have clients spread all over Africa and they have to process different types of requests, such as credit requests and debit requests. We use the Queue Manager to handle these requests. Our MQ server will accept the request and send it on to our core banking application.
If you imagine the order from left to right, the application is on the left, then the enqueue server is in the middle, and the core banking is on the right. In between the queue server and the banking application, we have APIs and systems in place to understand the XML files.
What is most valuable?
The most valuable feature is the Queue Manager, which lies in the middle between our application and our core banking server.
Managing this solution is not difficult.
IBM MQ is very stable, which is important for our core banking application.
What needs improvement?
The memory management is very poor and it consumes too much memory. We have 24 gigabytes of RAM and almost every day, we had to free up processes so that it can run.
Some of our messages were not being transmitted so we had to manually look at the MQ server to cut and paste them. That is supposed to be fully automated. The problem is normally a routing issue but it is compounded if there are connectivity troubles. For example, if 3,000 messages are supposed to be sent but 1,000 were not then you have to do it manually.
The solution is not very lightweight and if it could be decentralized, then put into three or four containers, it may be an improvement in this regard.
For how long have I used the solution?
I have been using IBM MQ since 2015.
What do I think about the stability of the solution?
The MQ service has never gone down and has never failed us. It is only offline when the VM is offline.
What do I think about the scalability of the solution?
This is a scalable solution. We scale by adding another VM to our cluster.
We have eight engineers who are using MQ, but in terms of end-users, or people who are consuming the services, there are thousands or millions. It is an enterprise-level organization and each application has a user base, so the scale depends on the application.
How are customer service and technical support?
I have never had support for this solution.
Which solution did I use previously and why did I switch?
As far as I understand, we did not use another solution prior to IBM MQ. Our old strategy did not use this type of technology.
How was the initial setup?
The initial setup is very straightforward. I have done it both on Linux and on Windows. With Windows, it is just a case of hitting the "next" button. I would say that within ten minutes, you should be finished with the installation.
Prior to the installation, you have to make sure that you have Java installed.
What about the implementation team?
I deployed this solution for the company.
The number of people required for maintenance depends on the environment. We used to have one person manage each application that was connected to the MQ server, which meant that we had four people maintaining it.
What was our ROI?
It is difficult to assess the ROI for this type of solution.
What's my experience with pricing, setup cost, and licensing?
IBM MQ is expensive and they charge based on the CPU.
Which other solutions did I evaluate?
I am familiar with a couple of similar solutions, including Red Hat AMQ. In fact, I am trying to migrate to Red Hat. It is very easy to install and get it running. All you have to do is get your API and you're done. Stability-wise, however, with Red Hat AMQ, I have seen cases where some of the messages were lost. IBM MQ is definitely more stable.
What other advice do I have?
For the most part, this solution serves our purpose. It is not difficult to manage and the only challenges we have really had were to deal with some of the messages manually.
My advice to anybody who is researching this solution is to consider costs first. It is expensive and you have to ask what value you are going to get from it. You need to consider factors like how many messages you are sending per day. If your budget is sufficient then IBM MQ is your choice, otherwise, you should look into a cheaper option. Also, if stability is the most important thing to you then IBM MQ is the choice that you want to make.
I would rate this solution an eight out of ten.
Which deployment model are you using for this solution?