OCI Streaming en Queue naar STACKIT

De migratie in zes stappen

Een demo-omgeving van vijf resources, beoordeeld op 4 november 2026, geeft de volgorde. De stappen zijn die uw team uitvoert; de run levert de doelen, klassen en afhankelijkheden.

1. 01

   1. Inventariseer queues, streams en clients

   Maak een lijst van elke producer en consumer met het protocol dat die gebruikt. OCI Queue biedt een REST-API en het STOMP-protocol; OCI Streaming is compatibel met de meeste Kafka-API's. Het clientprotocol bepaalt hoeveel applicatiecode wijzigt.

2. 02

   2. Kies de broker voor elke stream

   Streams landen op een zelf beheerde Kafka-compatibele broker op SKE, of het berichtenontwerp verandert naar RabbitMQ. De run legt het eerste vast als doel; in de reden staat het tweede als alternatief.

3. 03

   3. Bouw het SKE-cluster op een ondersteunde versie

   Kies een Kubernetes-versie die het rapport als geschikt markeert. Plan de broker met het aantal partities en de retentie van de bronstreams, die de run als instellingen noemt die aan u zijn overgelaten.

4. 04

   4. Maak de RabbitMQ-instance en de queues aan

   Elke OCI-queue wordt een queue op STACKIT RabbitMQ. Maak retentie, herlevering en dead-letter-gedrag opnieuw met RabbitMQ-functies en test ze.

5. 05

   5. Verplaats producers en consumers in gecontroleerde volgorde

   Berichten die onderweg zijn, worden vóór de cutover afgevoerd. Spreek voor streams af hoe consumers hun positie behouden en hoe lang beide kanten naast elkaar draaien.

6. 06

   6. Faseer de OCI-kant uit na de bewaarperiode

   Behoud de OCI-queues en -streams tot het rollbackvenster afloopt. Verwijder ze pas na de afgesproken bewaarperiode (algemene praktijk).

Een stream en zijn pool, beoordeeld

Links: de pool en beide streams in de invoer. Rechts: de beslissingen voor de pool en de stream clicks zoals ze in assessment.json staan; orders wordt op dezelfde manier beoordeeld. De streams zijn gekoppeld; de stream pool staat niet in de catalogus van deze build en is aan uw architecten overgelaten. assessment.json staat op één regel, dus het venster toont geselecteerde velden van elke eenheid, ingesprongen en genest zoals in het bestand, met ongewijzigde waarden.

resource "oci_streaming_stream_pool" "events" {
  compartment_id = var.compartment_id
  name           = "events"
}

resource "oci_streaming_stream" "orders" {
  name               = "orders"
  partitions         = 6
  retention_in_hours = 72
  stream_pool_id     = oci_streaming_stream_pool.events.id
}

resource "oci_streaming_stream" "clicks" {
  name               = "clicks"
  partitions         = 12
  retention_in_hours = 24
  stream_pool_id     = oci_streaming_stream_pool.events.id
}

[
  {
    "id": "oci_streaming_stream_pool.events",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "oci_streaming_stream_pool is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
    }
  },
  {
    "id": "oci_streaming_stream.clicks",
    "result": {
      "class": "CONTAINERIZE",
      "confidence": "MEDIUM",
      "target": {
        "service": "a self-managed Kafka-compatible broker on SKE"
      },
      "reason": "STACKIT has no managed Kafka service. The stream moves to a self-managed broker on SKE, or the messaging design changes to RabbitMQ."
    }
  }
]

• CONTAINERIZE, zekerheidsniveau MEDIUM

  De stream wordt een workload die u op SKE draait. Het rapport noemt een zelf beheerde Kafka-compatibele broker, met een SKE-cluster als STACKIT-resource erachter.

• De pool is handmatig

  oci_streaming_stream_pool is een MANUAL_REVIEW-eenheid zonder doel. Oracle beschrijft een pool als de groepering van streams die gedeelde Kafka- of beveiligingsinstellingen bevat; die instellingen neemt u zelf over.

• Partities en retentie neemt u zelf over

  name, partitions, retention_in_hours en stream_pool_id zijn de vier kritieke instellingen die het rapport voor de stream noemt. De demo stelt voor clicks 12 partities en 24 uur in, voor orders 6 en 72.

Twee queues, een met dead-lettering, beoordeeld

De queue jobs verplaatst een bericht na 5 leveringspogingen naar een dead letter queue; jobs_dead is een tweede, gewone queue. assessment.json staat op één regel, dus het venster toont geselecteerde velden van elke eenheid, ingesprongen en genest zoals in het bestand, met ongewijzigde waarden. De demo stelt 7 dagen (604800 seconden) in op jobs_dead, de maximale retentie die Oracle voor een queue documenteert.

resource "oci_queue_queue" "jobs_dead" {
  compartment_id       = var.compartment_id
  display_name         = "jobs-dead"
  retention_in_seconds = 604800
}

resource "oci_queue_queue" "jobs" {
  compartment_id                   = var.compartment_id
  display_name                     = "jobs"
  retention_in_seconds             = 345600
  visibility_in_seconds            = 60
  timeout_in_seconds               = 20
  dead_letter_queue_delivery_count = 5
}

