Kafka et RabbitMQ managés en Suisse, dans le VPC.

Les deux moteurs transportent des messages et s’arrêtent là de se ressembler. Ce qui suit décrit leur comportement propre, indépendamment de Hikube : c’est ce comportement qui décide, pas le fournisseur.

• Le message doit-il survivre à sa lecture ? Kafka conserve un journal que plusieurs consommateurs relisent à leur rythme ; RabbitMQ retire le message de la file quand il est acquitté
• Avez-vous besoin de rejouer le passé ? C’est la question qui tranche le plus vite : rejouer trois jours d’événements est natif côté Kafka, et n’a pas d’équivalent dans une file de travail
• L’ordre compte-t-il, et sur quoi ? Kafka garantit l’ordre à l’intérieur d’une partition, donc par clé de partitionnement : pas globalement, ce qui surprend souvent
• Le routage est-il une règle métier ? RabbitMQ route par exchange, clé et en-têtes ; côté Kafka, le tri est du code applicatif
• Combien de consommateurs, et indépendants ? Plusieurs groupes lisant la même chose sans se gêner est le terrain de Kafka ; un travail consommé une fois par un pool d’ouvriers est celui de RabbitMQ
• Les deux peuvent coexister dans le même tenant, et c’est fréquent : un journal d’événements d’un côté, des files de travail de l’autre

Le dimensionnement passe par la même grille d’instances que les bases managées, du nano au 2xlarge, avec le même plafond : les tailles sont sur la page tarifs. La rétention d’un topic Kafka se paie en stockage, pas en calcul, et c’est elle qui fait grossir la facture quand on garde trente jours « au cas où ». Restent de votre côté les topics et les files, les schémas, les ACL, le partitionnement, les producers et les consumers : la plateforme opère les brokers, pas votre modèle de messages. Deux choses ne sont pas publiées ici et se demandent avant de concevoir : le numéro de version des moteurs, et les limites par instance (débit, nombre de partitions, taille de message).

Comme une instance de base managée sur la page tarifs : nano (4 CHF/mois) à 2xlarge (160 CHF/mois). Ce sont les tailles publiées du catalogue databases, qui inclut Kafka. RabbitMQ est le chemin AMQP du même produit messaging. Il n’existe pas de SKU Kafka « version X ».

Pas si vous prenez le service managé. Vos apps dans Kubernetes restent des clients. Si vous insistez pour opérer Kafka vous-même sur le cluster, c’est possible sur des workers : ce n’est plus le produit managé. Workers répartis automatiquement, pas de choix de DC.

Hidora SA opère les brokers managés, les trois DC et le support FR/EN. Vous gardez topics, files, schémas, ACL, producers et consumers. Intégration Terraform en préparation : aujourd’hui, API Hikube et console.

Intégration métier qui ne doit pas sortir de Suisse. Remplacement d’un bus Cloud Act. Files AMQP déjà là sous VMware. Redis reste le cache : ce n’est pas ce produit.

Non. C’est Kafka et RabbitMQ managés dans le VPC suisse, opérés par Hidora SA. Pas un bus serverless mondial, pas Event Hubs, pas un numéro de version Kafka publié ici. Les producers et consumers restent les vôtres.