Echtzeitdaten mit Apache Flink: Wie Ververica und Steadforce industrielle IoT-Projekte zum Erfolg führen

Eure Maschinen, Sensoren und IIoT-Geräte erzeugen kontinuierlich riesige Datenströme. Das Potenzial ist enorm – aber in bestimmten kritischen Use Cases kommt es auf Sekundenbruchteile an. Denn wer nicht in Echtzeit reagiert, verpasst den entscheidenden Moment.

Also stellen wir die zentralen Fragen: Welche Use Cases erfordern wirklich Entscheidungen in Echtzeit?
Welche Technologien bewältigen Skalierung und Geschwindigkeit? Warum sprechen plötzlich alle über Apache Flink?

Und worauf solltet ihr achten, wenn ihr diese Technologie in euren Projekten einsetzt?
In dieser Folge gehen wir direkt in die Praxis – mit echten Beispielen und Einblicken, die über Buzzwords hinausgehen.

Mit dabei sind Ben Gamble, Field CTO bei Ververica, den Entwicklern von Apache Flink, und Stephan Schiffner, CTO bei Steadforce und Experte für die Implementierung von Kafka und Flink in industriellen Umgebungen. Wir sprechen darüber, warum viele Projekte stecken bleiben – und wie ihr genau das vermeidet. Ihr erfahrt, was es wirklich braucht, um Daten in Echtzeit zu verarbeiten – und wie ihr loslegen könnt, ohne eure Architektur zu überladen. 

Lass uns starten. Alle Infos wie immer auf iotusecase.com. Let’s go.

Hi Stephan, hi Ben. schön, dass ihr heute dabei seid. Wie geht’s euch beiden? Ben, ich starte mit dir.

Ben

Heute ist ein wunderbarer Tag. In Großbritannien gibt es gerade eine überraschende Hitzewelle – plötzlich ist das Wetter richtig gut. Die letzten Wochen waren sehr voll mit Konferenzen, die Saison ist voll im Gange.

Das kann ich mir vorstellen. Wo genau bist du denn aktuell?

Ben

Ich bin aktuell in der Nähe von Cambridge im UK. Wie der Großteil Amerikas arbeiten wir weltweit remote – mein Team sitzt gerade verteilt in Athen, Oregon und London.

Verstehe. Schön, dass du da bist. Und Stephan, wie geht es dir heute?

Stephan

Danke Madeleine, schön wieder dabei zu sein. Ich bin in München, draußen ist es etwas bewölkt, also nicht ganz so schön wie in London. Und es ist viel los – viele Meetings, viel zu tun.

Super, ich weiß das sehr zu schätzen. Ich freue mich auf diese Session. Wir steigen direkt ein. Ben, Ververica ist als ursprünglicher Entwickler von Apache Flink bekannt. Kannst du uns die Gründungsgeschichte erzählen und wie sich die Mission des Unternehmens im Laufe der Zeit entwickelt hat? Ich würde gern mehr darüber erfahren.

Ben

Ververica entstand ursprünglich in Berlin an der Technischen Universität. Damals gab es ein Projekt namens Projekt Stratosphere, das auf der einfachen Idee basierte, dass Datenmengen immer größer werden. Wer sich an den Big-Data-Boom Ende der 90er und Anfang der 2000er erinnert, denkt vielleicht an Technologien wie Hadoop, die diese Ära geprägt haben. Das Projekt Stratosphere bildete schließlich die Grundlage für die Idee, mit Daten zu arbeiten, die größer sind als der Speicher oder die Rechenleistung einer einzelnen Maschine. Die zentrale Frage war: Wie kann man all die Daten nutzen, die inzwischen gesammelt wurden? Daraus entwickelte sich ein neues Konzept – und später ein Beitrag an die Apache Foundation: Flink. Der Name „Flink“ ist dabei ein Wortspiel – er steht für Schnelligkeit und stammt aus dem Deutschen. Ich habe kürzlich gelernt, dass „flink“ nicht nur „schnell“, sondern auch so etwas wie „gewitzt schnell“ bedeutet. Der Firmenname „Ververica“ kommt übrigens vom Eichhörnchen – das ist auch das Logo von Apache Flink. Das Eichhörnchen steht für den Boten auf dem Weltenbaum der nordischen Mythologie – es überbrachte Nachrichten schnell zwischen den verschiedenen Welten. Flink ist über die Jahre zur führenden Technologie für Stream Processing geworden. Der zentrale Gedanke: Batches und Streams sind keine getrennten Welten. Sobald du Daten verarbeitest, die größer sind als dein Cache oder dein Speicher, arbeitest du im Grunde mit einem Stream. Deshalb streamen heute fast alle modernen Datenbanken – sogar DuckDB schreibt das ganz offen auf ihrer Website. Flink ging also schon früh davon aus, dass Streaming nicht nur ein Spezialfall ist, sondern der eigentlich wichtigere Ansatz – selbst wenn man batchartig arbeitet. Und von da an hat sich die Technologie verbreitet. Letztes Jahr haben wir das zehnjährige Bestehen auf der Flink Forward in Berlin gefeiert. Es war sozusagen ein „Overnight Success“, der zehn Jahre gedauert hat.

Heute nutzen Unternehmen wie Uber, Amazon oder Walmart Apache Flink schon seit Jahren. Aber mittlerweile ist Flink durch Anbieter wie uns auch im Mainstream angekommen.
Denn der Bedarf an Echtzeitverarbeitung betrifft längst nicht mehr nur die großen Konzerne, sondern mehr oder weniger jeden einzelnen. Denn mal ehrlich – wann hat ein Kunde das letzte Mal gesagt: „Ich hätte das gern langsamer?“ Ich kann mich nicht erinnern.

Ja, genau – besonders, wenn wir über IoT-Daten und Echtzeit-Use-Cases sprechen. Das ist ein kritischer Faktor. Ich würde gerne mehr über eure Best Practices zur Umsetzung solcher Projekte erfahren – aber dazu kommen wir gleich noch. Stephan, könntest du uns eine kurze Vorstellung geben? Ich weiß, ihr sitzt in München – aber für alle, die Steadforce noch nicht kennen: Kannst du einen Überblick geben, was ihr macht und wie ihr Streaming-Technologien wie Flink und Kafka in Industrieprojekten einsetzt? Übrigens, über Kafka sprechen wir gleich noch.

Stephan

Ja, klar. Steadforce ist ein Tech-Unternehmen, das seit 40 Jahren digitale Lösungen für seine Kunden entwickelt – dieses Jahr feiern wir unser 40-jähriges Jubiläum. Unser Fokus liegt auf drei technischen Kernbereichen: Erstens Cloud-Lösungen – dazu zählen auch Migrationen und die Modernisierung bestehender Anwendungen. Zweitens Plattform Engineering. Und drittens alles rund um Daten- und KI-Lösungen – da kommen dann auch Ververica, Flink und Co. ins Spiel. Wir arbeiten mit führenden Unternehmen aus der Automobil-, Fertigungs-, Chemie- und Medizintechnik-Branche – das sind unsere wichtigsten Zielbranchen.

Super, danke dir. Ich habe mich gefragt, worin eigentlich der Unterschied zwischen Flink und Apache Kafka liegt – ich sehe beides als Streaming-Technologien. Könntest du kurz erklären, wie sich Apache Flink einordnen lässt? Vielleicht auch mit einem praktischen Beispiel?

Ben

Ja, das passt gut – ich habe dazu kürzlich einen Vortrag gehalten, daher ist das Thema gerade präsent. Wenn wir zurückblicken: Flink entstand etwa zur selben Zeit wie Apache Spark – das ist die Technologie hinter Databricks, die heute viele kennen. Beide Tools gehen auf die Herausforderung zurück, große Datenmengen effizient zu verarbeiten. Apache Kafka, das etwas früher bei LinkedIn entwickelt wurde, entstand hingegen aus dem Bedarf heraus, Streaming-Daten überhaupt effizient speichern zu können. Apache Kafka ist eine Speicher-Engine für Daten – sie kümmert sich nicht darum, was du speicherst, sondern ist darauf optimiert, riesige Datenmengen zuverlässig und schnell zu erfassen und so zu speichern, dass du sie von fast überall abrufen kannst. Selbst der Name „Kafka“ wurde gewählt, weil das System auf das Schreiben von Daten ausgelegt ist.
Was Kafka dir gibt, ist ein ausfallsicheres, verteiltes Log – eine sogenannte Append-only-Datenstruktur, die kontinuierlich erweitert werden kann, ohne dass du dir Gedanken um die Durchsatzrate machen musst. Wenn es richtig eingerichtet ist, übersteht es nahezu jeden Ausfall und erlaubt dir, die Daten per Publish-Subscribe-Modell an beliebig viele Empfänger zu verteilen. Das macht Kafka zu einem sehr mächtigen Baustein in der verteilten Datenverarbeitung – besonders in Kombination mit Microservices oder großen Datenarchitekturen. Flink spielt sehr gut mit Kafka zusammen, aber es besteht keine direkte Abhängigkeit – sie ergänzen sich einfach gut. Besonders im IoT-Bereich landen viele Daten in Kafka, weil sie unregelmäßig auftreten und du sie zu einem späteren Zeitpunkt an einem zentralen Ort verlässlich auslesen möchtest. Kafka passt sehr gut zur IoT-Seite dessen, was Flink macht – außerhalb davon ist es eher eine praktische Kombination als eine echte Abhängigkeit.

Verstehe. Hast du ein Beispiel, das du teilen kannst? Ich weiß nicht, ob wir Kundennamen nennen dürfen, aber ich vermute, viele OT-Experten hören gerade zu.

Ben

Klar, ich kann ein Beispiel nennen und auch den Kunden erwähnen. In diesem Fall sind es zwei unterschiedliche, aber wir arbeiten intensiv mit Unternehmen wie Toyota und BMW in deren Produktionsstätten. Innerhalb einer Fabrik – das ist übrigens kein spezieller Einzelfall – sieht ein klassisches Beispiel so aus: Ich habe verschiedene Bauteile, die hergestellt werden. Die meisten modernen Werke funktionieren im Grunde wie eigene Lieferketten. Eine Linie stellt Türen her, eine andere Radaufhängungen, eine weitere Bremsen. Diese Sub-Assemblies müssen genau getaktet zusammengeführt werden. Du kannst keine Autos bauen, wenn dir die Räder fehlen. Und keine Räder ohne Reifen. Keine Naben ohne Schrauben. Die Koordination dieser unterschiedlichen Produktionsgeschwindigkeiten ist heute geschäftskritisch, um sogenanntes „Work in Progress“ zu minimieren.
Das ist eines der großen Prinzipien moderner Produktionssteuerung. Du willst keine überflüssigen Teile auf Lager haben – sie blockieren Platz. Manche Komponenten sind sogar verderblich, wie etwa roher Gummi. Schrauben sollen nicht rosten, Öl soll nicht auslaufen. Du willst genau das zur Verfügung haben, was du gerade brauchst – nicht mehr und nicht weniger. Ein Zuviel verstopft das Lager, ein Zuwenig verlangsamt die Produktion. Die Überwachung all dieser Faktoren in Echtzeit – also zu wissen, wann man nachbestellen muss, wann ein vorgelagerter Prozess verlangsamt oder ein nachgelagerter beschleunigt werden sollte – erfordert Echtzeitdaten. Ein großer Teil unserer Arbeit mit Fertigungskunden besteht darin, nicht nur Daten in Echtzeit zu sehen, sondern daraus auch unmittelbar Maßnahmen abzuleiten.

Okay, spannend. Und hast du noch ein anderes Beispiel, bei dem es wirklich notwendig ist, in Echtzeit zu handeln? Viele OT-Experten kennen ja Edge Computing und andere Technologien, mit denen man hochfrequente Daten direkt vor Ort verarbeiten kann. Aber ihr macht das in dem Fall in der Cloud. Warum? Kannst du das näher erklären?

Ben

Ja, nehmen wir ein alltägliches Beispiel: Ich war gestern in London und benutze heutzutage kein Bargeld mehr. An immer mehr Orten ist Bargeld gar nicht mehr erlaubt. Es gibt überall bargeldlose Läden, und im öffentlichen Nahverkehr läuft alles über Kreditkartenzahlung per „Tap“. Wenn ich zum Beispiel meine Kreditkarte an ein Drehkreuz am Bahnsteig halte, muss diese Zahlung sofort verarbeitet werden, damit sich das Tor direkt öffnet und es keinen Rückstau gibt. Aber sobald ich die Karte getappt habe, müssen diese Informationen in die Cloud gesendet werden. Das System muss zunächst überprüfen, ob ich mir den Kauf leisten kann, ob ich wirklich die Person bin, die ich vorgebe zu sein, und ob das Geschäft tatsächlich der Händler ist, der es vorgibt zu sein. Angenommen, ich tätige eine Zahlung, und sie wird ungewöhnlicherweise über das Mastercard-, Visa- oder Amex-Netzwerk weitergeleitet. Dann müssen diese Netzwerke verifizieren, wer den Tap wirklich gemacht hat. Wenn ich mich normalerweise in London aufhalte, aber plötzlich eine Zahlung in Kapstadt auftaucht – besonders, wenn die vorherige Zahlung in Lagos war – dann könnte das ein Problem sein. Solche Dinge erfordern die Fähigkeit, in Echtzeit zu reagieren – und das passiert heutzutage fast immer in der Cloud.

Verstehe. Gibt es dafür Beispiele aus der Industrie? Ich denke da an Situationen, in denen man ungewöhnliche Muster erkennt – zum Beispiel Stromspitzen –, bei denen man wirklich in Echtzeit handeln muss. Gibt es solche Use Cases auch in der Industrie?

Stephan

Ein Beispiel wäre die Anomalieerkennung. Nehmen wir Sensordaten, etwa Temperaturwerte. Man kann überwachen, ob die Temperatur zu einem bestimmten Zeitpunkt einen Grenzwert erreicht oder überschreitet. Aber es geht nicht nur darum, solche Zustände zu erkennen – es geht darum, daraus echten Mehrwert zu ziehen. Dafür braucht es eine zustandsbasierte Analyse der Datenströme. Es geht also nicht nur um einen einzelnen Peak, sondern vielleicht darum, ob sich der Durchschnitt der Temperatur über die letzten fünf Minuten verändert hat. Bezogen auf dein Beispiel mit der Kreditkarte, Ben: Wenn jemand deine Karte in München benutzt, ist das kein Problem – du könntest ja im Urlaub dort sein. Aber wenn innerhalb von fünf Minuten eine Transaktion auch noch in London erfolgt, dann haben wir ein Problem. Das heißt, der Kontext und der Zustand des gesamten Prozesses sind entscheidend.

Ben

Um das weiter auszuführen: Zustandsbehaftetes Computing ist ein zentrales Merkmal, das Apache Flink ins IoT bringt. Es war schon immer relativ einfach, Sensoren auszulesen – das ist heute ganz normal. Ich habe früher in der Leiterplattenfertigung gearbeitet, dort gibt es eine sogenannte Wellenlötanlage. Dabei entsteht eine Welle aus geschmolzenem Metall, über die die Leiterplatten gezogen und verlötet werden.
Diese Lötwelle muss eine bestimmte Höhe und Temperatur haben. Wenn sie zu niedrig ist, werden die Leiterplatten nicht richtig gelötet, was zu hohen Kosten führt. Wenn sie zu hoch ist, können Bauteile beschädigt werden. Klar, man kann einen einfachen Trigger setzen, wenn die Werte außerhalb des Sollbereichs liegen. Aber wenn über mehrere Minuten hinweg die Temperatur langsam abfällt, könnte das bedeuten, dass irgendwo Lötzinn verloren geht – ein systemischer Fehler. Dann reicht ein einmaliges Nachfüllen nicht.
In so einem Fall muss man nicht nur ein Ereignis erkennen, sondern ein Muster – und den Kontext dieses Musters über die Zeit hinweg verstehen und behalten. Wenn wir zum Beispiel jeden Tag um 15 Uhr nachfüllen müssen, könnte das auf ein Leck hindeuten, durch das wir jeden Tag eine bestimmte Menge verlieren. Dann sollten wir entweder das Leck reparieren – oder eben systematisch jeden Tag um 15 Uhr nachfüllen.

Ja, verstehe. Dann lass uns vielleicht ein bisschen über das zugrunde liegende Problem sprechen. Ich verstehe jetzt, warum Echtzeitdatenverarbeitung notwendig ist und welche Use Cases es dafür gibt – aber warum tun sich deiner Meinung nach so viele Unternehmen schwer damit, ihre Daten zu bewegen oder von traditionellen Datenarchitekturen wegzukommen? Du hast Toyota, BMW und andere große Unternehmen erwähnt – aber es gibt auch kleinere Firmen, die das versuchen. Warum denkst du, haben so viele Unternehmen damit noch immer Schwierigkeiten?

Stephan

Ein Punkt ist sicher, dass bestehende Infrastrukturen historisch gewachsen sind. Es gibt viele Altsysteme – oder zumindest sehr statische Systeme – und es ist nicht einfach, daraus Events zu extrahieren. Flink bietet hier mit dem Flink-CDC-Subprojekt eine gute Lösung, um genau diese Altsysteme anzubinden und die Daten dorthin zu bewegen, wo man sie braucht. Es geht also wirklich darum, Daten zu extrahieren, vorzubereiten und weiterzuleiten.
Ein weiterer Punkt ist, dass die Daten oft nicht die richtige Qualität für einen spezifischen Use Case haben. Selbst wenn die Daten grundsätzlich gut sind, heißt das nicht, dass sie für das angestrebte Ziel geeignet sind. Das muss man klären, bevor man mit Flink in die Verarbeitung geht.

Ben

Um das weiter auszuführen: Das Problem mit Legacy-Software ist, dass sie oft noch zu viel Geld einbringt, um sie einfach abzuschalten. Die meisten dieser Unternehmen gibt es schon lange. Die Einführung von IoT-Setups oder Fertigungslösungen dauert eben seine Zeit. Und die eingesetzten Sensoren liefern möglicherweise keine Echtzeitdaten. Die Datenflüsse und Speicherorte sind über Jahre gewachsen und funktionieren heute meistens gut. Sie könnten besser funktionieren – und da kommen wir ins Spiel – aber man kann sie eben nicht einfach mal eben abschalten, vor allem nicht in einer Produktion, die rund um die Uhr läuft.
Auch bei Verkehrssensoren ist das so – solche Systeme dürfen einfach nicht ausfallen. Wenn man das System, das die Ampeln einer Stadt steuert, einfach herunterfährt, hat man ein echtes Problem. Ich habe das schon erlebt – zum Beispiel bei Ticketkauf-Systemen für nationale Bahngesellschaften.
Deshalb ist „Change Data Capture“, also die Fähigkeit, Datenströme aus bestehenden Systemen herauszuziehen, der richtige Weg nach vorn. Stephan und ich haben in letzter Zeit einen Begriff mehrfach verwendet: „Evolution, nicht Revolution.“ Wenn jemand zu uns kommt und sagt: „Wir wollen jetzt in Echtzeit arbeiten“, dann sagen wir erstmal: „Glückwunsch – ihr seid an dem Punkt angekommen, an dem Echtzeit wichtig ist.“
Echtzeitverarbeitung ist heute oft notwendig, um wettbewerbsfähig zu bleiben – vor zehn Jahren war das noch eine nützliche Spielerei. Damals musste ein System einfach funktionieren und Berichte liefern. Heute muss es in Echtzeit funktionieren – weil man dadurch deutlich effizienter wird, Kosten spart und Wettbewerbsvorteile erzielt.

Ja. Du und ich haben ja schon bei mehreren Projekten zusammengearbeitet, und du siehst auch den gesamten Markt für solche Projekte. Beobachtest du, dass alle an diesem Thema arbeiten, oder betrifft das nur einen bestimmten Anteil der Unternehmen? Oder sind es nur die großen Konzerne? Hast du dazu eine persönliche Meinung oder eine Einschätzung, wie sich der Markt in den letzten Jahren entwickelt hat?

Ben

Ich gebe einen ersten Einblick in den Gesamtmarkt, und ich denke, Stephan kann mehr zu den Details sagen. Der allgemeine Trend auf der „großen“ Seite ist: Früher konnte man sich MES-Systeme leisten – diese umfassenden, elektronischen Systeme mit zentralem Bedienpanel aus Glas. Mein erster Job war vor 15 Jahren genau in diesem Bereich. Damals haben wir Glaspanels auf SPS-Systemen (PLCs) aufgebaut das war damals richtig fortschrittlich. Aber ehrlich gesagt konnten sich das nur die größten Unternehmen der Welt leisten. Diese Systeme brachten echte Verbesserungen für die Produktion oder das Monitoring. Aber sobald man eine Ebene kleiner wurde, war das eigentlich irrelevant.
Heute ist der Zugang demokratisiert. Uber und Netflix nutzen Flink. Ich selbst arbeite schon seit vielen Jahren mit Flink, aber früher brauchte man fünf bis zehn sehr erfahrene Leute, um solche Cluster zu betreiben und zu warten. Jetzt ist das mit wenigen Klicks verfügbar. Plötzlich ist das Ganze zugänglich geworden. Es ist nichts mehr, das man sich nicht leisten konnte oder von Anfang an bauen musste – es ist etwas, das man jetzt einfach hinzufügen kann.

Stephan

Ja, und ich glaube, das sehen wir inzwischen in vielen Branchen. Es gibt eigentlich kein Geschäft, in dem das keinen Sinn machen würde. Aber manchmal fehlt den verantwortlichen Personen noch das Verständnis für die Technologie – und dafür, was Echtzeitdatenverarbeitung überhaupt leisten kann, welche Use Cases möglich sind und welchen geschäftlichen Mehrwert man daraus ziehen kann. In der Finanz- oder Versicherungsbranche ist das zum Beispiel sehr offensichtlich – wie wir es beim Beispiel mit Kreditkartenbetrug gesehen haben. Ebenso bei Anomalieerkennung, Predictive Maintenance und ähnlichen Anwendungsfällen. Aber es kann auch für den öffentlichen Sektor interessant sein, um neue Services für Bürger oder Kunden anzubieten.

