Die versteckten Kosten beim Aufbau einer eigenen Batch-Streaming-Integrationsschicht

Von Andrew Tan

Die versteckten Kosten beim Aufbau einer eigenen Batch-Streaming-Integrationsschicht

Mit KI-unterstütztem Programmieren erscheint der Aufbau eigener Data Pipelines günstiger denn je. Doch die tatsächlichen Kosten liegen nicht im initialen Aufbau – sie entstehen in der Wartung, den Bereitschaftsdiensten und der angesammelten Komplexität, die sich im Laufe der Zeit vervielfacht.

Hier ist ein Gespräch, das immer wieder vorkommt:

Engineering Manager: "Wir brauchen eine neue Data Pipeline für das Kundenanalyseprojekt."

Senior Engineer: "Ich kann das bauen. Mit Cursor und Copilot kann ich die Kernlogik in ein paar Tagen fertigstellen."

EM: "Was ist mit der Wartung?"

SE: "Es ist nur ein Python-Skript mit etwas Airflow-Orchestrierung. Wie schwer kann das schon sein?"

Drei Monate später ist der Ingenieur, der es gebaut hat, im Urlaub, die Pipeline fällt unbemerkt aus, und niemand kann herausfinden, warum die Kundensegmentzahlen nicht mit dem Quellsystem übereinstimmen. Das "einfache Python-Skript" ist auf 2.400 Zeilen angewachsen, berührt drei verschiedene Datenbanken und hat genau null Dokumentation darüber, was die Geschäftslogik tatsächlich tun soll.

Die KI-Codierungsrevolution hat die Bau-Entscheidung fast kostenlos erscheinen lassen. Was sich nicht geändert hat, ist die Besitz-Entscheidung – und genau dort liegen die meisten Kosten.

Die ehrliche Buchführung

Wenn Teams die Kosten für den Aufbau ihrer eigenen Data Integration-Schicht schätzen, modellieren sie normalerweise etwas wie folgt:

So sieht die Tabelle tatsächlich nach zwölf Monaten aus:

Die Lücke entsteht nicht, weil Ingenieure schlecht im Schätzen sind. Sie entsteht, weil die Tabelle nur die Arbeit erfasst, die man im Voraus sehen kann. Die tatsächlichen Kosten sammeln sich unsichtbar an: die Anrufe um 2 Uhr morgens, die "schnellen Lösungen", die dauerhaft werden, die subtile Datenkorruption, die Tage braucht, um entdeckt zu werden.

Das Zwei-Pipeline-Problem

Es gibt einen spezifischen Fehlermodus, der Teams trifft, die ihre eigene Batch-Streaming-Infrastruktur aufbauen: das Divergenzproblem.

Man beginnt mit Batch. Es ist unkompliziert. Man schreibt einen Job, der jede Stunde läuft, Daten extrahiert, transformiert und irgendwo lädt. Funktioniert einwandfrei.

Dann fragt das Geschäft nach Echtzeit. "Können wir diese Daten in Sekunden statt in Stunden bekommen?"

Also baut man eine Streaming-Pipeline. Kafka, vielleicht Flink oder Spark Streaming. Sie konsumiert die gleichen Quelldaten und liefert sie an dasselbe Ziel. Aber die Transformationslogik ist anders — Streaming hat andere Einschränkungen, anderes Zustandsmanagement, andere Fehlermodi. Man kann den Batch-Code nicht einfach übertragen.

Jetzt hat man zwei Pipelines, die ungefähr dasselbe tun. Sie liefern leicht unterschiedliche Ergebnisse, weil der Batch-Join äußerlich und der Streaming-Join innerlich ist oder weil der Batch-Job verspätete Daten anders behandelt als das Streaming-Fenster. Wenn jemand fragt, warum die Zahlen nicht übereinstimmen, muss man beide Systeme debuggen.

Nach sechs Monaten hat man:

