Une plateforme Kafka partagée, pas un cluster par projet

Quand un projet a besoin de Kafka, le plus rapide est de lui donner un cluster. Puis le projet suivant a le sien, et l’organisation finit avec autant de clusters que de projets, chacun configuré par qui était là au moment de son installation.

Le diagnostic que j’ai rendu cette année partait de deux phrases.

Un cluster Kafka pour chaque projet n’est pas une solution abordable, et l’administration d’un cluster demande une expertise très élevée

Une compétence rare, dispersée dans chaque projet, finit par n’appartenir à personne. Ce qui remplace ces clusters, c’est une offre. Une seule équipe transverse les exploite: elle met à jour les règles, les diffuse et assure la maintenance de la plateforme. Les projets ne se préoccupent plus de l’infrastructure et bénéficient d’une sécurité conforme aux standards et d’une haute disponibilité qu’ils n’auraient pas construites seuls. Les environnements hors production, performance et production sont séparés, et l’ajout ou le retrait d’un broker ne touche aucun projet.

Les topics vivent dans du code. Un dépôt git rassemble tous les topics de tous les environnements, avec leurs partitions, leur rétention, leurs droits d’accès et leur schéma; une chaîne CI/CD valide et applique chaque demande, et ce même dépôt sert de catalogue central de l’existant. Toute autre modification d’un cluster passe par un ticket de support. Les équipes ont accès au monitoring de tous les environnements, et des projets starters et des sessions de mise à niveau diffusent les bonnes pratiques dans les projets.

L’objection, c’est l’autonomie. Mais un projet a rarement choisi son facteur de réplication pour de bonnes raisons: il a pris une valeur par défaut. Ce qu’il doit vraiment décider, ses topics, ses clés, sa rétention, il le décide toujours, dans un fichier qu’il peut lire et faire relire.

Centraliser ce qui demande de l’expertise, laisser aux projets ce qui demande de connaître le métier