Register Now for EDA Summit 2024 - Virtual Event Register for Free
EN CN FR DE JP KO ES PT
Search
In this Post

    IBM continues to push MQ as the messaging system for products like App Connect, DataPower and Websphere, but MQ is a legacy technology that was built primarily for point-to-point communication and does not meet a lot of modern needs. In this piece I’ll break down some of the key reasons many longtime MQ customers are looking for an alternative, and offer a list of attributes and capabilities I think you should look for when evaluating MQ alternatives.

    Drawbacks of IBM MQ

    Difficult Migration to the Cloud

    IBM technically offers a path to the cloud, but the MQ they offer in the cloud has many limitations. MQ is also weak in functional areas that are critical in hybrid and multi-cloud environments, such as handling slow consumers, replaying messages, and optimizing WAN distribution.

    • Weak Managed Cloud options: IBM MQ cloud managed service only works on AWS and IBM clouds, and not on any other clouds.
    • Very Weak Hybrid Cloud (No Event Mesh or WAN Optimization): When it comes to distributing data across wide area networks, MQ does not effectively account for or accommodate the bandwidth constraints and performance variability that are inherent in WAN links. For example, MQ does not let you fine-tune TCP window size and other parameters to work with lossy connections that are a norm in remote areas with poor connectivity. MQ does not even provide deep visibility into the TCP stack, which hampers your ability to make pragmatic decisions about their overall infrastructure.
    • Slow Consumer Handling: MQ’s approach to slow consumer handling puts back-pressure on publishers, and can crash the performance of entire clusters if too many undeliverable messages accumulate.
    • Message Replay: MQ does not support message replay, so the only way to implement replay is with IBM App Connect Enterprise (ACE), formerly known as IBM Integration Bus (IIB).
    • Expensive Upgrades: MQ version upgrades even on prem are difficult and expensive. Moving to the cloud makes the migration even more expensive and complex due to a different storage model, container planning and capabilities.

    Antiquated and Inflexible Disaster Recovery

    IBM MQ has a poor HA/DR mechanism and has not adapted to modern use cases.

    • Slow, Unpredictable Recovery Times: MQ suffers from painfully slow recovery times because SRDF is an antiquated approach that synchronously replicates messages as blocks of data on disk. This approaches means you rely on HACMP and SANs, have to wait for SRDF blocks to resolve, and risk message corruption – all of which means applications face an unpredictable “wait time” in case of an outage.
    • Confusing and Inconsistent Approaches: IBM MQ has a severe inconsistency between form factors: the appliance can only support asynchronous disaster recovery, and the software only supports synchronous. And there is a catch – synchronous DR is only available for Linux, and only on the “advanced” license. Not only will this inconsistency be hard to manage, but also add more costs to support DR scenarios.
    • Risk of Split Brain Scenarios: If you lose the network connections between two appliances, a partitioned situation can arise where the same queue manager continues to run on each appliance, and each instance has a different set of queue manager data. MQ lets you monitor failover activity, but does nothing to prevent a split-brain situation, so IT staff and admins need to make sure the “right” broker has come online.

    Complex, Costly to Maintain and Upgrade

    MQ requires significant resources in terms of servers and supporting software, making maintenance and upgrades complex and costly.

    • Associated Components: Upgrading MQ entails not just upgrading the MQ software itself, but client libraries, HACMP, and storage. When running MQ in the cloud, MQ Cloud Pack, MQ Operator, different HA strategies need to be understood and configured.
    • Versionitis: With more than a dozen active versions in the market, many IT organizations have to deal with a complex compatibility matrix across lines of business and use cases. Different versions of Queue managers need to operate in a compatible manner with different version of the APIs.

    Also, for cloud managed deployment model, the choices customers have are very limited and is only available on IBM Cloud or on AWS, and that too in limited cloud regions. Private Cloud is not supported as a managed service, so the customer has to bear the cost of managing complex infrastructure like Kubernetes or OpenShift to run MQ.

    Limited to Message Queuing

    MQ was created in the 80’s around the idea of queuing, and it’s an approach that served many companies very well for decades, but it is not optimal for use cases that expect a high level of automation and real-time action. In recent years the advent of cloud, IoT and AI has made most companies recognize the need to complement queuing with event-driven, publish/subscribe communications and integration.

    The most critical piece here is IBM MQ’s weak support for the publish/subscribe exchange pattern that enables such real-time communications. Architecturally, MQ was created as a queueing broker, with queues as the first-class citizen. Publish/subscribe and topic routing, while supported, have performance limitations when used. There is a 15% reduction in throughput when pub/sub is used, and there are other considerations which affect throughput and latency, such as distributed subscriptions across the topic tree. This causes a need to carefully architect applications for publish subscribe to balance MQs lack of pub sub predictable performance, thereby increasing cost in development, and reducing agility for change.

    • Slow Fanout: IBM MQ manages fan-out through multi-cast. In fan-out scenarios, it does not manage messages in a queue and rather directly delivers messages from the publisher to the subscribers. This approach is known to cause severe issues for customers in consistency of delivery and overall performance.
    • Topic Tree Management Overhead: Given that IBM topic routing latency and throughput is affected with the nature of the topic tree (lop sided or balanced), there is an architectural overhead in creating topic trees, and the relevant subscribers to topics.
    • Publish Latency Impact with Pub Sub : There are circumstances where this latency will be more apparent, including: when the number of subscribers to a specific topic is non-trivial (say, 10+), where the publications are persistent and being put to durable subscriptions (since multiple messages are being put by that one MQPut), where wildcards are being used inappropriately, where message selectors are being used (since the selectors for all the subscribers to a specific topic are evaluated as part of the MQPut).

    What to Look for in an MQ Replacement

    When evaluating solutions that can replace MQ, organizations should prioritize the following criteria to meet their needs not just today but into the future:

    • Comprehensive Support for Modern Technologies: Look for a vendor that can meet the evolving needs of big data, cloud computing, IoT, and microservices. Ensure the messaging solution seamlessly integrates with these technologies to facilitate efficient and reliable data exchange in complex environments.
    • Robust High Availability (HA) and Disaster Recovery (DR): Seek a vendor that offers fast and automatic HA and DR capabilities with no message loss. This ensures business continuity and data integrity, even in the event of failures or disruptions.
    • Hybrid-Cloud Enablement: Choose a vendor that supports hybrid cloud architectures, allowing the messaging solution to run seamlessly across various cloud platforms and on-premises environments. This flexibility enables organizations to leverage the advantages of both worlds while maintaining consistent messaging capabilities.
    • Commitment to Open APIs and Standard Protocols: Ensure the vendor demonstrates a strategic commitment to open APIs and standard protocols like AMQP 1.0, MQTT, and REST. This commitment promotes interoperability, avoids vendor lock-in, and enables seamless integration with a wide range of systems and applications.
    • Superior Performance and Scalability: Look for a messaging solution that offers better fan-out performance and high message volume capability (throughput). This ensures efficient distribution of messages across the infrastructure, supporting real-time data exchange and scaling to meet growing demands.
    • Cloud-Friendly Approach: Choose a vendor that embraces a cloud-friendly mindset, providing native integration with popular cloud platforms and services. This enables organizations to leverage the scalability, elasticity, and management advantages offered by the cloud environment.

    By considering these factors, organizations can identify a messaging vendor that aligns with their needs for robustness, scalability, and performance, empowering them to overcome the limitations and challenges posed by legacy solutions like IBM MQ. You can learn how Solace’s offering stacks up as an alternative to IBM MQ here.