Woran denken Sie, wenn Sie „Kafka“ hören? An das Apache-Projekt, das auf Brokern mit lokalen Festplatten läuft? Das stimmt so nicht mehr: Kafka hat sich zu einem Standard-Protokoll entwickelt, für das es inzwischen verschiedene Implementierungen gibt.
Die Drop-in-Alternativen lassen sich grob in zwei Gruppen unterteilen:
Die erste Gruppe behält die Form von Kafka bei und tauscht die Engine aus. Redpanda ist das bekannteste Beispiel: gleiches Protokoll, aber keine JVM.
Die zweite Gruppe verändert die Architektur selbst. WarpStream, AutoMQ, Bufstream und Nisshi schreiben Daten direkt in Object Storage. Keine lokalen Festplatten für das Log, keine zonenübergreifende Replikation. In Cloud-Umgebungen, in denen der Datentransfer zwischen Verfügbarkeitszonen die Rechnung dominiert, kann es Kosten signifikant reduzieren. Aber: S3 ist nicht für Schreibzugriffe im einstelligen Millisekundenbereich gebaut. Diskless-Architekturen nutzen daher Batching und Buffering, um dies zu umgehen, was zu zusätzlicher Latenz führt. Bei Echtzeit-Betrugserkennung kann das eine Rolle spielen. Für asynchrone Geschäftsprozesse, das Verschieben von Logs oder Metriken oder das Streamen von Daten in den Data Lake spielt es meist keine Rolle.
Rund um die Broker gibt es eine weitere Schicht, die Aufmerksamkeit verdient: Client-Bibliotheken, die Retries und Error-Topics übernehmen, anstatt dies jedem Team selbst zu überlassen. Proxys und Gateways für Multi-Protokoll-Unterstützung (Anbindungen über HTTP, SSE, gRPC, MQTT, WebSocket …), feingranulare Authentifizierung und Zugriffe über virtuelle Topics. Serverless-Setups, die es Consumern erlauben, auch abwärts zu skalieren (scale to zero).
Und auch Apache Kafka selbst ist nicht stehengeblieben. KIP-932 bringt Share Groups: Consumer, die dieselbe Partition kooperativ lesen, mit Bestätigungen pro Nachricht (Per-Message Acknowledgement). KIP-1150 bringt diskless Topics in das Open-Source-Kafka.
Die Entscheidung für oder gegen Kafka ist kein einfaches Ja oder Nein. Heute heißt es vielmehr: Wenn Sie sich für Kafka entscheiden, welche Implementierung nutzen Sie? Was braucht Ihre Workload tatsächlich: Wollen Sie für Latenz optimieren, oder für (Betriebs-)Kosten? Und was brauchen Sie drumherum?
Lutz Hühnken
Unabhängiger Berater für verteilte Systeme und Messaging
Lutz Hühnken ist ein erfahrener Softwarearchitekt und Manager mit über zwei Jahrzehnten Erfahrung in verteilten Systemen und Messaging-Technologien. Heute begleitet er als unabhängiger Berater Organisationen unter anderem durch die technischen und organisatorischen Herausforderungen bei der Einführung von Event-Driven Architecture.