• Zwei Codebasen zu pflegen
• Zwei Infrastrukturen zu überwachen
• Zwei Fehlermodi zu verstehen
• Zwei Bereitschaftsdienste (oder eine sehr unglückliche Person)
• Und eine hartnäckige Frage: Warum können wir nicht einfach eine Pipeline haben?

Die ehrliche Antwort: weil Batch und Streaming wirklich unterschiedliche Paradigmen sind und die meisten DIY-Stacks nicht darauf ausgelegt sind, sie zu vereinheitlichen.

Die verborgenen Komplexitätsmultiplikatoren

Neben den offensichtlichen Kosten gibt es drei Komplexitätsmultiplikatoren, die in den ersten Schätzungen nicht auftauchen:

Schema-Evolution

Ihr Quellsystem ändert sich. Eine Spalte wird umbenannt. Ein Typ wird erweitert. Ein neues nullable Feld erscheint. In einer verwalteten Plattform wird dies gehandhabt. In Ihrer benutzerdefinierten Pipeline ist es eine Codeänderung, eine Bereitstellung und ein Gebet, dass Sie die nachgelagerten Verbraucher nicht beeinträchtigt haben.

Die tatsächlichen Kosten sind nicht die Änderung selbst. Es ist die Koordination: jedes Team benachrichtigen, das diese Daten konsumiert, ihre Schemata aktualisieren, die Integration testen, zurückrollen, wenn etwas schiefgeht. Eine zweistündige Codeänderung wird zu einem zweiwöchigen Projekt.

Fehlerbehandlung im großen Maßstab

Eine einfache Wiederholungsschleife ist leicht. Exponentielles Backoff, eine Dead-Letter-Queue, einige Warnungen – das können Sie an einem Nachmittag aufbauen.

Aber die Fehlerbehandlung in der Produktion ist fraktal. Was passiert, wenn das Ziel eine Stunde lang ausfällt? Was passiert, wenn eine Nachricht zu groß ist? Was passiert, wenn ein Schema-Mismatch einen Parsing-Fehler verursacht? Was passiert, wenn dasselbe Ereignis zweimal zugestellt wird? Was passiert, wenn Netzwerkteilungen Split-Brain-Situationen erzeugen?

Jeder Sonderfall muss behandelt werden. Jeder Handler muss getestet werden. Jeder Test benötigt Wartung. Die "einfache Wiederholungslogik" wächst zu einem verteilten Systemanliegen, in dem niemand im Team tiefes Fachwissen hat.

Beobachtbarkeitslücken

Sie müssen wissen: Läuft die Pipeline? Hält sie mit der Quelle Schritt? Werden Ereignisse verarbeitet oder verworfen? Wie hoch ist die Latenz? Wie hoch ist die Fehlerrate? Wie hoch sind die Kosten pro Million Ereignisse?

Diese Sichtbarkeit aufzubauen bedeutet nicht nur, einen Metrik-Endpunkt hinzuzufügen. Es geht darum, die richtigen Metriken zu entwerfen, die Dashboards zu erstellen, die richtigen Warnungen einzustellen (nicht zu laut, nicht zu leise) und das Team zu schulen, sie zu interpretieren. Es ist ein weiteres System, das gebaut, gewartet und debuggt werden muss.

Wann der Eigenbau tatsächlich sinnvoll ist

Ich möchte fair sein. Es gibt Situationen, in denen der Aufbau einer eigenen Integrationsschicht die richtige Entscheidung ist:

Sie haben extrem spezifische Anforderungen, die kein Anbieter gut abdeckt — ungewöhnliche Datenformate, spezielle Sicherheitsanforderungen, exotische Bereitstellungsumgebungen.

Sie haben das Team dafür — verteilte Systemingenieure, die Kafka im großen Maßstab betrieben haben, die genau-einmal-Semantik verstehen und Backpressure-Probleme um 3 Uhr morgens debuggt haben.

Es ist ein echter Differenzierer — die Datenverarbeitungsschicht ist zentral für Ihr Produkt, nicht nur Infrastruktur. Sie bauen keine Pipeline; Sie schaffen einen Wettbewerbsvorteil.