Ben

Um genau diesen Punkt zu unterstreichen: Denk mal an Google Maps. Ich nutze es, um mich in Städten zurechtzufinden, in denen ich noch nie war. In London funktioniert das zum Beispiel nur, weil aus der früheren Tourismusbehörde „London and Partners“ wurde – und diese haben sämtliche APIs für das gesamte Verkehrsnetz der Stadt öffentlich gemacht. Man kann einfach auf diese Live-Feeds zugreifen. So lassen sich beispielsweise vorausschauend Zugzeiten auf den Routen anzeigen. In Helsinki gibt es sogar einen offenen MQTT-Feed für den öffentlichen Nahverkehr. Man kann in Echtzeit verfolgen, wo der Bus gerade ist. Die meisten meiner Demos mit Apache Flink basieren auf solchen Feeds – weil es so eindrucksvoll ist, zu sehen, wo sich ein Fahrzeug gerade befindet, wo es vor zehn Minuten war und in welchem Zustand es jetzt ist.
Ich komme ursprünglich aus der Logistik, und dort mussten wir oft Fahrzeugbewegungen tracken – egal ob Boot, LKW oder Lieferwagen. Der entscheidende Unterschied ist: Was ist drin? Was wurde ausgeladen? Was wurde zugeladen? Wer ist der Eigentümer? Es geht um kontinuierliche Status-Updates. Die Herausforderung ist nicht nur, einen kontinuierlichen Datenstrom zu haben, sondern dann die Antwort zu kennen, wenn man sie braucht. Asynchrone Prozesse erfordern Echtzeitverarbeitung. Ich muss z. B. nicht ständig wissen, was in meinem Fahrzeug ist – aber in dem Moment, wo ich eine Zollkontrolle habe, darf es keine Unsicherheit geben. Ich kann es mir nicht leisten, zu warten.
Die einzige Lösung ist, die Daten in Echtzeit zu erfassen – und dann bei Bedarf asynchron darauf zuzugreifen.

Okay, und vielleicht noch eine letzte Frage, denn am Ende ist das Ganze ja auch eine Investition in Technologie. Unternehmen könnten überlegen, so etwas selbst mit ihrem internen Team aufzubauen – oder sie erkennen den Vorteil, das Ganze mit Partnern wie euch umzusetzen. Was macht eurer Meinung nach Apache Flink – und eure Zusammenarbeit – besonders? Gibt es typische Stolperfallen, auf die man achten sollte? Was sind Best Practices? Warum sollte ich mich für Flink entscheiden – und warum ist eure Partnerschaft in diesem Kontext interessant? Könnt ihr darauf etwas näher eingehen?

Stephan

Wie Ben bereits erwähnt hat, ist Apache Flink derzeit der De-facto-Standard, wenn es um Stream Processing geht. Was ich wichtig finde, wenn man ein solches Projekt startet, ist, dass man beide Perspektiven berücksichtigt. Auf der einen Seite braucht man die Domänenexpertise – zum Beispiel im Bereich Fertigung: Man muss verstehen, wie die Prozesse funktionieren, welche Parameter und Sensoren relevant sind und was genau man erreichen möchte. Auf der anderen Seite steht der technische Aspekt: Wie baue ich eine Architektur, die skalierbar ist und die nötige Performance liefert? Latenz kann ein großes Problem sein. Wenn ich zum Beispiel ein Ereignis – bleiben wir beim Kreditkartenbeispiel – erst ein paar Minuten später erkenne, kann es schon zu spät sein. Oder bei einer Maschine, die beschädigt werden könnte, wenn die Temperatur einen Schwellenwert überschreitet – da muss man sofort handeln.
Man braucht also beide Seiten. Was wir bei Steadforce bieten, ist die Beratung und die Zusammenarbeit mit dem Kunden, um die entsprechenden Jobs zu entwickeln.
Auf der anderen Seite ist Flink eine sehr leistungsfähige Technologie, aber auch komplex, insbesondere im Betrieb – also in den sogenannten Day-Two-Operations. Sicherheit und Wartung sind entscheidend. Und genau da ist es von Vorteil, eine Plattform zu haben, die wirklich produktionsreif ist. Und dafür gibt es Ververica und Ben.

Okay, ja. Ben, viele Unternehmen wissen, dass Apache Flink eine Open-Source-Technologie ist, aber es gibt auch eine kommerzielle Lösung. Was würdest du sagen, sind die wichtigsten Gründe, warum sich Unternehmen dafür entscheiden, mit euch zu arbeiten? Vielleicht kannst du ein paar Aspekte nennen.

Ben

Ja, klar. Ververica ist wahrscheinlich einer der Haupt-Maintainer des Open-Source-Projekts. Wir bauen auf dieser soliden Grundlage einer offenen, verteilten Technologie auf, die es jedem ermöglicht, loszulegen. Und der Einstieg mit Apache Flink ist in den letzten Jahren deutlich einfacher geworden. Man kann einfach die Open-Source-Version aufsetzen, und sie wird funktionieren. Aber es geht nicht nur ums Loslegen. Es gibt einen großen Unterschied zwischen einem Prototyp oder einem Proof of Concept (POC) und einem echten Produktionssystem – insbesondere bei den meisten IoT-Projekten. Die Kosten eines Ausfalls bedeuten nicht nur, dass das System kurzzeitig nicht verfügbar ist oder man nichts verkaufen kann. Es kann auch sein, dass man ein paar Millionen an Inventar verliert und wochenlang nicht produzieren kann – etwa wenn in einer Glasfabrik etwas zu stark abkühlt oder große Roboter betroffen sind.
Worauf es wirklich ankommt, ist Zuverlässigkeit. Man muss wissen, dass das System morgen noch läuft, dass Sicherheitslücken gepatcht werden und dass die Personen, die das System betreiben, Experten sind. Alle Software braucht Wartung – das sind komplexe Systeme, und man kann sie nicht ohne entsprechendes Know-how betreiben. Man muss auch sicher sein, dass die Service Level Agreements (SLAs) den eigenen Erwartungen entsprechen. Wenn nicht, wird es schnell sehr teuer. Aus genau diesem Grund nutzen wir heute alle die Cloud – Rechenzentren waren nie leicht zu managen. Maschinen, Festplatten und all das sind Abstraktionen, die wir nicht brauchen. Was wir wirklich wollen, sind Ergebnisse – und Ergebnisse zu kaufen, ist fast immer günstiger, als die Infrastruktur zu kaufen, die diese Ergebnisse liefert.

