We’re excited to announce the latest version – v3.13 of VMware Tanzu RabbitMQ. This new version replaces v1.5 as the latest version. To those curious about our transition from v1.5 to v3.13, this has been done to ensure consistency across the open source and enterprise versions of RabbitMQ. With its unwavering popularity in the world of messaging and streaming, Tanzu RabbitMQ stands as the preferred choice for those seeking robust, scalable, and dependable communication solutions. Our dedication to continuous improvement has led to significant recent developments, building on the success of our last release and pushing the envelope of what RabbitMQ can deliver. As we roll out this new version, it reflects our ongoing commitment to innovation and ensuring that Tanzu RabbitMQ remains at the forefront of evolving technologies. We’re excited to introduce the highlights of this next step in our journey.
What’s new in VMware Tanzu RabbitMQ 3.13?
Warm Standby Replication on Tanzu Platform for Cloud Foundry: For the first time it is now possible for users to leverage the versatile disaster recovery features of RabbitMQ on the Tanzu Platform for Cloud Foundry. Now Streams, Messages and Schema definitions can be replicated to a passive downstream RabbitMQ cluster. This can be done across Tanzu Platform foundations and failover controlled by the user via a new API (see below).
Warm standby Replication for Streams: As part of the natural progression of RabbitMQ’s disaster recovery (DR) features, WSR (Warm Standby Replications) users can now replicate high volumes of data at high speed from an active RabbitMQ cluster to a downstream passive cluster in order to provide a disaster recovery strategy. This technology also paves the way for further development of the RabbitMQ high availability functionality.
New Warm Standby Replication API: As use cases and topologies become more complex so the need for users to have better control and visibility of the status of messaging components increases. This new API along with a new tab in the management user interface, provides better monitoring of the upstream and downstream clusters in a RabbitMQ warm standby configuration. This includes the status of both message and schema replication as well as which cluster is currently active and which is in standby mode. Promotion of a cluster can also now be handled by the API (and the Management UI) allowing users to either manually or programmatically failover to a synchronized RabbitMQ cluster.
Multi-Resource OAuth2: This new feature unlocks the support for those environments where a single RabbitMQ server is used by multiple teams across an organization. Often these teams refer to RabbitMQ (the resource) with different names (aka the audience) and where users may be declared in different identity providers.
OAuth2 support for Warm Standby Replication synchronization: This enhances the security of data links between the upstream (active) and downstream (passive) cluster used in Warm Standby Replication by using the more secure OAuth 2.0 authentication mechanism.
FIPS compliance: One of the key features exclusive to this commercial version of Tanzu RabbitMQ is compliance with the Federal Information Processing Standard (FIPS) 140-2. This provides another level of security to RabbitMQ messaging using OpenSSL 3. Vital to the security of financial and governmental systems and built into the Erlang core of RabbitMQ getting the correct configuration can be challenging for some users at best. Now with Tanzu RabbitMQ 3.13 this configuration is provided ‘out of the box’.
Support for MQTT 5.0: The last release of VMware Tanzu RabbitMQ (v1.5) saw some significant improvements to the performance of the simple and lightweight MQTT (Message Queuing Telemetry Transport) protocol used extensively in IoT applications. By streamlining the way that VMware Tanzu RabbitMQ handles the connection process for MQTT it is now possible for the most popular message broker to handle millions of IoT connections.
In line with this advancement we now have the ability to support the newest version of this protocol – MQTT 5.0. This version brings a whole raft of additional features specific to this protocol. MQTT 5.0 provides improved session management, support for user properties, and extended error reporting. It also allows for more fine-grained control over message properties and behaviors, making it a more versatile and extensible protocol compared to MQTT 3.1.1.
Filtering for RabbitMQ Streams: Since the launch of Streams in RabbitMQ, we have seen a steady growth in the adoption of this highly performant message transport mechanism. Not only do Streams provide the ability to route high volumes of data, but they can be partitioned into topics to make the consumption easier for client applications using Super Streams. New in VMware Tanzu RabbitMQ is the ability to filter a Stream. This lightens the load on client applications at the same time as saving network bandwidth. In high throughput message topologies it is common for microservices to become overburdened and in extreme cases cease to be very micro at all. Filtering for Streams is particularly helpful in this type of application. However, being bloom filter based, it does not replace the need for client side filtering logic altogether. Like many messaging implementations a degree of pragmatism is needed.
Message Containers Introduced: VMware Tanzu RabbitMQ 3.13 also sees the debut of message containers. These form the basis of a protocol agnostic core that offers greater flexibility for users looking to leverage protocols other than AMQP 0.9.1. Previously all non AMQP 0.9.1 messages were handled via a proxy which increased the processing overhead and had the potential to lose some metadata. With message containers though messages are wrapped and preserved throughout the routing of VMware Tanzu RabbitMQ and only reconstructed back into their original format when consumed. Metadata is preserved where possible, obviously if consuming in a different protocol to that which published a message, a compromise in metadata mapped is needed. Integrating event driven architectures across disparate systems can be very complex especially if ‘legacy’ protocols are in play. Message containers allow users to consume messages from legacy systems (using older protocols like MQTTv3) and integrate them into a more modern microservice architecture without having to rewrite consuming clients from scratch. This protocol agnostic core also means that VMware Tanzu RabbitMQ has become even more flexible and has the potential to adopt many more protocols in the future.
New Metadata Store: This release of VMware Tanzu RabbitMQ is an important milestone in the roll out plan for a new metadata store. Khepri, the new metadata store, will replace the existing Mnesia distributed metadata store. Based on the proven raft algorithm Khepri makes it easier to reason about things like network partitions. It makes a clear consistent choice, rather than leaving that choice up to the user, thus improving the stability and predictability of the metadata store. In this first release of Khepri users have control over how it is enabled. By default the existing metadata store is used. This gives customers the opportunity to try Khepri first before a wider roll out in the upcoming releases.
Improvements to memory footprint: Finally we have also improved the memory footprint for the robust Quorum Queue and conventional Classic Queues v2. The benefits would bring about better resource efficiency, cost savings, enhanced performance, and greater overall stability.
All these new and updated features hold true to the values that VMware Tanzu RabbitMQ is a message broker that “just works” and continues to be the most versatile and popular message broker for event driven architectures.
Learn more:
