Single service comparison

Huawei splits the Pub/Sub workload across two services with distinct boundaries. DMS is the managed message-broker service, offered as DMS for Kafka, DMS for RocketMQ, and DMS for RabbitMQ; each runs a single open-source engine on provisioned instances you size yourself, so capacity planning, topic/partition provisioning, and broker instance lifecycle become your operational responsibility rather than Google's serverless model. DIS is a separate streaming-ingestion pipeline (RESTful APIs, SDKs, agents, built-in dump connectors to OBS, DLI, MRS, DWS) that buffers data for up to seven days; it behaves like a managed intake channel toward analytics stores rather than a general-purpose pub/sub broker. The two are not interchangeable: choose DMS when consumers are applications expecting broker-native pull/push and ack semantics, and DIS when the destination is a downstream analytics or storage service.

API and data model diverge significantly. Pub/Sub exposes a Google-native gRPC/REST API with topic+subscription objects, ordering keys, and push/pull subscription types; DMS instead exposes the native protocol of its chosen engine (Kafka, RocketMQ, or AMQP), so client libraries and message semantics come from the upstream project, which limits filtering to per-engine capabilities and changes dead-letter and retry handling. Acknowledgement and dead-letter behavior differs per engine: DMS for Kafka relies on consumer offset and retry logic rather than Pub/Sub's dead-letter-topic pattern, while DMS for RocketMQ and RabbitMQ provide built-in dead-letter queues. There is no byte-for-byte Pub/Sub API on Huawei; remapping requires client and code changes to the target engine SDK.

Scaling, high availability, pricing, and integration model differ. Pub/Sub scales elastically with serverless metering by ingested and delivered message volume, while DMS instances are size-constrained resources you scale by resizing the instance or adding partitions and pay per instance-hour plus storage; DIS scales by adding partitions and is priced per use from a low hourly rate. DMS and DIS integrate natively with Huawei services (FunctionGraph, SMN, OBS, DLI, MRS) rather than with arbitrary HTTPS push endpoints as Pub/Sub webhooks do. Confirm supported regions, instance quotas, and per-engine feature support in your target region because coverage is not uniform across DMS engines.

Start with workload assessment to choose the right target and avoid a forced one-to-one port. If your Pub/Sub usage is application decoupling with many independent subscribers and push/pull delivery, DMS for Kafka is the closest behavioral target because it supports partition-level ordering, message filtering, and pull consumption that maps to webhook or callable consumers only via supplementary integration code. If the workload is primarily high-volume ingest feeding analytics or object storage, DIS is the better fit because it provides agents, dump connectors, and multi-day buffering toward OBS, DLI, MRS, and DWS. Do not treat DMS and DIS as interchangeable; a single Pub/Sub deployment may split across both services depending on consumer patterns.

Data and configuration migration is largely manual because Huawei offers no one-click Pub/Sub migration tool. Inventory topics, subscriptions, ordering keys, filters, retention settings, dead-letter policies, IAM bindings, and push endpoints, then recreate equivalents in the chosen Huawei target. For DMS, provision broker instances in the target region, create topics and (for Kafka) partitions sized to peak throughput, select an instance flavor that meets throughput and storage needs, and configure disk capacity for retention. Recompile or repoint publishers and subscribers to the DMS engine's native client library, replacing Pub/Sub ordering keys with Kafka partition keys and re-implementing dead-letter handling using the engine's native mechanism. For DIS, create streams with the partition count matching desired throughput and configure dump tasks or connectors to downstream services.

Application code changes center onSDK and delivery-mode translation. Replace the Pub/Sub client library with the DMS engine SDK or the DIS SDK, and convert push subscriptions to either pull loops or a Huawei event-routing layer because there is no native Pub/Sub-style HTTPS push delivery. Re-implement at-least-once and idempotency logic against the chosen engine's acknowledgement model, and replace subscription filters with Kafka message filtering or application-side filtering. Update authentication to Huawei IAM and DMS SASL/SSL credentials, and adjust monitoring to DMS or DIS metrics rather than Pub/Sub Cloud Monitoring dashboards.

Validate end-to-end before cutover and recalculate the cost model. Test throughput, latency, ordering guarantees, and dead-letter/retry behavior under realistic peak load against the Huawei target, and run dual-publish or shadow consumption in parallel to compare message counts and ordering. Be aware of the cost-model shift from Pub/Sub's volume-based metering to DMS instance-plus-storage hourly billing or DIS per-use billing, and factor in cross-region or interconnect traffic if producers run outside the Huawei region. Document remaining gaps (no exact Pub/Sub API, region-specific engine availability, quota limits) and plan a cutover with a window that allows rollback to the Pub/Sub source.