Ich weiß nicht, ob ihr eine Return-on-Investment-(ROI)-Berechnung dafür habt – aber ist die Investition in diese Streaming-Technologie, wie du sie gerade beschreibst, vor allem ein Thema rund um Time-to-Market? Habt ihr Einblicke zum ROI? Ich kann mir vorstellen, dass viele Unternehmen genau das beschäftigt.

Ben

Ich gebe dir zwei Perspektiven dazu. Die erste betrifft die Kosten von Echtzeitverarbeitung. Es gibt ein berühmtes – vielleicht apokryphes – Zitat von Jeff Bezos, das besagt, dass fünf Millisekunden mehr Ladezeit auf der Amazon-Startseite 100.000 Dollar im Monat kosten würden. Das ist etwa zehn Jahre her, aber eBay hat ähnliche Ergebnisse festgestellt – mit noch höheren Beträgen, wenn sich ihre Seite verlangsamte. Der Punkt ist: Menschen nehmen solche Unterschiede sehr sensibel wahr. Und das ist nur die menschliche Perspektive. Wenn man sich Maschinen und deren Toleranzen ansieht – besonders in präzisen Fertigungsprozessen – kann schon ein einziges Grad Unterschied entscheidend sein. Wenn ich ein System mit höherer Präzision steuern kann, bedeutet das, dass ich näher an die Toleranzgrenzen heranarbeiten und schneller betreiben kann, weil ich Probleme frühzeitig erkenne.
Wir arbeiten nicht am Limit der Toleranz, weil wir keine Situation wollen, in der uns ein Problem unbemerkt durchrutscht. Aus dem gleichen Grund wird in Flugzeugen nicht so viel Titan verwendet, wie viele denken. Ein Riss in Titan ist schwer zu erkennen, während ein Riss in Aluminium auffällt. Wenn sich in Titan ein Riss bildet, ist es schon zu spät – bei Aluminium sieht man es vorher. Die Idee ist: Echtzeitüberwachung bringt dich näher an potenzielle Probleme heran, bevor sie kritisch werden.
Die Kehrseite – also die Betrachtung der Betriebskosten statt des Vorteils – ist ebenfalls eindeutig. Angenommen, ein leitender Ingenieur kostet in Deutschland 100.000 € pro Jahr. Wenn du zehn Ingenieure brauchst, um eine Plattform zu betreiben und zu warten, bist du bei einer Million pro Jahr. Wenn du weniger als eine Million für ein gehostetes System zahlst, wird schnell klar, dass sich die Investition lohnt.
Das ist die einfachste Kennzahl, aber sie zeigt nur eine Seite der Kosten. Was wir tun: Wir optimieren Flink. Unsere Version läuft doppelt so schnell – oder noch schneller – als die Open-Source-Variante. Es braucht zwar mehr Aufwand, um dahin zu kommen, aber was zählt, ist das Ergebnis, nicht der Input. Der Input kann variieren – im großen Maßstab verschwimmen diese Unterschiede. Wichtig ist: Mit besserer Technologie kannst du schneller arbeiten und mehr Fehler erkennen. Die Kosten eines Ausfalls übersteigen die Kosten eines besseren Systems oft deutlich. Wenn du nur einen einzigen Produktionsausfall verhindern kannst, bei dem ein Werk drei Tage stillsteht, hast du bereits viel gespart.

Dann ist das die Antwort. Okay.

Stephan

Ich denke, nicht alle Use Cases lassen sich direkt in Geld messen. Wenn ich zum Beispiel meinen Produktionsprozess verbessere und ein qualitativ hochwertigeres Endprodukt bekomme, hilft mir das, Kunden zu binden. Aber es ist wirklich schwierig, dies in finanzieller Hinsicht zu messen.

Ben

Absolut. Denk nur daran, wie viele Leute du auf dem Shopfloor brauchst, wenn du die Daten nicht in Echtzeit über ein zentrales Dashboard siehst. Sonst musst du zu jeder Maschine gehen und ein Messgerät ablesen. Ich habe das gesehen – ich habe es selbst gemacht. Es kostet Zeit – und ehrlich gesagt: Es ist etwas frustrierend.

Ja, genau. Und habt ihr Best Practices, wie man solche Projekte richtig aufsetzt? Du hast viele Kundenprojekte gesehen – was sind deine Empfehlungen? Worauf sollte ich achten, wenn ich so ein Projekt starten will? Wir haben ein paar Beispiele besprochen, aber was würdest du raten?

Ben

