Plattform-Engineering, Cloud-Kosten und das "Copy-Paste-Problem": Alex Kropp im Interview

Alex, du beschreibst dich selbst als Plattform-Ingenieur. Was machst du da eigentlich den ganzen Tag?

Alexander Kropp: (lacht) Ich mache Plattform-Dinge. Das heißt, ich baue und orchestriere komplexe Systeme in der Cloud, primär in Azure. Aber man hat die Cloud ja nicht, um die Cloud zu haben, sondern damit Dinge darauf laufen.

Ich stelle also komplette Plattformen für Produktteams und Entwickler bereit. In der Mitte steht oft ein Kubernetes-Cluster, dazu Datenbanken, Storage und eben auch Kafka.

Meine Hauptaufgabe ist es, komplexe Probleme, vorzugsweise durch Infrastructure as Code (IaC), zu abstrahieren. Ich baue Self-Service-Lösungen, damit Entwickler möglichst einfach neue Ressourcen bestellen können, sei es eine Datenbank, Compute-Ressourcen oder eben ein Kafka-Topic, und die Einstiegshürde so niedrig wie möglich ist.

Was ist der konkrete Mehrwert, den du Kunden bringst? Wie sieht eine Umgebung aus, nachdem du 6 Monate dort warst?

Alexander Kropp: Das kommt natürlich darauf an, wo der Kunde startet. Fangen wir auf der grünen Wiese an, bringe ich die Erfahrung mit, eine robuste, hochverfügbare Cloud-Plattform inklusive Monitoring und Logging aufzubauen, die am Ende nicht fünf Leute für die reine Wartung bindet.

Am Ende steht eine einfache, erweiterbare Codebasis, die komplexe Probleme abstrahiert.

Aber der vielleicht wichtigste Punkt ist der Wissenstransfer. Cloud- und Infrastruktur-Themen lernst du weder in der Ausbildung noch im Studium. Wenn Unternehmen migrieren, fehlt dieses Wissen intern. Mein Ziel ist es immer, die internen Mitarbeiter mitzunehmen. Ich mache viel Pair-Programming, damit das Team nach einer gewissen Zeit auch ohne mich arbeiten kann.

Es wird viel über die Kosten der Infrastruktur gesprochen. Warum geben Unternehmen oft zu viel Geld für die Cloud aus?

Alexander Kropp: Ich sehe oft bei Kunden, dass die Cloud-Kosten dreimal so hoch sind, wie sie sein müssten. Das Problem ist oft, dass die einzelne Person im Unternehmen keine direkte Budgetverantwortung hat und sich wenig Gedanken über die Kosten macht.

Das summiert sich extrem schnell. Oft wird ein Setup als Blaupause für künftige Services verwendet. Wenn dieses fehlerhaft konfiguriert oder überdimensioniert war, pflanzt sich das fort. Ehe du dich versiehst, läuft ein einfacher NGINX, der drei Requests pro Stunde bekommt, auf einer VM, die 300 Euro im Monat kostet.

Du bist nicht nur Plattform-Engineer, sondern auch der Mitautor von Kafka in Action. Wie siehst du den Einsatz von Kafka bei deinen Kunden?

Alexander Kropp: Kafka wird von sehr vielen Produktteams genutzt, um Daten auszutauschen. Ich habe schon alles gesehen: Daten, die für Analytics gepusht werden, oder sogar synchrone Prozesse, die über Kafka abgebildet werden.

Kafka ist oft der Hammer, und plötzlich sieht alles aus wie ein Nagel. Wenn es einfach ist, ein Topic und einen User bereitzustellen – weil es dafür vielleicht schon einen Automatismus gibt – nutzen die Teams eben Kafka, auch wenn es für den Anwendungsfall vielleicht Overkill ist. Wenn Kafka nun mal da ist und der Aufwand, etwas anderes zu nutzen, höher wäre, wird es eben genommen.

Was sind die größten Herausforderungen, die du bei Entwicklungsteams im Umgang mit komplexer Technologie siehst?

Alexander Kropp: Die größte Herausforderung ist: Der Technik-Stack im Cloud-Bereich ist verdammt groß. Es ist selten geworden, dass sich Leute nur mit einer Technologie richtig gut auskennen müssen. Es ist unmöglich, sicherzustellen, dass alle alles wissen.

Dadurch entsteht das, was ich das "Copy-Paste-Problem" nenne. Alle bauen absichtlich oder unabsichtlich Blueprints, die kopiert werden. Wenn aber kein tiefes Verständnis für die Technologie da ist, werden Dinge kopiert, die vielleicht für den ursprünglichen Anwendungsfall passten, aber nicht für den neuen.

Man kommt mit Copy-Pasting eine Zeit lang zurecht, wenn die Last niedrig und die Kosten egal sind. Aber irgendwann fällt man damit auf die Nase. Und dann sitzen zehn Leute drei Monate an einem Performance-Bottleneck.

Kannst du ein typisches Beispiel für so einen Fehler geben, der durch Halbwissen entsteht?

