Von Andrew Tan
Die Demo, die nicht ankam
Wir waren achtzehn Monate in der Entwicklung von layline.io, als wir unseren ersten ernsthaften Unternehmensinteressenten hatten. Ein Fortune 500 Logistikunternehmen. Ihr Datenteam hatte unsere Architektur überprüft, mochte den Batch-plus-Streaming-Ansatz und plante einen ganztägigen Workshop, um tief einzutauchen.
Wir bereiteten uns wochenlang vor. Wir bauten eine Demo, die alles zeigte: komplexe Ereignisverarbeitung, automatische backpressure-Behandlung, Schema-Evolution. Es war, nach jeder Lehrbuchdefinition, eine Best-Practice-Architektur. Verteilt. Fehlertolerant. Entwickelt, um horizontal zu skalieren. Die Art von System, die man bei einem Vortrag auf einer Konferenz an ein Whiteboard zeichnen würde.
Der Workshop verlief gut. Die Ingenieure stellten gute Fragen. Dann, in den letzten dreißig Minuten, lehnte sich der leitende Architekt zurück und sagte etwas, das ich nie vergessen werde: "Das ist beeindruckend. Aber wir betreiben alles auf einem einzigen Server mit Cron-Jobs, und es funktioniert. Was würden wir tatsächlich von all dieser Komplexität gewinnen?"
Ich hatte hundert Antworten parat. Skalierbarkeit. Resilienz. Zukunftssicherheit. Aber ich konnte in seinem Gesicht sehen, dass er nicht nach einem Technologievergleich fragte. Er bat mich zu rechtfertigen, warum seine aktuelle Realität – langweilig, einfach, funktionierend – unzureichend war.
Ich konnte es nicht. Nicht ehrlich.
Die Architektur, die ich gelöscht habe
Drei Monate später war ich in einem anderen Raum mit einem anderen Kunden. Dieser war ein mittelgroßes Fintech-Unternehmen. Sie betrieben seit zwei Jahren eine Kafka-basierte Streaming-Pipeline. Sie stürzte ständig ab. Sie hatten Berater engagiert, Hardware aufgerüstet, ihre Verbrauchslogik zweimal neu geschrieben. Das System war "korrekt" nach jedem Lehrbuch über verteilte Systeme. Es war auch ein Albtraum zu betreiben.
In der Besprechung zeigte mir ihr leitender Ingenieur das Architekturdiagramm. Es war wunderschön. Zwölf Microservices, drei verschiedene Persistenzschichten, ein benutzerdefinierter operativer Datenspeicher für das Zustandsmanagement. Sie hatten jedes Muster aus dem Confluent-Blog und dem Buch von Martin Kleppmann befolgt.
"Was wäre, wenn," fragte ich, "Sie die Ereignisse einfach in eine Datei schreiben und sie in Batches verarbeiten?"
Er starrte mich an. "Das ist... kein Streaming."
"Nein," stimmte ich zu. "Aber Sie verarbeiten die Ereignisse sowieso stündlich, weil Ihr nachgelagertes System keine Echtzeit-Updates verarbeiten kann. Sie tragen die Betriebskosten einer Streaming-Architektur, um Batch-Semantik zu erreichen."
Sie kauften layline.io an diesem Tag nicht. Aber sechs Wochen später bekam ich eine E-Mail. Sie hatten die gesamte Architektur gelöscht. Ersetzt durch einen einzigen Prozess, der Dateien liest und in eine Datenbank schreibt. Im Grunde ein Cron-Job. Ihre p99 Latenz ging von 200 ms auf fünf Minuten – was keine Rolle spielte, da ihr Geschäftsprozess täglich war. Ihre Betriebszwischenfälle gingen von drei pro Woche auf null. Ihr Ingenieurteam ging vom Feuerlöschen zum Ausliefern von Funktionen über.
Die "falsche" Architektur war besser, weil sie ihren tatsächlichen Einschränkungen entsprach, nicht ihren aspirationalen.
Die Best-Practice-Falle
Hier ist, was ich aus 25 Jahren Erfahrung im Aufbau und Verkauf von Dateninfrastruktur gelernt habe: Best Practices sind per Definition kontextabhängig, werden aber als universelle Wahrheiten vermarktet.
Die Streaming-First-Architektur, die Netflix benötigt, ist nicht die Architektur, die ein 50-Personen-SaaS-Unternehmen benötigt. Der Microservices-Ansatz, der es Amazon ermöglicht, 10.000 Mal pro Tag zu deployen, ist nicht das, was Ihr Team von vier Ingenieuren benötigt. Das AI-Agenten-Framework, das 50 Millionen Dollar an VC-Finanzierung eingebracht hat, ist nicht das, was Ihr cron-basierter ETL benötigt.
Aber das würde man nicht wissen, wenn man Brancheninhalte liest. Jeder Anbieter-Blogpost, jeder Konferenzvortrag, jeder Architektur-Blueprint zeigt den gleichen Verlauf: einfach anfangen, dann zur Komplexität "graduieren", wenn man wächst. Die Implikation ist klar: Einfach ist für Anfänger. Komplexität ist für ernsthafte Praktiker.
Das ist rückwärts. Komplexität ist eine Haftung, die widerwillig hinzugefügt werden sollte, nicht ein Ehrenzeichen, das eifrig verfolgt werden sollte.
Wie "funktioniert für uns" tatsächlich aussieht
Ich habe angefangen, Kunden in frühen Gesprächen eine andere Frage zu stellen: "Was ist das Einfachste, das für Ihre tatsächliche Arbeitslast funktionieren könnte?" Nicht Ihre prognostizierte Arbeitslast in drei Jahren. Nicht Ihr aspirationaler Echtzeit-Anwendungsfall, den der CEO einmal erwähnt hat. Ihre tatsächliche Arbeitslast, heute.
Die Antworten sind durchweg überraschend:
- Ein Gesundheitsunternehmen, das täglich eine Million Patientenakten verarbeitet, tut dies mit einem einsträngigen Python-Skript, das jede Nacht vier Stunden läuft. Es läuft seit sechs Jahren ohne Änderung. Warum? Weil die Akten um 2 Uhr morgens per FTP ankommen und die Ärzte die Dashboards erst um 8 Uhr morgens ansehen.
- Ein Einzelhandelsunternehmen, das Verkaufsstellendaten von 2.000 Geschäften verarbeitet, verwendet einen dreiknotigen Kafka-Cluster. Nicht weil sie den Durchsatz benötigen – sie könnten die Ereignisse eines Tages in einer einzigen Datei unterbringen – sondern weil ihr bestehendes Team Kafka kannte und keine Zeit hatte, während ihrer geschäftigsten Saison etwas Neues zu lernen.
- Ein Logistikunternehmen, das Container-Schiffe in Echtzeit verfolgt, verwendet... eine Tabelle. Das Operationsteam aktualisiert sie manuell. Sie haben zweimal versucht, eine automatisierte Pipeline zu bauen. Beide Male scheiterte das automatisierte System auf eine Weise, die schwerer zu debuggen war als die Tabelle. Die Tabelle ist in einem Dutzend Weisen "falsch", aber sie ist einsehbar falsch. Man kann die Fehler sehen.
Keine dieser Praktiken sind "Best Practices". Alle sind korrekt für ihren Kontext.
Der AI-Agent-Hype-Zyklus
Wenn Sie die Best-Practice-Falle in ihrer aggressivsten Form sehen wollen, beobachten Sie, wie die Dateningenieurbranche derzeit auf AI-Agenten reagiert.
Jeder Wettbewerber-Blog, den ich in letzter Zeit lese – Airbyte, Confluent, Kestra – positioniert ihr Produkt als "AI-Agent bereit". Es gibt tiefgehende Einblicke in das Model Context Protocol, Ontologien für Agenten, Kontextfenster-Management. Die implizite Botschaft: Wenn Sie nicht gerade für AI-Agenten architektonisieren, fallen Sie zurück.
Ich fragte letzte Woche einen Kunden, ob sie AI-Agenten für ihre Datenpipelines in Betracht ziehen. "Wir haben sechs Monate versucht, ein LLM zu bekommen, das SQL generiert", sagte er. "Es war zu 70% genau bei einfachen Abfragen und zu 30% genau bei komplexen. Die 30% waren subtil genug, dass wir es nicht bemerkten, bis der CEO eine falsche Zahl in einem Vorstandsdeck sah. Wir sind zurück zu Ingenieuren, die SQL schreiben."
Das ist kein Argument gegen AI. Es ist ein Argument gegen das Standardisieren auf AI, weil es die aktuelle Best Practice ist. Die Teams, die heute von AI-Agenten profitieren, haben spezifische Merkmale: hohe Abfragevolumina, relativ einfache Schemata, Toleranz für gelegentliche Fehler und Ingenieurressourcen, um Ausgaben zu validieren. Wenn das Ihre Situation nicht beschreibt, sind AI-Agenten noch nicht Ihre Lösung – egal, wie viele Anbieter-Blogposts etwas anderes suggerieren.
Wie man Technologie tatsächlich bewertet
Wenn "Best Practice" kein zuverlässiger Leitfaden ist, was dann?
Hier ist das Framework, das ich jetzt benutze, sowohl für meine eigenen architektonischen Entscheidungen als auch bei der Beratung von Kunden:
Beginnen Sie mit Ihren tatsächlichen Einschränkungen. Wie viele Daten? Welche Ankunftsmuster? Welche Latenzanforderungen? Welche Teamgröße und Expertise? Welches Budget für den Betrieb? Die Antworten auf diese Fragen eliminieren sofort 90% der "branchenüblichen" Architekturen.
Optimieren Sie für das Debuggen, nicht für die Eleganz. Die Architektur, die saubere Diagramme produziert, ist oft diejenige, die um 2 Uhr morgens am schwersten zu debuggen ist. Bevorzugen Sie Systeme, bei denen Sie einen einzelnen Datensatz vom Ursprung bis zum Ziel verfolgen können, ohne drei verschiedene Abstraktionsebenen zu durchqueren.
Messen Sie die Betriebskosten in Teamaufmerksamkeit, nicht nur in Infrastrukturkosten. Ein verteiltes System, das sich selbst betreibt, aber einen leitenden Ingenieur erfordert, der auf Abruf ist, ist teurer als ein einzelner Server, der gelegentlich neu gestartet werden muss, aber von einem Junior-Mitarbeiter verwaltet werden kann.
Planen Sie die Migration, die Sie tatsächlich durchführen werden, nicht die Migration, die Sie durchführen sollten. Jedes Team hat Altsysteme, die sie nie außer Betrieb nehmen werden. Entwerfen Sie für ein reibungsloses Nebeneinander mit alter Technologie, anstatt sie revolutionär zu ersetzen.
Im Zweifelsfall, starten Sie langweilig. Sie können immer Komplexität hinzufügen. Sie zu entfernen ist viel schwieriger. Die Teams, die ich erfolgreich sehe, sind diejenigen, die Technologie widerwillig hinzufügen, mit klaren Beweisen, dass einfachere Ansätze erschöpft sind.
Das Gegenargument, das ich nicht mache
Ich möchte klarstellen, was ich nicht sage. Ich argumentiere nicht für technischen Konservatismus oder gegen das Ausprobieren neuer Dinge. Einige Probleme erfordern tatsächlich komplexe, verteilte, Echtzeit-Architekturen. Wenn Sie Zahlungen im großen Maßstab verarbeiten, benötigen Sie genau-einmal-Semantik. Wenn Sie ML-Funktionen mit einer Latenz von unter 100 ms bereitstellen, benötigen Sie Streaming. Wenn Sie Netflix sind, benötigen Sie, was Netflix benötigt.
Aber die meisten Unternehmen sind nicht Netflix. Die meisten Datenpipelines müssen nicht 10.000 Ereignisse pro Sekunde verarbeiten. Die meisten Teams haben keine Plattform-Engineering-Gruppe, um die Betriebslast moderner Dateninfrastruktur zu verwalten.
Die unbequeme Wahrheit ist, dass die Branche "was erfolgreiche Tech-Unternehmen tun" mit "was Sie tun sollten" gleichgesetzt hat. Erfolgreiche Tech-Unternehmen haben endlose Ingenieurressourcen, hohe Toleranz für betriebliche Schmerzen und Geschäftsmodelle, die Echtzeit alles erfordern. Ihr Unternehmen wahrscheinlich nicht. Ihre Architektur sollte nicht so tun, als ob.
Wo layline.io passt (und wo nicht)
Ich schließe mit etwas, das Sie überraschen könnte: layline.io ist nicht die richtige Wahl für jedes Datenintegrationsproblem.
Wenn Sie ein paar Batch-Jobs haben, die zuverlässig nach einem Zeitplan laufen, und Ihr Team mit Ihrem aktuellen Setup zufrieden ist, brauchen Sie uns wahrscheinlich nicht. Ernsthaft. Der Betriebsaufwand, eine neue Plattform zu erlernen, lohnt sich nicht, wenn Ihre aktuelle Realität stabil und verstanden ist.
Wo wir Mehrwert bieten, ist, wenn Sie einfache Ansätze übertroffen haben, aber die Komplexitätssteuer vermeiden möchten, mehrere spezialisierte Tools zusammenzufügen. Wenn Sie sowohl Batch als auch Streaming im selben System benötigen. Wenn Ihr Team es leid ist, separate Orchestrierungs-, Transformations- und Überwachungsebenen zu pflegen. Wenn Sie sich um ein Modell konsolidieren möchten, anstatt eine Koordinationsnaht zwischen drei verschiedenen Tools zu verwalten.
Selbst dann würde ich lieber mit einem Proof of Concept beginnen, das die Daten eines einzigen Tages verarbeitet, als mit einem ehrgeizigen Migrationsplan. Beweisen Sie, dass der einfachere Ansatz für Ihre tatsächliche Arbeitslast funktioniert, bevor Sie sich für den komplexen entscheiden.
Die beste Praxis ist die, die für Sie funktioniert. Alles andere ist nur Marketing.
Wenn Sie Dateninfrastruktur evaluieren und eine ehrliche Einschätzung darüber wünschen, welche Komplexität tatsächlich für Ihre spezifische Situation hinzuzufügen ist, kontaktieren Sie uns. Wir sagen Ihnen, ob Sie uns brauchen oder ob Sie Ihre Cron-Jobs behalten sollten.
Andrew Tan ist ein Serienunternehmer und Gründer von layline.io, das Unternehmensdatenverarbeitungsinfrastruktur entwickelt, die sowohl Batch- als auch Echtzeit-Arbeitslasten im großen Maßstab bewältigt.
