Von Andrew Tan
Zwei Fakten, die ständig vermischt werden
Apache Kafka ist weiterhin ein offenes Protokoll. Sie können es auf MSK betreiben, auf einem von Ihnen betriebenen Cluster, auf Redpanda oder auf der Confluent Platform. Das Wire-Format wurde nicht übernommen.
Confluent, das Unternehmen, das dieses Protokoll zum Standard für den kommerziellen Kafka-Stack gemacht hat, gehört seit dem 17. März 2026 zu IBM. IBM hat etwa 11 Milliarden US-Dollar, 31 Dollar pro Aktie bezahlt. Am ersten Tag lautete die Geschichte nicht „Wir bleiben das unabhängige Kafka-Unternehmen“. Am ersten Tag ging es um watsonx.data, IBM MQ, webMethods und IBM Z. Streaming als Treibstoff für eine KI-Datenplattform und hybride Automatisierung.
Betrachten Sie diese beiden Dinge als dasselbe Ereignis, werden Sie die nächsten 18 Monate an Produktentscheidungen verschlafen. Trennen Sie sie, wird das nächste Gespräch mit Ihrem Anbieter deutlich nützlicher.
Was tatsächlich abgeschlossen wurde
Ich habe den technischen Kafka-Vergleich bereits geschrieben. Dies hier ist der Konzentrationsbeitrag.
Am Tag des Abschlusses hat IBM die These bereits im Titel der Pressemitteilung formuliert: Real-time Data als Motor für Enterprise AI und Agents. Rob Thomas sprach von Modellen und Agents, die auf das reagieren, was gerade passiert. Jay Kreps, in diesem Zitat noch CEO, sprach davon, die Daten der Welt bei IBM-Maßstab in Bewegung zu setzen.
Das ist eine andere Produktwette als „bester Kafka“.
„Best Kafka“ bedeutet Partition-Rebalances, Connector-Qualität, Flink-Packaging, Cloud-SKUs und die Frage, ob Ihre Consumer-Lag-Seite an einem Dienstag noch funktioniert. IBMs Wette bedeutet, dass Confluent Cloud und Platform in Richtung watsonx, MQ und dem Mainframe gezogen werden. Der Kafka-Log ist die Auffahrtsrampe. Das Ziel ist IBMs KI- und Integrations-Suite.
Sie können diese Wette gut finden. Viele Unternehmen leben bereits in dieser Suite. Sie sollten jedoch nicht so tun, als wäre es dieselbe Roadmap, die Confluent als börsennotiertes Unternehmen verkauft hat.
Der Gründer ist gegangen. Das Protokoll ist geblieben.
Am 13. August ist Jay Kreps nach fast zwölf Jahren zurückgetreten. Gründerwechsel nach einem 11-Milliarden-Abschluss sind normal. Sie verraten auch, wo die Entscheidungen künftig getroffen werden.
Roadmaps wurden früher in Mountain View auf einer Kafka-Unternehmensuhr diskutiert. Jetzt werden sie innerhalb von IBM Software auf einer watsonx- und Mainframe-Uhr diskutiert. Connector-Taktung, Cloud-Packaging und die Bedeutung von „supported“ folgen nun dieser Uhr.
Ein konkretes Signal gab es Ende Oktober. IBM kündigte die watsonx.data-Integration für Apache Flink an – mit einem visuellen Canvas und einem Python-SDK, das Jobs auf Confluent Platform for Apache Flink überträgt. Das ist kein Kafka-Killer. Es ist IBM, das Stream Processing in die watsonx.data-Produktlinie einbettet. Wenn Sie Confluent gekauft haben, weil Sie ein unabhängiges Streaming-Unternehmen wollten, lesen Sie diesen Satz bitte noch einmal.
Ich behaupte nicht, dass das Produkt schlechter geworden ist. Ich habe keinen Telemetrie-Zugang zu Confluent Cloud. Ich behaupte, dass sich der Schwerpunkt verschoben hat – und dass man das öffentlich sehen kann.
Kafka die Sprache, IBM der Verlag
Denken Sie an Kafka als eine Sprache. Viele Menschen sprechen sie. Die Grammatik ist offen. IBM hat die größte Schule gekauft, die den kommerziellen Dialekt unterrichtet, die Lehrbücher gedruckt und den Zertifizierungsstand auf der Konferenz betrieben hat.
Sie können die Sprache weiterhin sprechen. Sie können Menschen einstellen, die sie sprechen. Sie können einen Cluster betreiben, der IBM nie einen Dollar schickt.
Was Sie nicht voraussetzen können, ist, dass der kommerzielle Standardpfad (Confluent Cloud, Confluent Platform, der Connector-Katalog, auf den Sie sich bereits standardisiert haben) für die Unabhängigkeit von Kafka kämpfen wird. Er wird der IBM-Daten- und KI-Plattform folgen. Das Dual-Running eines Topics in watsonx.data wird mehr Liebe bekommen als die Trivialisierung des Verlassens.
Anbieter folgen ihrer These. Ihre Aufgabe ist es, zu bemerken, dass sich die These geändert hat.
Drei Fragen, die Ihr nächstes QBR enthalten sollte
Überspringen Sie die Folie „Seid ihr weiterhin zu Kafka verpflichtet?“. Natürlich sind sie das. Kafka ist das Asset.
Stellen Sie die operativen Fragen, die die Pressemitteilung nicht abdeckt.
Dual-Run für die nächsten zwei Jahre
Falls IBM SKUs zusammenlegt, Konsolen umbenennt oder Sie auf eine watsonx-Steuerungsebene umstellt, brauchen Sie einen Zeitraum, in dem der alte und der neue Pfad dieselben Ergebnisse liefern. Dual-Run ist langweilig. Dual-Run ist der Weg, wie Sie eine Anbieterfusion ohne Wochenend-Cutover überstehen.
Replay, wenn MQ, Z und ein Warehouse im selben Incident stecken
Die meisten Kafka-Teams wissen bereits, wie man eine Consumer Group zurückspult. Der schwierige Fall ist gemischt: ein Stream, eine Mainframe-Transaktion, eine nächtliche ERP-Datei und eine Iceberg-Tabelle, die bereits jemand abgefragt hat. IBMs Diagramm vom ersten Tag stellt diese Dinge in eine Familie. Ihr Incident an einem Dienstagabend braucht trotzdem eine Person, die einen Teil zurückspulen kann, ohne die anderen zu beschädigen.
Ob Batch weiterhin einen zweiten Orchestrator braucht
Wenn die Antwort lautet „Nutzt Airflow für die Dateien und Confluent für die Topics“, haben Sie keine Plattform gekauft. Sie haben eine Streaming-Suite gekauft und die Trennung beibehalten, die Sie bereits hatten. Lassen Sie sich einen Workflow zeigen, der eine verspätete Datei und ein fehlerhaftes Topic mit derselben Verantwortlichkeit replayt.
Wenn Ihr Account Executive diese Fragen nicht ohne Solution Architect und eine Woche Verzögerung beantworten kann, haben Sie Ihr Signal.
Das Problem, das nicht übernommen wurde
IBM hat ein Streaming-Unternehmen gekauft. Es hat nicht Ihr Koordinationsproblem gekauft.
Sie müssen weiterhin einen Batch-Job nachholen, der das Zeitfenster verpasst hat, während der Stream weiterlief. Sie müssen weiterhin drei Stunden Poison Messages replayen, ohne doppelt in das Warehouse zu schreiben. Sie müssen weiterhin eine Slowly Changing Dimension mit einem Live-Topic joinen. Sie müssen einem neuen Mitarbeiter am Freitagnachmittag weiterhin sagen können, welches System die Single Source of Truth ist.
Nichts davon steckt im Kafka-Protokoll. Das IBM-Logo auf der Confluent-Konsole macht es nicht einfacher. Manches wird sogar schwieriger, wenn der kommerzielle Stack auf Agents und watsonx ausgerichtet wird, während Ihre tatsächliche Arbeitslast immer noch lautet: „Bringt die Zahlungsdatei und das Fraud-Topic in Übereinstimmung.“
Die Teams, mit denen ich spreche und die bei diesem Thema ruhig bleiben, haben nicht „Kafka ist Open Source, uns geht’s gut“ in Slack gepostet. Sie behandeln den Broker bereits als Transport und halten die Laufzeitumgebung (Retries, Abhängigkeiten, Replay, Freigaben) an einem Ort, den sie selbst kontrollieren.
Wo wir hineinpassen
Bei layline.io arbeiten wir mit Teams, die Kafka sprechen und trotzdem um 18 Uhr Dateien anlanden müssen. Wir sind kein Kafka-Ersatz und kein IBM-Alternative. Wir sind die Laufzeitumgebung, die über Batch und Streaming hinweg sitzt, sodass die Koordinationsarbeit nicht in der Suite des Streaming-Anbieters stattfindet.
Wenn IBMs Plattform für Sie das richtige Zuhause ist, nutzen Sie sie. Verwechseln Sie nur nicht „wir produzieren weiterhin Kafka-Records“ mit „unser Betriebsmodell ist unverändert“. Die Records können gleich aussehen. Die Schwerkraft um sie herum kann es nicht.
Wenn Sie Confluent Cloud oder Platform nutzen und Protokoll-Komfort von Vendor-Schwerkraft trennen möchten, melden Sie sich bei uns. Wir haben Teams dabei geholfen, Dual-Run und Replay über Batch und Stream zu planen, ohne auf die nächste Umbenennung zu warten.
Andrew Tan ist Serienunternehmer und Gründer von layline.io. Er baut Enterprise-Data-Processing-Infrastruktur, die sowohl Batch- als auch Real-time-Workloads in großem Maßstab verarbeitet.
