Managiertes Kafka und RabbitMQ in der Schweiz, im VPC.

Beide Engines transportieren Nachrichten, und damit endet die Ähnlichkeit. Das Folgende beschreibt ihr eigenes Verhalten, unabhängig von Hikube: dieses Verhalten entscheidet, nicht der Anbieter.

• Muss die Nachricht das Lesen überleben? Kafka führt ein Log, das mehrere Consumer in ihrem Tempo erneut lesen; RabbitMQ entfernt die Nachricht nach dem Acknowledge
• Müssen Sie Vergangenes erneut abspielen? Das ist der schnellste Test: drei Tage Ereignisse erneut abzuspielen ist bei Kafka nativ und hat in einer Arbeitsschlange keine Entsprechung
• Zählt die Reihenfolge, und worüber? Kafka garantiert die Reihenfolge innerhalb einer Partition, also je Partitionierungsschlüssel: nicht global, was oft überrascht
• Ist das Routing eine Fachregel? RabbitMQ routet über Exchange, Key und Header; bei Kafka ist die Sortierung Anwendungscode
• Wie viele Consumer, und unabhängig? Mehrere Gruppen, die dasselbe lesen, ohne sich zu stören, ist Kafkas Terrain; eine Aufgabe, die ein Worker-Pool einmal konsumiert, ist RabbitMQs
• Beide können im selben Tenant koexistieren, und tun es oft: ein Ereignis-Log auf der einen Seite, Arbeitsschlangen auf der anderen

Die Dimensionierung nutzt dieselbe Instanz-Tabelle wie die managierten Datenbanken, s1.small bis m1.8xlarge, mit derselben Obergrenze: die Grössen stehen auf die Preisseite. Die Retention eines Kafka-Topics wird in Storage bezahlt, nicht in Compute, und sie treibt die Rechnung, wenn man dreissig Tage «für alle Fälle» behält. Topics und Queues, Schemas, ACLs, Partitionierung, Producer und Consumer bleiben bei Ihnen: die Plattform betreibt die Broker, nicht Ihr Nachrichtenmodell. Zwei Dinge stehen hier nicht und sind vor dem Entwurf zu erfragen: die Versionsnummern der Engines und die Grenzen je Instanz (Durchsatz, Partitionszahl, Nachrichtengrösse).

Als managierte DB-Instanz auf der Preisseite: s1.small (30 CHF/Monat) bis m1.8xlarge (2880 CHF/Monat). Das sind die publizierten Database-Kataloggrössen, die Kafka einschliessen. RabbitMQ ist der AMQP-Pfad desselben Messaging-Produkts. Ein «Version X»-Kafka-SKU gibt es nicht.

Nicht, wenn Sie den Managed Service nehmen. Kubernetes-Apps bleiben Clients. Kafka selbst auf Workern ist möglich: dann nicht mehr das Managed-Produkt. Worker automatisch verteilt, keine RZ-Wahl.

Hidora SA betreibt die managierten Broker, die drei RZ und Support FR/EN. Sie behalten Topics, Queues, Schemata, ACLs, Producer und Consumer. Terraform-Integration in Vorbereitung: heute Hikube-API und Konsole.

Fach-Integration, die die Schweiz nicht verlassen darf. Ersatz eines CLOUD-Act-Busses. AMQP-Queues schon unter VMware. Redis bleibt Cache: das ist nicht dieses Produkt.

Nein. Das ist managiertes Kafka und RabbitMQ im Schweizer VPC, betrieben von Hidora SA. Kein globaler Serverless-Bus, keine Event Hubs, keine Kafka-Versionsnummer hier. Producer und Consumer bleiben bei Ihnen.