Alibaba Cloud Kafka, RabbitMQ and RocketMQ on STACKIT

Three brokers, assessed

A streaming estate written for this page, assessed by StackToIT on 4 November 2026. Left: the Kafka and RabbitMQ resources of the input. Right: an excerpt of assessment.json for all three brokers, with the values the run wrote. assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged.

resource "alicloud_alikafka_instance" "events" {
  name          = "orders-events"
  partition_num = 50
  disk_type     = 1
  disk_size     = 500
  deploy_type   = 5
  io_max        = 20
  vswitch_id    = alicloud_vswitch.data.id
}

resource "alicloud_amqp_instance" "jobs" {
  instance_name  = "billing-jobs"
  instance_type  = "professional"
  max_tps        = 1000
  queue_capacity = 50
  support_eip    = false
}

[
  {
    "id": "alicloud_amqp_instance.jobs",
    "result": {
      "class": "REPLATFORM",
      "confidence": "MEDIUM",
      "target": {
        "service": "STACKIT RabbitMQ"
      },
      "reason": "Alibaba Cloud Message Queue for RabbitMQ becomes STACKIT RabbitMQ. Exchanges, queues and credentials are recreated, and messages in flight are drained before cut-over."
    }
  },
  {
    "id": "alicloud_alikafka_instance.events",
    "result": {
      "class": "CONTAINERIZE",
      "confidence": "MEDIUM",
      "target": {
        "service": "a self-managed Kafka-compatible broker on SKE"
      },
      "reason": "STACKIT has no managed Kafka service. The broker runs self-managed on SKE, or the messaging design changes to RabbitMQ."
    }
  },
  {
    "id": "alicloud_rocketmq_instance.txn",
    "result": {
      "class": "REDESIGN",
      "confidence": "LOW",
      "target": {
        "service": "STACKIT RabbitMQ"
      },
      "reason": "STACKIT has no RocketMQ service. Ordered and delayed message semantics have to be redesigned for RabbitMQ, or the broker runs self-managed on SKE."
    }
  }
]

• RabbitMQ: exchanges and queues recreated

  The reason the run records is that exchanges, queues and credentials are recreated and messages in flight are drained before cut-over. StackToIT carries none of this across.

• Kafka: sizing is in the input

  The input states 50 partitions, a 500 GB disk and an io_max of 20. They are the starting point for the broker design on SKE, not a recommendation.

• RocketMQ: the lowest confidence

  The RocketMQ instance is the only unit of the run at LOW confidence. The run points to RabbitMQ as target, or to a self-managed broker on SKE.

The options per broker

What the run classifies, the alternative it names, and the trade-off you carry. The trade-off column states general practice where it goes beyond the run.

The run lists no managed Kafka or RocketMQ service on STACKIT. If STACKIT adds such a service, a later StackToIT build classifies these two units differently; re-run the assessment rather than relying on this page.

What differs between the source brokers and the targets

• RabbitMQ features of the service

  ApsaraMQ for RabbitMQ is documented as compatible with AMQP 0-9-1 and adds delayed messages (up to one day) and a retry policy: failed messages are retried once per minute up to 16 times, then go to a dead-letter queue. Open-source RabbitMQ has no native delayed queue.

• STACKIT RabbitMQ

  Described as a managed broker based on the open-source project, with AMQP, STOMP, MQTT, HTTP and WebSockets, created in the portal or the Cloud Foundry marketplace. The priced plans on the product page are three-node replica plans.

• Kafka clients

  ApsaraMQ for Kafka supports Apache Kafka 0.10.x to 3.x with standard clients, so producers, consumers and Kafka Connect pipelines use the Kafka protocol. That is what makes a self-managed broker a realistic target.

• RocketMQ message types

  A RocketMQ 5.x topic supports one message type: normal, FIFO, delay, transaction or the newer Lite type, and a 5.x broker rejects a message whose type does not match its topic. Your topic list therefore tells you which semantics each topic depends on.

• Consumer groups and offsets

  Kafka consumers track their position per partition, and several groups can read one topic independently. A queue model has no equivalent of an independent group reading the same log, which is why the run's RabbitMQ alternative for Kafka means changing the messaging design, not just the endpoint.

• State is not data movement

  The run lists no data movement for these units: topics and queues are not read as stateful. Definitions and messages in flight are still yours to plan.

How to decide, per workload

1. 01

   1. Inventory topics, queues and groups

   List every topic or queue with its producers, consumers and the semantics it needs: ordering, delay, replay, transactions. The Terraform shows the instance, not these.

2. 02

   2. Separate event streams from jobs

   Job and task traffic fits a RabbitMQ queue. Event streams that several consumers replay point to a Kafka-compatible broker.

3. 03

   3. Decide who operates the broker

   Self-managed on SKE is a service you run: upgrades, disk, monitoring, on-call. Count that cost before choosing it over a managed redesign.

4. 04

   4. Plan the cut-over per workload

   In practice: drain or dual-publish, switch consumers first, then producers. This is general practice, not a step the run carries out.

5. 05

   5. Record owners

   The run puts the three brokers in one work package for the Platform Architect and the network in another for the Network Architect.

Questions platform teams ask

Sources

• Alibaba Cloud: what is ApsaraMQ for Kafka
• Alibaba Cloud: ApsaraMQ for RocketMQ 5.x topics
• Alibaba Cloud: benefits of ApsaraMQ for RabbitMQ
• STACKIT RabbitMQ product page