Das Wichtigste, das man bei Flink immer im Kopf behalten sollte, ist: Man kann unglaublich viele Dinge damit machen. Es gibt immer noch mehr, was möglich ist. Ich scherze oft, dass mein Job darin besteht, „Ja“ zu sagen – und ich kann fast allem zustimmen, was Flink leisten kann. Aber der erste wirkliche Schritt sollte sein, sich zu fragen: Was will ich eigentlich erreichen? In den meisten Fällen geht es um ein Qualitätsziel, ein Monitoring-Ziel oder eine bestimmte Reaktionsgeschwindigkeit. Und letztlich läuft es immer auf eines hinaus: Daten.
Also sollte man als Erstes seine Daten modellieren. Im Grunde baut man damit ein Data Mesh – ob man es will oder nicht. Und heutzutage bietet Apache Flink einige der besten Werkzeuge dafür. Modellier also deine Daten, sei dir sicher, was tatsächlich in Echtzeit verarbeitet wird, und wisse, woher die Daten stammen. Fang dann einfach an, alles miteinander zu verbinden. Schließ alle verfügbaren Datenquellen an und geh von dort aus weiter. Bau deine nachgelagerten Datenprodukte erst auf, wenn du die Daten im System hast. Es empfiehlt sich nicht, zunächst nur eine einzelne Lösung zu entwickeln und danach zu prüfen, was sich noch realisieren lässt. Zunächst sollte alles miteinander verbunden werden. Sind alle Verbindungen einmal hergestellt, lässt sich darauf wesentlich einfacher aufbauen – anstatt später auf Lücken zu stoßen und Systeme nachträglich neu strukturieren zu müssen.

Stephan

Da stimme ich voll zu. Zum Beispiel führen wir mit unseren Kunden sogenannte Starter-Kit-Workshops durch. Diese bieten wir für KI, Cloud und natürlich auch für Stream Processing an. In diesen Workshops gehen unsere Berater gemeinsam mit dem Kunden die bestehende Infrastruktur, Datenquellen usw. durch, um einen guten Ausgangspunkt für die Architektur zu schaffen oder die Ziele zu definieren, die wir erreichen wollen. Ich denke, das gilt für fast alle Arten von Softwareprojekten: Man beginnt klein, zeigt einen ersten Mehrwert und baut darauf auf. Für die ersten Schritte kann man definitiv mit der Open-Source-Version von Apache Flink starten. Aber man sollte im Hinterkopf behalten, dass irgendwann Skalierung und Produktivbetrieb kommen – und dafür wäre eine Plattform wie Ververica ideal.

Richtig. Und wenn wir schon über die Plattform sprechen, Ben, hast du einen Link, über den sich Interessierte weiter informieren können? Ich nehme an, ihr habt verschiedene Lösungen – ich könnte sie in die Show Notes packen, damit man eure Website direkt findet.

Ben

Ja, klar. Der beste Einstiegspunkt ist tatsächlich unsere Cloud. Unsere Cloud ist unserer Plattform sehr ähnlich. Sie heißt Ververica Cloud, oder wie wir sie oft nennen: VVC. Es handelt sich um eine vollständig verwaltete, serverlose Version von Apache Flink mit einigen Erweiterungen, da sie auf dem sogenannten VERA Engine läuft. Ich empfehle diesen Einstieg, weil man direkt 400 $ Guthaben zum Loslegen bekommt. Damit kann man Datenquellen anbinden, SQL-Statements modellieren und Java- oder Python-Code über seine Daten laufen lassen – alles mit relativ wenig Aufwand.
Wenn man gerade anfängt, ist das wahrscheinlich die beste Option, weil man sich um nichts kümmern muss. Die Maschinen laufen, die Kubernetes-Cluster sind gemanagt – man bringt nur noch seinen Code mit und startet.
Natürlich kann man auch mit der Open-Source-Version beginnen – da entwickelt man seine Anwendung ganz normal mit einem Java-, Python- oder SQL-Editor. Bei SQL kann man die Abfragen direkt in eine Online-Konsole einfügen und loslegen. Man kann jede gewünschte Quelle anschließen – es gibt bereits viele Konnektoren, und weitere kann man bei Bedarf ergänzen.
Selbst wenn man später On-Premise betreiben möchte, bieten wir auch eine On-Prem-Version an. Aber für den Einstieg macht das weniger Sinn – es ist immer besser, mit einer gemanagten Lösung zu starten, um sich viele Fragen zu ersparen.

Okay, sehr schön. Ich verlinke das in den Show Notes. Eine letzte Frage zum Thema On-Premise – das ist immer wieder Thema bei Kunden: Ihr bietet also eine On-Premise-Version an, richtig?

Ben

Absolut. Tatsächlich ist das genau der Bereich, in dem Stephan und ich am häufigsten zusammenarbeiten. Wir setzen viele On-Premises-Lösungen um, da es in vielen Fällen sehr hohe Anforderungen an Datenschutz und Datensicherheit gibt. Das Problem mit Maschinen ist, dass sie eine sehr lange Lebensdauer haben – viele von ihnen wurden gebaut, bevor Cybersicherheit überhaupt ein Thema war. Daher müssen sie in isolierten Netzwerken betrieben werden, und die Systeme müssen häufig physisch in den Fabriken installiert sein. Wir unterstützen viele unserer Kunden aktiv mit On-Premises-Lösungen. Wir betreiben einige der größten Banken der Welt und auch große Industrieunternehmen – speziell, weil wir gemeinsam mit ihnen On-Premises arbeiten können.

Verstehe. Also Stephan, sind das eure Industriekunden oder andere Kunden, die ihre Lösungen On-Premises betreiben möchten?

Stephan

Das ist größtenteils im industriellen Bereich.

