Von Andrew Tan
Die Ausgaben, die niemand in das Migrationsbudget einplant — und warum der wahre Preis für den Wechsel zu Echtzeit nichts mit Softwarelizenzen zu tun hat
Das Budget, das den ersten Kontakt nicht überlebte
Ein VP of Engineering, den ich kenne, budgetierte 180.000 $ für die Umstellung seines Teams von Batch- auf Streaming-Verarbeitung. Das war vor zwölf Monaten. Als wir das letzte Mal sprachen, hatte das Projekt bereits 640.000 $ verschlungen und sie waren noch sechs Wochen von der Produktion entfernt.
Was ist passiert? Kein Betrug. Kein Scope Creep im traditionellen Sinne. Sie haben einfach die Kosten nicht berücksichtigt, die in den Angeboten der Anbieter nicht erscheinen: die sechswöchige Verzögerung, während sie einen Kafka-Ingenieur einstellten, der genau-once-Semantik verstand. Die drei Monate, in denen Batch- und Streaming-Verarbeitung parallel liefen, weil niemand der neuen Pipeline traute. Das Notfallberatungsengagement, als ihre Streaming-Aggregation andere Zahlen als der Batch-Bericht lieferte und der CFO es bemerkte.
Die Software selbst war günstig. Die versteckten Kosten fraßen sie auf.
Ich habe dieses Muster bei Unternehmen jeder Größe beobachtet. Teams budgetieren für Infrastruktur und Lizenzen. Sie budgetieren nicht für Unsicherheit, Nacharbeit und die Betriebskosten für die Wartung zweier Systeme, während eines das andere ersetzt. Wenn sie erkennen, was passiert, ist das Projekt entweder über dem Budget oder unter den Erwartungen — manchmal beides.
Hier sind die tatsächlichen Kosten, wenn Sie von Batch- auf Streaming-Verarbeitung umstellen.
Kostenpunkt #1: Das Talent, das Sie noch nicht haben
Batch-Engineering und Stream-Engineering sind miteinander verwandt, wie Schreinerei und Möbelbau verwandt sind. Gleiches Rohmaterial, völlig unterschiedliche Handwerkskunst.
Ihr bestehendes Team kennt Cron-Zeitpläne, Tabellenscans und die beruhigende Endgültigkeit eines Jobs, der startet, läuft und endet. Streaming fordert sie auf, in Ereigniszeit zu denken, unbegrenzten Zustand zu verwalten und Systeme zu debuggen, die nie aufhören zu laufen. Einige Ihrer Ingenieure werden sich schnell anpassen. Andere nicht — nicht weil sie schlechte Ingenieure sind, sondern weil verteilte Stream-Verarbeitung wirklich schwierig ist und nicht jeder sich darauf spezialisieren möchte.
Dies schafft versteckte Kosten in drei Formen:
Einstellung: Ein Senior Stream Processing Engineer in London oder New York kostet derzeit zwischen 160.000 $ und 220.000 $ Grundgehalt, plus die durchschnittliche viermonatige Einstellungszeit für diese Spezialität. Wenn Sie zwei davon benötigen, sind das fast eine halbe Million an Gehalt, bevor sie eine Zeile Produktionscode geschrieben haben.
Schulung: Ihre bestehenden Ingenieure müssen neue Konzepte lernen: Watermarking, Consumer Lag, Partition Skew, zustandsbehaftete Operatoren, at-least-once versus exactly-once. Dies sind keine Themen für einen Nachmittagsworkshop. Es sind Monate des praktischen Lernens, in denen die Produktivität niedriger als normal ist und Fehler teurer als üblich sind.
Fluktuation: Einige Ihrer besten Batch-Ingenieure werden während der Migration gehen — nicht weil sie Streaming nicht lernen können, sondern weil sie sich nicht angemeldet haben, um Spezialisten für verteilte Systeme zu werden. Sie mochten die Datenarbeit. Sie werden dorthin gehen, wo es noch so gemacht wird, wie sie es mögen.
Der Budgetposten für "Talent" in den meisten Migrationsplänen deckt Schulungen ab. Er deckt selten Einstellungsverzögerungen, Produktivitätsverluste oder unerwartete Fluktuation ab.
Kostenpunkt #2: Die Parallelbetriebsperiode
Niemand spricht genug darüber. Sie können nicht einfach Batch ausschalten und Streaming einschalten. Nicht, wenn Ihnen Ihr Job lieb ist.
Für einen Zeitraum — typischerweise drei bis sechs Monate, gelegentlich länger — werden Sie beide Systeme betreiben. Die Batch-Pipeline produziert weiterhin die Berichte, denen jeder vertraut. Die Streaming-Pipeline läuft daneben und produziert Ergebnisse, die theoretisch übereinstimmen sollten, aber oft nicht, zumindest nicht am Anfang.
Das bedeutet doppelte Infrastruktur. Doppelte Überwachung. Doppelte Alarme. Und ein Team von Ingenieuren, die ihre Tage damit verbringen, zwei Zahlenreihen abzugleichen, anstatt neue Funktionen zu entwickeln.
Ein E-Commerce-Unternehmen, mit dem ich zusammengearbeitet habe, betrieb parallele Systeme für acht Monate. Ihr Batch-Stack kostete ungefähr 4.200 $ pro Monat in Cloud-Computing. Ihr Streaming-Stack kostete 7.800 $ pro Monat. Für acht Monate zahlten sie beide. Das sind 96.000 $ allein für die Infrastruktur — ganz zu schweigen von der Ingenieurszeit, die damit verbracht wurde, zu untersuchen, warum die Streaming-Zählung der Bestellungen am Dienstag um 347 von der Batch-Zählung abwich.
Die Parallelperiode ist nicht optional. Sie ist eine Versicherung. Aber wie jede Versicherung ist sie teuer, und die meisten Teams unterschätzen die Prämie.
Kostenpunkt #3: Die Datenarchäologie
Ihre Batch-Pipelines enthalten Jahre angesammelter Geschäftslogik. Irgendwo in einem 400-zeiligen Python-Skript, das um 2 Uhr morgens läuft, befindet sich eine Join-Bedingung, die aufgrund einer Preisabweichung von 2019 existiert. Niemand hat dokumentiert, warum sie da ist. Die Person, die sie geschrieben hat, ist 2021 gegangen. Aber wenn Sie sie entfernen, verschieben sich die Umsatzzahlen um 0,3 % und die Finanzabteilung schickt wütende E-Mails.
Die Migration zu Streaming bedeutet, jedes dieser Artefakte zu verstehen. Sie können den Code nicht einfach portieren. Die Logik muss für die kontinuierliche Ereignisverarbeitung neu implementiert werden, was bedeutet, dass Sie zuerst verstehen müssen, was sie tut und warum. Dies ist Datenarchäologie — mühsam, langsam und unmöglich genau zu schätzen, weil Sie nicht wissen, was Sie finden werden, bis Sie anfangen zu graben.
Ein Finanzdienstleistungsunternehmen, das ich beraten habe, verbrachte fünf Wochen mit einer einzigen Pipeline. Die Streaming-Implementierung dauerte drei Tage. Das Herausfinden, warum die Batch-Version eine bestimmte Eckfallausgabe produzierte, dauerte die anderen zweiunddreißig Tage. Die Geschäftslogik war in einer gespeicherten Prozedur kodiert, die von drei verschiedenen Personen über vier Jahre hinweg geschrieben wurde, mit Kommentaren wie "Fix für Q2-Bug" und ohne weitere Erklärung.
Kostenpunkt #4: Die Steuer der betrieblichen Komplexität
Batch-Pipelines scheitern sichtbar. Ein Job stürzt ab. Sie erhalten einen Alarm. Sie beheben es. Sie führen es erneut aus. Jeder versteht, was passiert ist.
Streaming-Pipelines scheitern subtil. Consumer Lag baut sich über Stunden auf. Zustandspeicher wachsen, bis sie die Speichergrenzen erreichen. Watermarks driften und plötzlich lassen Ihre Fensteraggregationen verspätete Ereignisse fallen. Bis Sie es bemerken, haben Sie seit einem halben Tag leicht falsche Ergebnisse produziert.
Auch das betriebliche Tooling ist anders. Sie überwachen nicht nur, ob ein Job abgeschlossen ist. Sie überwachen Latenzverteilungen, Durchsatzneigungen, backpressure-Signale und Zustandspeichergrößen. Ihre bestehenden Runbooks gelten nicht. Ihre bestehenden Alarme erfassen die neuen Fehlermodi nicht.
Der Aufbau dieser betrieblichen Reife erfordert Zeit und Fehler. Das erste Mal, wenn Ihre Streaming-Pipeline 2 % der Ereignisse für sechs Stunden stillschweigend fallen lässt, werden Sie stark in bessere Beobachtbarkeit investieren. Das ist ein notwendiger Kostenpunkt. Aber er ist fast nie im ursprünglichen Budget enthalten.
Kostenpunkt #5: Die Opportunitätskosten, die niemand misst
Während Ihre besten Ingenieure Partition Rebalancing debuggen und Batch- versus Streaming-Ausgaben abgleichen, machen sie keine andere Arbeit. Funktionsanfragen häufen sich an. Technische Schulden akkumulieren sich. Wettbewerber liefern Dinge aus, die Ihr Team gebaut hätte, wenn es nicht bis zum Hals in der Migration stecken würde.
Dies ist der schwierigste Kostenpunkt zu quantifizieren und der einfachste zu ignorieren. Es gibt keine Rechnung dafür. Aber er ist real.
Ein SaaS-Unternehmen pausierte die gesamte Entwicklung neuer Datenprodukte für neun Monate während ihrer Streaming-Migration. Als sie fertig waren, hatten sie eine technisch beeindruckende Echtzeit-Pipeline gebaut — aber ihr Hauptkonkurrent hatte in derselben Zeit drei Analysefunktionen ausgeliefert und Marktanteile gewonnen. Die Migration war ein technischer Erfolg und eine strategische Verzögerung.
Warum wir weiterhin unterschätzen
Ein Teil des Problems ist die Botschaft der Anbieter. Streaming-Plattformen verkaufen das Ziel: Echtzeit-Einblicke, sofortige Reaktionen, Wettbewerbsvorteil. Sie werben nicht für die Reise: die Einstellung, die parallelen Systeme, die Archäologie, die betriebliche Lernkurve.
Ein anderer Teil ist der Optimismus-Bias. Jedes Ingenieurteam glaubt, dass es die Ausnahme sein wird. Ihr Code ist sauberer. Ihr Team ist schlauer. Ihre Anforderungen sind einfacher. Manchmal stimmt das. Meistens nicht.
Das Ergebnis ist eine anhaltende Lücke zwischen den budgetierten Kosten und den tatsächlichen Kosten. Ich habe Verhältnisse von 2:1, 3:1, sogar 5:1 gesehen. Nicht weil jemand unehrlich war — weil die echten Kosten unsichtbar sind, bis man sich bereits verpflichtet hat.
Wie man ehrlich budgetiert
Sie können diese Kosten nicht eliminieren, aber Sie können sie berücksichtigen. Hier ist, wie ich Teams rate, darüber nachzudenken:
Fügen Sie eine 40%ige Puffer zu den Infrastruktur-Schätzungen hinzu. Die Parallelperiode, die Testumgebungen, die Schattenbereitstellungen — sie alle fügen Rechen- und Speicherbedarf hinzu, den Sie nicht genau vorhersagen werden.
Budgetieren Sie für mindestens sechs Monate des Dualbetriebs. Wenn Sie früher fertig sind, feiern Sie. Wenn nicht, müssen Sie Ihrem CFO keine Überschreitungen erklären.
Stellen Sie einen Streaming-Spezialisten ein oder beauftragen Sie ihn, bevor Sie beginnen, nicht nachdem Sie feststecken. Die Kosten, sie frühzeitig einzubringen, sind hoch. Die Kosten, sie nach drei Monaten falscher Starts einzubringen, sind höher.
Akzeptieren Sie, dass einige Pipelines im Batch bleiben sollten. Nicht alles profitiert von Echtzeit. Tägliche Berichterstattung, historische Analysen, ML-Trainingspipelines — dies sind oft batch-geeignete Workloads, die die Migrationskosten nicht rechtfertigen. Seien Sie explizit darüber, was Sie nicht migrieren.
Eine andere Art, über den Übergang nachzudenken
Die Teams, die dies gut handhaben, teilen eine Eigenschaft: Sie betrachten es nicht als Migration. Sie betrachten es als Hinzufügen einer Fähigkeit.
Anstatt "wir wechseln von Batch zu Streaming" sagen sie "wir fügen Streaming hinzu, wo es Wert schafft, und behalten Batch bei, wo es noch funktioniert." Das klingt nach Semantik, aber es verändert die Wirtschaftlichkeit komplett. Sie sind nicht mehr verpflichtet, alles zu verschieben. Sie können jede Pipeline nach ihren eigenen Vorzügen bewerten: Latenzanforderungen, Komplexität, Geschäftswert, Migrationskosten.
Einige Pipelines werden verschoben. Einige nicht. Diejenigen, die verschoben werden, rechtfertigen ihre eigene Investition. Diejenigen, die bleiben, erzeugen keine unnötigen Kosten.
Hier ist eine einheitliche Plattform von Bedeutung. Wenn Sie separate Tools für Batch und Streaming betreiben, steht jede Pipeline unter Druck, zu migrieren, weil die Wartung zweier Plattformen teuer ist. Wenn Sie beide Modelle auf derselben Plattform ausführen können — gleiche Workflows, gleiches Team, gleicher betrieblicher Ansatz — verschwindet der Druck. Sie fügen real-time streaming dort hinzu, wo es sich lohnt, und lassen Batch dort, wo es bereits funktioniert.
Das ist der Ansatz, den wir in layline.io eingebaut haben. Nicht weil Batch schlecht ist — es ist oft genau richtig — sondern weil Teams zu zwingen, einen Ansatz zu wählen und den anderen aufzugeben, künstliche Kosten und Risiken schafft. Die Teams, die nachts gut schlafen, sind diejenigen, die nicht versucht haben, den Ozean zu kochen.
Das Fazit
Die versteckten Kosten des Wechsels von Batch zu Streaming sind nicht die Software. Es ist das alles andere: die Leute, die Sie einstellen müssen, die Systeme, die Sie parallel betreiben müssen, die alte Logik, die Sie ausgraben müssen, die betriebliche Reife, die Sie aufbauen müssen, und die Gelegenheit, die Sie verlieren, während Sie sich auf Infrastruktur statt auf das Produkt konzentrieren.
Budgetieren Sie dafür. Berücksichtigen Sie es. Seien Sie ehrlich darüber, welche Pipelines tatsächlich verschoben werden müssen und welche nicht.
Das Ziel ist nicht, überall in Echtzeit zu sein. Das Ziel ist, in Echtzeit zu sein, wo es darauf ankommt, ohne sich dabei zu ruinieren.
Was als nächstes
Wenn Sie eine Batch-to-Streaming-Migration planen, beginnen Sie mit einem ehrlichen Audit. Listen Sie Ihre zehn wichtigsten Pipelines auf. Fragen Sie für jede: Was sind die tatsächlichen Kosten der Latenz? Was ist der geschätzte Migrationsaufwand? Was ist der betriebliche Komplexitätszuwachs?
Wenn die Zahlen den Umzug für eine bestimmte Pipeline nicht rechtfertigen, lassen Sie sie in Ruhe. Konzentrieren Sie Ihre Energie auf die zwei oder drei, bei denen Echtzeit messbaren Geschäftswert schafft.
Für Teams, die Plattformen evaluieren, ist die Community Edition von layline.io kostenlos zu erkunden. Sie können eine Streaming-Pipeline neben Ihrem bestehenden Batch-Workflow prototypisieren und sehen, wie die betriebliche Realität aussieht, bevor Sie das Budget festlegen.
Andrew Tan ist ein Serienunternehmer und Gründer von layline.io, der Unternehmensdatenverarbeitungsinfrastrukturen entwickelt, die sowohl Batch- als auch Echtzeit-Workloads in großem Maßstab verarbeiten.