[
  {
    "id": "oci_queue_queue.jobs",
    "result": {
      "class": "REPLATFORM",
      "confidence": "MEDIUM",
      "target": {
        "service": "STACKIT RabbitMQ"
      },
      "reason": "An OCI queue becomes a queue on STACKIT RabbitMQ. Clients change protocol, and messages in flight are drained before cut-over."
    }
  },
  {
    "id": "oci_queue_queue.jobs_dead",
    "result": {
      "class": "REPLATFORM",
      "confidence": "MEDIUM",
      "target": {
        "service": "STACKIT RabbitMQ"
      },
      "reason": "An OCI queue becomes a queue on STACKIT RabbitMQ. Clients change protocol, and messages in flight are drained before cut-over."
    }
  }
]

• REPLATFORM naar RabbitMQ

  Beide queues worden queues op een STACKIT RabbitMQ-instance. In de reden staat dat clients van protocol veranderen en dat berichten die onderweg zijn, vóór de cutover worden afgevoerd.

• Gedragsinstellingen die bij u liggen

  Retentie, visibility timeout, polling timeout en het aantal leveringen vóór dead-lettering staan als instellingen die u overneemt. De run vertaalt ze niet.

• Let op de dead-letterkoppeling

  In de invoer stelt jobs een aantal leveringen van 5 in, maar niets in de Terraform van de demo verwijst naar jobs_dead; de koppeling bestaat alleen in de naamgeving. Maak die koppeling expliciet in het RabbitMQ-ontwerp.

Hoe de berichtenomgeving wordt gekoppeld

Klassen en doelen zoals de run ze bepaalde. Het queuepaar en het streampaar zijn elk twee eenheden, hier elk één rij.

De SKE-versies waarop u kunt landen

Het rapport noemt elke SKE-versie met de bijbehorende data, gelezen van de STACKIT-pagina's op 3 november 2026 en niet gegarandeerd na 1 februari 2027. Dit zijn de rijen zoals ze in engineering/architect-report.md staan.

| Version | State | Released | Deprecated | Expires | Production suitability | Upgrade action | Migration timing risk |
|---|---|---|---|---|---|---|---|
| 1.36 | SUPPORTED | 2026-08-27 | not stated | 2027-06-09 | SUITABLE | PLAN | LOW |
| 1.35 | UNKNOWN | not stated | not stated | 2027-02-10 | UNKNOWN | UNKNOWN | UNKNOWN |
| 1.34 | EXPIRED | 2025-12-16 | 2026-08-28 | 2026-10-14 | NOT_SUITABLE | MANDATORY_UPDATE_APPLIES | HIGH |
| 1.33 | EXPIRED | 2025-07-29 | 2026-06-09 | 2026-06-10 (sources disagree: 2026-07-08) | NOT_SUITABLE | MANDATORY_UPDATE_APPLIES | HIGH |
| 1.32 | EXPIRED | not stated | 2026-02-20 | 2026-04-15 | NOT_SUITABLE | MANDATORY_UPDATE_APPLIES | HIGH |

• Landen op 1.36

  1.36 wordt ondersteund, met een geplande upgrade en een einddatum van 9 juni 2027. De lifecyclepagina van STACKIT noemt dezelfde einddatum.

• 1.35 is niet beoordeeld

  De run markeert die versie als UNKNOWN en meldt dat er geen datumbewijs is, dus is die niet beoordeeld, hoewel de rij een einddatum van 10 februari 2027 bevat, dezelfde datum als op de lifecyclepagina van STACKIT. Hoe dan ook eindigt die vier maanden vóór 1.36; land er niet op.

• Verlopen versies zijn geen optie

  1.32, 1.33 en 1.34 zijn verlopen; de verplichte update geldt. Een zelf beheerde broker op SKE gaat mee met elke clusterupgrade, dus plan de brokerupgrades samen met die van het cluster.

Beslissingen van de architect

• Kafka-compatibele broker of RabbitMQ voor streams

  Een stream bewaart berichten nadat ze zijn gelezen en laat consumers binnen de retentietijd opnieuw afspelen; de volgorde geldt per partitie. Een queuebericht is weg zodra de consumer het verwijdert. Spelen uw consumers opnieuw af, dan is RabbitMQ een redesign en geen vervanging.

• Wie de broker beheert

  Een broker op SKE dimensioneert, beveiligt, upgradet en back-upt u zelf. Leg de eigenaar van de piketdienst en het upgraderitme vast in het plan.

• Hoe queuegedrag wordt nagebootst

  OCI Queue heeft een visibility timeout en een maximaal aantal leveringen; RabbitMQ levert onbevestigde berichten opnieuw en biedt berichtverloop en dead-letter exchanges (RabbitMQ-functies, geen STACKIT-documentatie: controleer ze op de planversie die u kiest).

• Clientprotocol

  De STACKIT RabbitMQ-pagina noemt MQTT en STOMP als plug-ins en noemt AMQP op die pagina niet. Bevestig welk protocol uw clients spreken voordat u bouwt.

• Cutovervolgorde en het replayvenster

  Producers, consumers en de periode van dubbel draaien zijn uw ontwerp; de run geeft alleen afhankelijkheidsgolven (queues en pool in golf 1, streams in golf 2).

Vragen van integratieteams

Bronnen

• Oracle-documentatie: overzicht van Streaming
• Oracle-documentatie: overzicht van Queue
• STACKIT-documentatie: architectuur van RabbitMQ
• STACKIT-documentatie: lifecycle van SKE Kubernetes-versies