Ja, verstehe. Vielen Dank! Ich hätte noch viele weitere Fragen, aber ich möchte auch die Geschichte ein wenig abrunden und einen Überblick geben, was Apache Flink macht, welche Use Cases damit adressiert werden und warum es wichtig ist, in Echtzeit auf Daten zu reagieren. Das ist auf jeden Fall deutlich geworden – vielen Dank dafür. Und vielleicht die letzte Frage für heute: Ich blicke auch in die Zukunft. Wir sprechen hier über aktuelle Use Cases, die heute umgesetzt werden. Was seht ihr als die nächste große Transformation im Bereich der industriellen IoT-Datenverarbeitung?

Ben

Für mich ist es das Denken über das eigene Unternehmen hinaus. Ich glaube, eine der größten Veränderungen, die wir in Zukunft sehen werden, ist die Idee, dass alles in Echtzeit funktioniert – über die gesamte Lieferkette hinweg. Momentan gibt es Echtzeit nur als kleine Inseln innerhalb einzelner Unternehmen. Vielleicht gibt es Echtzeit in einer Fabrik oder in zwei, drei, aber dass das unternehmensübergreifend funktioniert, ist extrem selten. Ich sehe als große Entwicklung die Möglichkeit, dass man einen Echtzeit-Feed von der Fabrik erhält, die die eigenen Teile produziert. Oder im Logistikbereich: Der Hafenbetreiber stellt einen Echtzeit-Feed bereit, aus dem hervorgeht, welche Schiffe an welchem Kai anlegen, und mit welcher Geschwindigkeit die Zoll- oder Lagerprozesse ablaufen. Es geht darum, nicht nur den Mittelteil in Echtzeit zu machen, sondern die gesamte Kette. Es geht ums Teilen von Daten.

Stephan

Ich würde das aus einer etwas technischeren Perspektive betrachten. Ich glaube, Stream Processing wird zugänglicher. Wir haben heute nicht über Flink SQL gesprochen – das ist die Möglichkeit, einen Flink-Job mit normalem SQL zu schreiben. Das ist natürlich viel einfacher als z. B. Java-Programmierung. Das kann sogar von Personen gemacht werden, die keine klassischen Softwareentwickler sind, aber Datenbank-Know-how haben. Ich denke, dieser Trend wird sich fortsetzen und weiter verbreiten.

Spannend. Siehst du auch, dass KI in diese Architekturen Einzug hält – zum Beispiel, um die Verarbeitung oder das Mapping von Daten zu vereinfachen?

Ben

Kurz gesagt: Ja. Ich habe es vorhin bewusst nicht zuerst erwähnt, weil KI oft das erste Buzzword ist, an das alle denken. Aber KI folgt noch dem Grundsatz „Garbage in, garbage out“. Wenn du sie nicht mit sinnvollen Daten in der richtigen Geschwindigkeit und mit einem klaren Ziel versorgst, bringt sie keinen Mehrwert. Das ist etwas, womit Stephan und ich uns in letzter Zeit viel beschäftigt haben. Die Möglichkeit, natürliche Fragen an dein gesamtes IoT-System zu stellen, ist extrem mächtig – aber wir sind noch nicht ganz so weit. Das IoT-Umfeld ist nicht in der Cloud entstanden, und API-Design ist in dieser Branche noch weit von Standardisierung entfernt.

Verstanden. Und wie passt KI konkret in den Technologie-Stack? Lässt sie sich in Apache Flink integrieren, um Dinge zu vereinfachen?

Ben

Ja, absolut. Es gibt inzwischen Copilot-Tools, die dir helfen, Flink-Code mit Assistenzfunktionen zu schreiben – wir unterstützen das aktiv. Einige Tools ermöglichen dir, eine Frage zu stellen und daraus automatisch ein SQL-Statement zu generieren. Wir arbeiten mit Partnern zusammen, die genau das machen. Auch die Verwaltung und Skalierung von Clustern lässt sich mit KI unterstützen. Flink ist sehr kompatibel mit KI – es wurde sogar mit Machine Learning als Kernanwendungsfall entwickelt. Die ML-Bibliotheken sind integriert. Tatsächlich läuft die gesamte Empfehlungs- und KI-Engine von TikTok über Flink. Dass sich das auch im IoT durchsetzt, ist sicher – es ist nur eine Frage, in welcher konkreten Form.

Ja, verstehe. Okay. Vielen Dank euch beiden für eure Einblicke und eure Zeit. Ich fand es sehr spannend, anhand praktischer Beispiele zu lernen, wie die Technologie konkret eingesetzt wird und wie eure Partnerschaft funktioniert – und auch, was ihr anbietet. Das war wirklich interessant. Vielen Dank für eure Zeit und für eure Teilnahme am Podcast. Ich überlasse euch das Schlusswort.

Stephan

Danke, Madeleine, dass wir dabei sein durften. Ich freue mich schon auf die nächsten gemeinsamen Projekte mit Ben und darauf, welche Herausforderungen wir gemeinsam angehen können. Und natürlich: Wenn nach dem Podcast noch Fragen offen sind, meldet euch gern bei uns – lasst uns sprechen, wie wir gemeinsam Softwarelösungen in Echtzeit bringen können.

Ben

Ganz meinerseits. Es war großartig, hier zu sein und diese Use Cases zu besprechen. Gerade im Industrial-IoT-Bereich neigen wir leider oft dazu, hinter verschlossenen Türen zu arbeiten. Es ist schön, mal offen darüber zu sprechen, was möglich ist – besonders mit offenen Tools.

Zum Schluss werde ich auch eure Kontaktdaten in die Show Notes aufnehmen, damit sich die Hörer mit Stephan und Ben vernetzen können. Nehmt gerne Konktakt auf. Vielen Dank nochmal – und euch eine tolle restliche Woche. Tschüss!

Stephan

Tschüss.

Ben

Tschüss.