Der Senior-Dev-Faktor: Wie man Kafka-Projekte rettet

Hartmut, ich bezeichne dich gerne als den Senior Dev für Kafka Streams. Du bist oft derjenige, der in verfahrene Projekte reingeht und das Team dazu befähigt, die Deadline doch noch zu halten. Wenn du dir deine Rolle malen dürftest: Was macht einen echten Senior eigentlich aus?

Hartmut: Für mich ist es die Fähigkeit, das Big Picture nie aus den Augen zu verlieren, aber gleichzeitig tief im Maschinenraum zu stehen. Es reicht nicht, nur schöne Architekturdiagramme zu malen.

Im Projektalltag bin ich vielleicht zu 30 % Architekt, je nach Projektphase mal mehr, mal weniger. Ich entwerfe Topologien und diskutiere das Datenmodell. Aber den Rest der Zeit bin ich hands-on.

Ich schreibe Code, ich debugge live in der Umgebung und, auch wenn es nicht immer Spaß macht, ich kümmere mich um die Deployment-Pipelines und das Monitoring. Mir ist es extrem wichtig, den Zustand der Umgebungen genau zu kennen. Gerade nach einem Deployment.

Bei aller Liebe zu automatisierten Tests: Ich verifiziere und evaluiere gerne selbst manuell. Das trainiert nicht nur den Umgang mit den Systemen und Debugging-Tools, sondern gibt auch die letzte Sicherheit, dass wirklich alles läuft.

Das klingt nach der klassischen Feuerlöscher-Rolle. Du gehst dahin, wo es brennt. Wie nimmst du dabei das Team mit, das vielleicht schon frustriert ist?

Hartmut: Kommunikation ist hier fast wichtiger als Code. Ich bin im Projekt sehr präsent, hänge viel auf Slack, ziehe Leute in Calls. Oft sehe ich Teams, die eigentlich kompetent sind, aber vor der Komplexität der modernen Infrastruktur erstarren.

Meist haben die Teams mit der Wahl des Tech-Stacks und der Architektur eine gute Wahl getroffen und liegen gar nicht weit daneben. Es mangelt noch etwas an Erfahrung, einigen Korrekturen und einem mentalen Modell der Datenflüsse im Zusammenspiel mit verteilten Systemen und Partitionierung.

Oft herrschen auch Berührungsängste mit der Infrastruktur. Das betrifft Kafka, Kubernetes/OpenShift und (Persistent) Volumes. Die Entwickler trauen sich nicht, die Umgebung wirklich anzufassen, aus Sorge, etwas kaputtzumachen.

Und wie löst du diese Blockade?

Hartmut: Indem wir es gemeinsam tun – und zwar über alle Umgebungen hinweg. Es geht dabei nicht nur um die Entwicklungsumgebung. Im Projektalltag gibt es immer wieder Bedarf für umfassendere Rollouts, Migrationen oder auch mal einen kompletten Reset einer Umgebung.

Mein Ansatz ist hier nicht das bloße Gegen-die-Wand-Fahren, sondern das tiefe Verständnis vorab: Was ist nötig? Welche Auswirkungen hat unser Vorhaben? Wir erstellen gemeinsam einen Plan, der alle Details berücksichtigt und eine dem Projekt angemessene Balance zwischen Aufwand und Downtime findet.

Wenn so ein Plan dann aufgeht, ist das extrem erfüllend. Das ist für mich der beste Weg, Expertise aufzubauen. Neben den rein technischen Kenntnissen schult das auch die Professionalität, die Verantwortung für das Unternehmen und den Teamgeist enorm.

Aber dafür ist doch im Alltag oft gar kein Platz? Wie schaffst du es, den Teams die Expertise rüberzubringen, wenn die Deadline drückt?

Hartmut: Ja, das Argument höre ich oft, aber etwas Zeit ist eigentlich immer da – sie wird nur oft falsch genutzt.

Um Expertise rüberzubringen, setze ich auf einen Mix aus verschiedenen Methoden: Ganz oben stehen Pair Programming und gerne auch Pair Designing. Dazu kommen regelmäßige Knowledge Sharings und Reviews in der Gruppe, um das Wissen im Team zu streuen.

Und wenn es darum geht, neue Konzepte wirklich zu durchdringen, finde ich Hackathons, PoCs oder MVPs eine gute Lösung.

Mein Rat an Teamleads ist: In Absprache mit den Teams, Hackathons aktiv in den Sprint einplanen. Gebt dem Team 2 bis 3 Tage. Lasst sie eine kleine Anwendung bauen, die einmal den kompletten Durchstich macht. Dieser Lerneffekt durch das Selbermachen in kurzer Zeit ist viel höher als bei jeder theoretischen Lektüre.

Nicht zu vergessen, eine kritische Auswertung oder Retro. Das Team wird selbstsicherer, lernt einzuschätzen, wo die Reise hingeht und mit wie viel Aufwand das verbunden sein wird.

