This week, my customer engagements were rather routine, so there’s not much to report on that front. However, I took a deep dive into the upcoming AMQ Broker 8.0 release, and I’d like to share some key insights and highlights from my research. All of these changes are, as always for planned releases, subject to change.

AMQ Broker 8.0 Announcements

Migration and Support

One of the main priorities for the AMQ team is to ensure a smooth migration path from AMQ 7 to AMQ 8. To support this, AMQ 7.13 will benefit from an extended support cycle, giving users plenty of time to plan and execute their upgrades.

A significant change in AMQ 8.0 is the removal of the Openwire protocol. Openwire was originally included for backward compatibility with AMQ 6, but in AMQ 7.x, it was already being translated into the native AMQP or CORE protocols. With AMQ 6 now officially end-of-life, the need for Openwire has disappeared, and it will no longer be supported in AMQ 8.0.

Operator and Release Model

Another major shift is the decoupling of the AMQ Operator and container images from the AMQ Broker itself. Red Hat’s build of ArkMQ (formerly known as ArtemisCloud) will take over from the previous AMQ Operator, enabling faster and more flexible release cycles. Operator and image releases will now be independent of the broker version, and users will be able to choose between stable and development channels to suit their needs.

New Custom Resource Definitions (CRDs)

AMQ 8 introduces new Custom Resource Definitions (CRDs) to simplify and streamline broker and application provisioning:

  • Broker Provisioning CRD:
    This CRD allows for the deployment of broker services with a strong focus on security. Brokers will be fully locked down, including JMX and metrics, and will enforce mutual TLS (mTLS) everywhere. Passwords are eliminated, and certificates are managed through integration with cert-manager.

  • Application CRDs:
    These CRDs enable the creation of application-specific destinations, quality of service (QoS) settings, and authentication schemes. They also support multi-tenant environments using RBAC, and automatically generate certificates for clients. Applications can request specific QoS levels, which can be realized through single, federated, or mirrored brokers—or a combination of these.

Operational Model

The new operational model emphasizes simplicity and reliability over complex configuration. Deployments are now more opinionated and deterministic, supporting high availability through a leader-follower model. AMQP federation enables on-demand message movement, while AMQP mirroring provides robust disaster recovery and replication. Static routing is also supported to address data gravity concerns.

AMQP Bridge

A new AMQP Bridge will allow connections to any AMQP endpoint, aligning all AMQ components with the AMQP standard. This bridge serves as an open alternative to the core bridge and JMS bridge, and supports SASL authentication.

Federation and Mirroring

  • Federation:
    Federation will replace clustering as the default solution for message distribution. It supports on-demand distribution, eliminates the “stampeding herd” problem, and removes the need for complex topology state management. Federation is bi-directional, and brokers can be configured independently—or even operate without explicit federation configuration.

  • Mirroring:
    Mirroring will become the default solution for high availability and disaster recovery, replacing traditional replication. It is better suited for cross-data center scenarios, avoids complex catch-up algorithms, and is more efficient since only messages and acknowledgments are mirrored, not the entire journal.

OpenShift Integration

OpenShift integration will reach General Availability (GA) with this release, and some of the new CRDs will reflect this enhanced integration.

Planned Release Dates

  • Preview release: Q3
  • General Availability (GA): Q1 2026