Single service comparison

Huawei DMS is not a single broker but three independently provisioned managed runtimes — DMS for Kafka, DMS for RocketMQ, and DMS for RabbitMQ — each compatible with its respective open-source protocol. Azure Service Bus is one broker speaking AMQP 1.0 natively, with no Kafka, RocketMQ, or AMQP-0-9-1 wire compatibility. There is no DMS engine that exposes the Service Bus API or its queue/topic/SBMP semantics, so producers and consumers must be rewritten against Kafka, RocketMQ, or AMQP-0-9-1 clients rather than re-pointed by a connection string.

Feature coverage differs per engine: DMS for RabbitMQ provides the closest protocol analog (AMQP-0-9-1) with priority queues up to 0–10, dead-letter queues, and credit-based throttling, but lacks a native equivalent of Service Bus sessions, transactions across entities, duplicate detection, and scheduled delivery. DMS for RocketMQ offers transactional messages, delayed queues, message retry, dead-letter queues, and multi-tenancy that partially cover Service Bus sessions and scheduled messages, but ordering is queue-scoped rather than session-scoped. DMS for Kafka gives partition-level FIFO plus high-throughput streaming but has no delayed, priority, dead-letter, or transactional semantics out of the box.

Scaling, high availability, and operational responsibility also diverge. Service Bus partitions entities and Microsoft transparently handles broker placement and geo-replication with Geo-DR pairing. DMS instances are sized by the operator to fixed broker and storage specifications, with multi-AZ deployment and failover for resilience, and cross-region disaster recovery is not equivalent to Service Bus Geo-DR. Throttling on DMS is credit- or client-based per engine, not the tier-based unit/pricing-namespace model of Service Bus, so capacity planning must be redone against instance TPS, partition count, and message retention rather than messaging units.

Assess the Service Bus usage contract first: enumerate queues, topics, subscriptions, sessions, scheduled messages, transactions, duplicate-detection windows, ordered delivery requirements, and peak TPS. Map each contract to a DMS engine — AMQP-0-9-1 workloads with priority queues fit DMS for RabbitMQ; session/transaction/scheduled workloads needing dead-letter and retry fit DMS for RocketMQ; high-throughput partitioned streaming fits DMS for Kafka. Do not assume drop-in compatibility; product documentation documents migration guidance per engine.

Migrate metadata and clients per chosen engine. For RabbitMQ, export broker definitions (exchanges, queues, bindings, users) from the source and import them into the target DMS RabbitMQ instance, then run dual-read consumers before moving producers, validating messages_ready and messages_unacknowledged reach zero. For Kafka-based targets, the documented patterns are producer-then-consumer re-pointing, dual-consumption, or data replication via MirrorMaker or DMS Smart Connect. For RocketMQ, follow the engine-specific migration guide. Service Bus sessions, transactions, and duplicate detection must be reimplemented in application code, since no DMS engine mirrors those semantics.

Validate ordering, idempotency, at-least-once versus at-most-once behavior, and dead-letter routing against the new engine before cutover; replication patterns like Smart Connect and MirrorMaker can replay historical messages and require idempotent consumers. Confirm VPC, public-access, security-group, SASL/SSL, and IAM permissions match the connectivity model the clients expect, and that instance specifications meet or exceed source throughput and retention.

Recalculate total cost of ownership: Service Bus bills by tier and operations, while DMS bills per instance-hour, storage, and (for Kafka) Smart Connect and bandwidth, with separate pricing per engine (RabbitMQ starting lower than Kafka and RocketMQ). Account for peak load, partition count, message retention period, message size limits, and cross-region or interconnect traffic, since a migration that increases instance count or adds replication tasks can move cost materially relative to the Service Bus unit model.