Manchmal liegt es aber auch an der Zusammensetzung des Teams. Hast du da auch einen Blick drauf?

Hartmut: Absolut. Manchmal muss man das Team einfach ein bisschen neu mischen.

Es braucht in jedem Kafka-Projekt mindestens eine Person, die diesen inneren Lösungsdrang hat – jemanden, der sich wirklich in die Technologie verbeißen will. Wenn diese Rolle fehlt, stockt das Projekt.

Als Senior schaue ich mir die Dynamik an: Wer hat den Drive? Wen müssen wir vielleicht anders einsetzen? Manchmal reicht es, die Rollen leicht zu verschieben, um den Knoten zu lösen.

Aber der Grund, dass Kafka Streams Projekte nicht immer einfach sind, ist ja nicht rein organisatorisch. Auch Kafka Streams ist technisch nicht gerade einfach zu beherrschen. Können wir da was besser machen als Kafka Community?

Hartmut: Die Kafka Streams DSL, und das technische Grundverständnis bilden die Basis, aber der wirkliche Knackpunkt ist das Mindset für verteilte Systeme. Man muss die Partitionierung immer mitdenken. Ohne dieses Verständnis läuft man in Sackgassen.

Ein weiterer Aspekt, der ebenso umfassend und fordernd ist, sind Deployment-Modell und Betrieb. Was wir als Community besser machen können?

Ich glaube, gerade in den Bereichen Deployment, Konfiguration, hochverfügbarem Betrieb, Monitoring & Analyse und letztlich Entstörung könnte es mehr Guides und Best Practices geben. Natürlich lässt sich nicht alles pauschal lösen; dafür ist die Domäne zu komplex – aber es ist sicherlich Luft nach oben.

Hast du das Gefühl, die Technologie ist für manche Anwendungsfälle vielleicht sogar zu komplex?

Hartmut: Ja, das ist ein Punkt, der mich aktuell stark beschäftigt. Wir haben eine Lücke im Ökosystem.

Auf der einen Seite haben wir einfache Producer/Consumer-Anwendungen. Auf der anderen Seite die Schwergewichte wie Kafka Streams oder Flink. Aber für viele Kunden, die mittelgroße Datenmengen haben, ist Kafka Streams mit seinem State Management, Rebalancing und den Ops-Anforderungen oft Overkill.

Ich wünsche mir für die Zukunft eine Lösung, die irgendwo dazwischen liegt: Einfacher als Kafka Streams, aber mächtiger als ein purer Consumer. Vielleicht sehen wir da in den nächsten Jahren Bewegungen im Markt. Bis dahin müssen wir aber lernen, die Komplexität von Kafka Streams zu beherrschen.

Kommen wir zum Abschluss zu den praktischen Dingen. Hast du konkrete Tool-Empfehlungen für die Leserschaft?

Hartmut: (lacht) Natürlich KSTD (Kafka Streams Topology Design).

Dein eigenes Tool. Erzähl kurz, warum man das braucht.

Hartmut: Weil Code oft nicht die ganze Wahrheit erzählt – oder zumindest nicht auf einen Blick. KSTD ist ein Framework und Design-Standard, um Kafka Streams Topologien grafisch zu entwerfen und zu dokumentieren.

Es hilft enorm, wenn man mit dem Team oder Architekten über komplexe Joins und Datenflüsse spricht und dabei auf ein Bild statt auf Java-Code schaut. Es schließt die Lücke zwischen Code und Architektur-Board.

Ich schreibe in der Regel keine Zeile Code, bevor ich nicht durch das Design zuversichtlich bin, dass die Topologie funktioniert. Da dieser Teil im Kopf oder in Excalidraw stattfindet, spart das ungemein Zeit. Die eigentliche Implementierung geht danach oft überraschend flott und macht riesigen Spaß.

Und noch ein Tool, welches nicht von dir ist? (lacht)

Hartmut: DuckDB.

DuckDB? Die in-process SQL OLAP Datenbank? Für Kafka?

Hartmut: Genau. Das ist mein absoluter Geheimtipp für Debugging. Oft hast du Situationen, wo du einfach wissen willst: Wo ist die Message mit ID XY? oder Wie ist die Verteilung der Keys in diesem Topic?. Kafka selbst bietet ja kein SELECT * WHERE ID = …

Was ich mache: Ich nehme den Console Consumer, pipe den Output als JSON raus und leite ihn direkt in DuckDB weiter. DuckDB erlaubt es mir dann, SQL auf den eingehenden Stream loszulassen. Ich kann filtern, aggregieren, JSON-Felder auswerten – alles ad-hoc in der Konsole.

Das ist genial. Quasi SQL-Debugging auf der Command Line ohne Infrastruktur-Overhead.

Hartmut: Exakt. Es ist der schnellste Weg, um Licht ins Dunkel der Daten zu bringen, ohne erst eine komplexe Infrastruktur aufzubauen.