Share your experience using Avora

I use MQ MFT for asynchronous communication – file and message transfers. I also frequently use IBM MQ for its queuing mechanisms and queue management.

IBM MQ is good for system integration within our organization. 

If we need to do batch metadata transfers – involving APIs and MQ – we can do that as long as the source and target systems support MQ. 

However, for anything without MQ, especially when we need asynchronous communication, we have to rely on custom-developed services. It's like that.

The performance is good.

I appreciate the level of control we have over queue managers, queues, and the messaging itself. That provides good security.

So, the control and scalability of messaging are important to me.

Moreover, it is more reliable than other queuing mechanisms we've tried – things like ActiveMQ, RabbitMQ or embedded queues. We have more confidence in not losing data with IBM MQ.

So, I find IBM MQ to be a reliable solution.

We find it scalable for internal applications, but not so much for external integrations.

It should support a wider range of protocols, not just a few specific ones. Many other products have broader protocol support, and IBM MQ is lagging in that area.

IBM MQ needs to improve the UI for quicker logging. Users should also have a lot more control over logging, with a dashboard-like interface. That's something they should definitely work on.

It's been about three to four years.

It is a stable and reliable product. I would rate the stability a nine out of ten.

It's very scalable. We can allocate more queue managers based on our use cases.

I would rate the scalability a seven out of ten. There are around 20 end users in my company. Their job roles include developers, consultants, and architects.

However, we don't use it extensively, so no plans to increase usage.

There is room for improvement in the customer service and support. 

IBM MQ should offer more extended support to users, and their response time could be faster. They have a community forum, but the official support channels could be improved.

Neutral

We have it on-premises. We're not using it on a public cloud currently, but it can be deployed there.

The initial deployment takes hours. There's a lot of manual scripting involved. So, Ideally, some kind of automation for that process would be helpful.

IBM's licensing model seems more reasonable than some competitors. They charge based on usage, which is good. 

However, the pricing could still be a bit lower. Their installation-based licensing model is acceptable, but other products might have an edge in terms of cost.

I would recommend it, but it's important to be aware that many users are shifting towards cloud-centric solutions like Kafka.

Overall, I would rate the solution a seven out of ten.

During my tenure, there was a transition to using IBM MQ due to its compatibility with IBM mainframe systems, which was beneficial for projects involving message queuing systems, particularly for clients like Volkswagen. I've handled various tasks related to IBM MQ, including testing connections, configuring and installing the system, setting up high availability and disaster recovery solutions, and providing administration support. Additionally, I've conducted training courses on IBM MQ.

One of the most crucial aspects for us is ensuring no data loss, and IBM MQ excels in this area, especially in banking environments where reliability is paramount. The feature I find most effective for ensuring message delivery without loss is the backup threshold. This feature allows for automatic retries of transactional messages within a specified threshold. For instance, if the backup threshold is set to five, IBM MQ will automatically retry sending the message up to five times. If unsuccessful, the message is then sent to the backout queue, indicating that it has been attempted multiple times. This flexibility allows us to handle message delivery failures by either discarding, logging, or retrying the message using mediation patterns.

The security features of IBM MQ have met our data protection requirements well. We utilize encryption with SSL keys to ensure data encryption. Additionally, many companies prefer using MQ connections with SSL challenges for added security. The integration with operating systems like Linux and authentication with Active Directory or Open Endpoint of Microsoft has made security configuration straightforward.

IBM MQ could streamline its complexity to be more like Kafka without the channel complexities of clusters, making it more straightforward. Migrating to IBM MQ from another messaging solution has not impacted our operational efficiency as we always build our messaging solutions from scratch.

I have been using IBM MQ from 17 years.

Regarding stability, IBM MQ itself is stable, but issues can arise from the surrounding infrastructure or configurations. Technical support from IBM can be hit or miss, with varying levels of expertise and dedication among support personnel.

In terms of scalability, IBM MQ has supported our growing transaction volumes effectively. We use telemetry and performance tools like Mehdi, Nessus, Zavix, etc., to monitor and manage scalability. While some tools like Cisco AppDynamics offer proprietary solutions, we often create or customize performance monitoring tools within MQ for scalability monitoring.

The initial setup of IBM MQ can be quite complex, often leading to mistakes during configuration. The documentation, while extensive, can be challenging to navigate. The deployment is typically on-premises, and the actual deployment time can vary based on the complexity of the configuration.