What is our primary use case?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
We've been using the solution for a very long time. It's been at least a decade - about ten years.
What do I think about the stability of the solution?
The stability of the solution is good. We've never run into any issues.
What do I think about the scalability of the solution?
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.
How are customer service and technical support?
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.
Which solution did I use previously and why did I switch?
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.
How was the initial setup?
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.
What other advice do I have?
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.
Which deployment model are you using for this solution?