Alexander Kropp: Oh ja, gerade bei Kafka sieht man das oft. Mein "Lieblingsbeispiel": Ich habe gesehen, wie Offsets manuell committet wurden. Es wurden 1.000 Nachrichten als Batch geholt und verarbeitet, aber der Offset wurde im Code nur um 1 inkrementiert. Was passiert? Beim nächsten Fetch “neuer” Nachrichten werden 1.000 Nachrichten geladen, von denen 999 schon gelesen wurden. Das erzeugt eine extreme Last.

Ein anderer Klassiker: Entwickler spielen an der Konfiguration herum, um mehr Performance rauszuholen. Ich habe mehrfach gesehen, dass der Consumer-Parameter fetch.max.wait.ms auf 0 gesetzt wird. In der Realität fangen sie damit an, ihren eigenen Kafka-Cluster zu DDoSen, weil die Consumer in einer engen Schleife Requests an die Broker senden.

Ist das ein Kafka-Problem oder liegt die Ursache woanders?

Alexander Kropp: Nein, das ist kein Kafka-Problem, das siehst du bei Datenbanken oder Kubernetes genauso. Ich persönlich finde die offizielle Kafka-Doku, oder halt unser Buch (lacht), sehr gut, um ein grundlegendes Verständnis zu bekommen.

Das Problem ist organisatorisch. Der Alltag der Entwicklungsteams ist oft vom Business getrieben, die Product-Owner sitzen ihm mit dem nächsten Feature im Nacken. Es ist ein Problem, wie in Unternehmen gearbeitet wird.

Das klingt stark nach der DevOps-Philosophie. Aber du betonst die Rolle des Plattform-Teams als "Center of Excellence". Ist "You build it, you run it" also überbewertet?

Alexander Kropp: "Weniger DevOps" würde ich so gar nicht sagen. Aber die Entwicklungsteams alleine zu lassen, ist der falsche Ansatz. Man braucht eine zentrale Anlaufstelle.

In Abteilungen ist eine offene Kommunikation extrem wichtig. Das Plattform-Team muss Verantwortung für seine Services übernehmen und stolz darauf sein. Die Haltung muss sein: "Ich bin der Experte. Ich helfe dir gerne." und nicht "Oh, jetzt will der blöde Entwickler schon wieder was von mir."

Genau hier sehe ich das Plattform-Team als Multiplikator für das gesamte Unternehmen. Man darf nicht sagen: "Jedes Team ist für seinen Tech-Stack selbst verantwortlich." Stattdessen sollte man ein Expertenteam haben, das für den Betrieb von Kafka, Kubernetes oder Datenbanken verantwortlich ist.

Ganz wichtig: Man darf nicht beim Bereitstellen aufhören nach dem Motto "Friss oder stirb". Diese Teams müssen als Multiplikatoren und Anlaufstelle gesehen werden. Eine zusätzliche Person in einem Plattform-Team kann im Zweifel die Arbeit von drei oder vier Entwicklern in den Produktteams einsparen, weil sie deren Zeit für ihre eigentlichen Fachthemen freiräumt.

Wie viel Aufwand ist es eigentlich, Kafka zu betreiben?

Alexander Kropp: Wenn man einmal ein vernünftiges Setup mit Infrastructure as Code und skalierbaren Lösungen, zum Beispiel mit dem Strimzi-Operator auf Kubernetes, aufgesetzt hat, braucht der reine Betrieb nicht mal eine Vollzeit-Person.

Der Punkt ist: Ein Großteil der Arbeit liegt nicht im Hosten des Kafka-Clusters selbst, sondern in allem, was drumherum anfällt: die Orchestrierung der Topics und User, die Governance und vor allem das Enablement der Teams. Diese Arbeit nimmt dir kein Kafka as a Service-Anbieter ab. Wenn das System einmal steht, sind 80% der Arbeit Enablement.

Was ist dein persönliches Lieblings-Tool aus dem Kafka-Ökosystem, das vielleicht nicht jeder kennt?

Alexander Kropp: Karapace. Das ist ein Open-Source REST-Proxy und gleichzeitig eine Schema-Registry unter der Apache-Lizenz. Es gibt da nicht so viele Alternativen, und im Vergleich zu manchen proprietären Lösungen, die von Herstellern stark gepusht werden, halte ich Karapace für die wesentlich bessere Wahl.

Dein abschließender Appell an alle Plattform-Teams da draußen?

Alexander Kropp: Zwei Dinge. Erstens: Fragt euch immer: Wenn ihr eure eigenen Services nutzen müsstet, wärt ihr damit zufrieden? Ist das "convenient"?

Zweitens: Setzt auf Automatisierung! Unbedingt. Setzt auf Infrastructure as Code. Es macht alles wartbar, es ist lebende Dokumentation, es hat nur Vorteile. Sobald jemand in einer GUI herumklickt – vielleicht zum Debuggen, okay – aber für den Betrieb? Niemals.

Eine GUI ist prima zum Gucken, nicht zum Anfassen in der Produktion. Wenn alles im Code ist, vorzugsweise in lesbarem YAML mit Kommentaren, kann man immer nachvollziehen, wer was warum gebaut hat.

Danke für das Interview, Alex! Wo können wir dich online finden?

Alexander Kropp: Du kannst mich auf LinkedIn finden.