Sie sind in einem Maßstab, bei dem die Kosten für Anbieter die Baukosten übersteigen — seien Sie jedoch ehrlich, was "Baukosten" beinhaltet. Die meisten Teams unterschätzen um das 2-3-fache.

Für alle anderen überwiegt in der Regel die Berechnung zugunsten des Kaufs — wenn man die gesamten Betriebskosten berücksichtigt.

Die Anbieterauswahl, die wirklich zählt

Wenn Sie Anbieter vergleichen, ist die Feature-Matrix der falsche Ausgangspunkt. Die meisten Plattformen haben auf dem Papier ähnliche Fähigkeiten. Was zählt, ist das Betriebsmodell:

Wie gehen sie mit dem 2-Uhr-morgens-Problem um? Wenn etwas in der Produktion kaputt geht, wer wird benachrichtigt? Ist es Ihr Team, das ihre Infrastruktur debuggt, oder ihr Team, das Ihre Pipeline debuggt?

Wie sieht der Migrationspfad aus, wenn Sie wechseln? Datenpipelines sind hartnäckig. Verstehen Sie, was es kostet, Ihre Logik zu extrahieren und woanders hin zu verlagern.

Vereinheitlichen sie Batch und Streaming? Oder enden Sie doch mit zwei Pipelines, nur in der Infrastruktur eines anderen?

Wie hoch sind die tatsächlichen Gesamtkosten (TCO)? Berücksichtigen Sie Schulungen, Integrationszeit, die Kosten für das Warten auf benötigte Funktionen und die Opportunitätskosten der Ingenieurszeit, die für die Verwaltung der Plattform aufgewendet wird.

Wo layline.io passt

Ich werde nicht so tun, als wäre dies eine unvoreingenommene Einschätzung. Bei layline.io haben wir eine Plattform speziell für Teams entwickelt, die eine ehrliche Bilanz gezogen haben und entschieden haben, dass der Eigenbau nicht die richtige Wahl ist.

Die zentrale Annahme: Batch- und Streaming-Prozesse sollten nicht separate Pipelines sein. Sie sollten die gleichen Workflows, die gleichen Werkzeuge und dasselbe Team sein. Wenn Sie Echtzeit benötigen, bauen Sie nicht neu auf. Sie passen eine Konfiguration an.

Die operative Last liegt bei uns. Schema-Evolution, Fehlerbehandlung, Beobachtbarkeit — das ist die Aufgabe der Plattform, nicht Ihre. Ihr Team konzentriert sich auf die Geschäftslogik, nicht auf die Infrastruktur verteilter Systeme.

Ist es günstiger als der Eigenbau? Das hängt davon ab, wie ehrlich Sie die Baukosten berechnen. Wenn Sie zwei Wochen Entwicklung zählen und es als erledigt betrachten, wahrscheinlich nicht. Wenn Sie die Bereitschaftsdienste, die Wartungslast, die Vorfälle mit Schemaabweichungen und die Opportunitätskosten von Ingenieuren, die keine Produktfunktionen entwickeln, einbeziehen — dann in der Regel ja.

Die Frage, die Sie stellen sollten

Bevor Ihr Team sich verpflichtet, etwas zu entwickeln, fragen Sie:

"Wenn wir das selbst bauen, wer ist dann verantwortlich für den Anruf um 2 Uhr morgens, wenn es in sechs Monaten ausfällt? Und wissen sie, worauf sie sich einlassen?"

Wenn die Antwort klar ist und jeder das Engagement versteht, dann bauen Sie los. Wenn es Bedenken gibt oder die Antwort lautet "wir klären das später", dann machen Sie eine ehrliche Rechnung. Die Zahlen könnten Sie überraschen.

Andrew Tan ist ein Serienunternehmer und Gründer von layline.io, das Unternehmensdatenverarbeitungsinfrastrukturen entwickelt, die sowohl Batch- als auch Echtzeit-Workloads im großen Maßstab bewältigen.