Warum Apache Kafka® und für welche IIoT Use Cases? – Confluent Cloud, Kafka und Eventstreaming einfach erklärt

Kai – für die, die dich nicht kennen: Du bist Field CTO bei Confluent. Du beschäftigst dich hauptsächlich mit modernen Unternehmensarchitekturen, Datenstreaming und auch innovativen Open-Source- und Cloud-Technologien. Du hast ebenfalls eine eigene Website, welche ich auch verlinken werde.

Ihr bei Confluent seid ein börsennotierter Vorreiter einer grundlegend neuen Kategorie von Dateninfrastruktur, die sich auf Daten in Bewegung konzentriert. Zentral geht es um eure Cloud-Native-Plattform, die als intelligentes Nervensystem funktioniert. Es ermöglicht Daten in Motion, in Echtzeit aus verschiedensten Quellen kontinuierlich durch das gesamte Unternehmen fließen zu lassen, kann man das so sagen?

Kai

Das kann man sehr gut so zusammenfassen. Wir wollen das Ganze nicht tief technisch, sondern mehr aus Use-Case-Sicht heute betrachten. Das ist genau das Thema, bei welchem ich mich mit Kunden treffe, um das zusammen auszuarbeiten. Der Kerngedanke ist, dass ich kontinuierlich Daten verarbeiten und korrigieren kann. Dabei sowohl große Datenströme aus IoT-Sensordaten aus der Fabrik, aber auch die Korrelation dieser Daten, wie zu Beispiel mit einem ERP-System oder CRM-System. Das ist die Grundregel, wo Datenbewegungen in Echtzeit immer einen Mehrwert bringen können gegenüber der Möglichkeit, die Daten nur irgendwo zu speichern.

Das ist genau das, was ich mit vielen Kunden auf der Welt mache. Dann teile ich diese Success Storys mit anderen. Das ist der Grund, wieso wir heute hier sind, und warum es so spannend ist. Es ist wirklich ein Paradigm Shift.

Um gleich reinzugehen und das Thema einzuordnen; wir sprechen immer über Datenstreaming und Echtzeitdaten. Warum ist das, was ihr macht so wichtig? Kannst du das Thema »Echtzeit-Daten-Handling« in diesem Kontext einordnen?

Kai

In den letzten 20 bis 30 Jahren, wenn man Software entwickelt hat – egal, ob das auf dem Mainframe war, später einem modernen Server oder jetzt in der Cloud –, ist es grundsätzlich so, dass man immer Daten irgendwo herbekommen und dann in eine Datenbank oder Datei geschrieben hat. Dann hat sie später jemand dort abgegriffen. Das war dann zum Beispiel ein Report, den ich jede Woche mache oder für irgendwelche Analysen, jetzt gerade auch mit AI, Big Data und solchen Themen – aber die Grundidee bei solchen Dingen war, dass die Daten immer »adressed« sind. Das heißt, ich speichere sie irgendwo, und irgendwann später – das kann zehn Minuten oder auch einen Tag später sein – greife ich die Daten ab, um sie zu analysieren oder weiterzuverarbeiten.

Was wir nun machen, nennt sich »Data in Motion«. Also während die Daten noch relevant sind, möchte ich sie auch weiterverarbeiten und korrelieren. Da gibt es Anwendungsfälle über alle Branchen und Business Units hinweg. Man kann es sich am besten bei dem IoT-Umfeld »Predictive Maintenance« vorstellen. Natürlich kann ich die Daten auch adressed später in der Datenbank analysieren, aber dann ist die Maschine wahrscheinlich schon kaputt; dann kann ich nur noch erkennen, warum sie kaputt gegangen ist. Aber ich möchte genau diese Erkenntnisse verwenden, um in Zukunft in Bewegung auf solche Änderungen zu reagieren. Das ist der Unterschied und Paradigmen-Shift zwischen: Daten adressed in der Datenbank und wirklich Data in Motion, wenn ich die Daten kontinuierlich verarbeite. Das ist das Datenstreaming. Da geht es nicht nur um große Volumina, sondern auch um transaktionale Daten. Aber wie setze ich die im richtigen Moment ein, und zwar jetzt und nicht erst später?

Das ist der Kerngedanke, und dabei der wichtige Begriff »Echtzeit«, auf Englisch dann »Real Time« genannt; diesen immer definieren, weil jeder ihn anders definiert. Da gibt es auch bei uns ein breites Spektrum. Manche sind zufrieden, wenn man es in zehn Sekunden lösen kann, und manche müssen das in Millisekunden machen. Dann gibt es noch in der OT-Welt (Operational Technology) – also noch etwas mehr in der Produktion – das Thema »harte Echtzeit«. Das ist das, wo ich safety critical gar keine Latenz haben darf; das ist dann noch mal etwas ganz anderes. Das ist auch nicht IT; das sind dann auch nicht mehr wir; das ist einfach nur zur Abgrenzung.

Wenn wir von Echtzeit sprechen, dann ist das manchmal im Millisekunden-Bereich, manchmal im Sekunden- oder Minuten-Bereich. Es geht darum, schnell auf Änderungen zu reagieren.

Hast du ein paar Use Cases und Projektbeispiele für heute, anhand dessen wir verstehen können, wie eure Technologie funktioniert, und was der Business Impact dahinter ist?

Kai

Ich spreche dazu drei verschiedene Kundenbeispiele an, anhand derer man erkennt, dass es ein breites Spektrum ist; denn solche Arten von Datenströmen habe ich überall, und da kann ich immer einen Mehrwert generieren, auch wenn dieser unterschiedlich aussieht.

Das ist auf der einen Seite Kundenspezifisch, oder auf der anderen Seite mehr in Produktion, mit IoT-Sensordaten gedacht. Die Frage, die man sich immer stellen kann – auch als Zuhörer: Wenn ich auf Events, egal welches, jetzt reagieren kann, statt später; wenn das Business hier sagt, »Das ist mehr wert«, dann kann ich zum Beispiel meine Kosten oder mein Risiko reduzieren. Oder ich kann das Revenue oder die Kunden-Experience verbessern. Dann ist das eine Sache, wo Daten in Bewegung besser agieren können.

Ein konkretes Beispiel ist bei BMW; die rollen das Data Streaming konkret aus, um ihre Smart Factorys mit der Cloud zu verbinden, und genau diese Daten von den Fabriken in Echtzeit zu korrelieren und mit anderen Systemen, wie zum Beispiel dem ERP von SAP, zu korrelieren. Das ist ein Back-End-Prozess ablaufend, um unter anderem die OEE (Overall Equipment Effectiveness) zu optimieren.

Ein anderes Beispiel ist bei Bosch. Diese haben als ein Projekt eine Logistics Supply Chain, und dort geht es auch wieder darum, wie ich im End-to-End Prozesse und Monitore überwachen kann, um dann auf bestimmte Ereignisse in Echtzeit zu agieren. Da geht es nicht nur um diese Echtzeit-Informationen, sondern die Korrelation der Information, die jetzt passiert, mit anderen Informationen, die schon länger vorhanden sind. Da hat Bosch verschiedene Prozesse gebaut, auch zum Beispiel Track and Trace. Wenn die Geräte und Maschinen, die von Bosch verkauft werden, in der Fabrik oder irgendwo im Einsatz sind auf einer Baustelle, sodass ich alles tracken und auf Änderungen reagieren kann. Das sind einfache Use Cases, wie das Werkzeug finden, das verloren gegangen ist auf der Baustelle; aber auch frühzeitiger Alarm, um die Batterien auszutauschen oder weil der Netzwerkzugriff nicht mehr funktioniert, als zweites Beispiel.

Als drittes Beispiel, mehr in Richtung Kundenspezifik, also Customer Experience – das ist auch wieder branchenunabhängig – geht es um Themen wie After Sales. Wie kommuniziere ich mit dem Kunden? Wir haben da einen guten Use Case von der Royal Caribbean. Diese sind Cruise Ships und dort wird Datenstreaming auf dem Schiff genutzt. In diesem Fall ist es komplett disconnected von dem Internet, weil es schlechtes Internet auf dem Schiff gibt, und trotzdem geben sie Recommendations, Location-based Services, Upselling, mit zum Beispiel Inventory Management aus dem Restaurant, und korrelieren alte Daten, um bestmöglich das Revenue zu verbessern, aber auch die Kunden-Experience.

Diese Beispiele dienen zum verdeutlichen, wie breit das Spektrum an Use Cases über Branchen und Business Domains hinweg ist. Heute können wir dann explizit über BMW, die Smart Factory und SAP-Integration drüber sprechen

Ich verlinke für alle Hörer noch mal, die an der Stelle in andere Projekte nachlesen wollen, wer zum Beispiel im logistischen oder maritimen Umfeld unterwegs ist.

Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus [09:18]

Lass uns mit BMW starten; wo befinden wir uns bei BMW und was sind dort beispielhafte Prozesse?

Kai

Um das vorwegzunehmen: Bei BMW gibt es sehr viele Projekte, wo Data Streaming das Thema »Data addressed« ersetzt, weil diese Echtzeitverarbeitungen in vielen Fällen einen Mehrwert schaffen. In diesem konkreten Aspekt, wo wir darüber sprechen, geht es um das Thema Smart Factory und Shopfloor.

Wie die meisten Automobilhersteller hat BMW auch hier eine Cloud-First-Strategie. Das heißt, während die Produktion in der Fabrik at the Edge stattfindet und auch in der Zukunft stattfinden wird, weil es eben materielle Güter sind, werden diese Daten direkt aus den Factorys in die Cloud in Echtzeit, repliziert und dort mit anderen Systemen verarbeitet oder visualisiert.

Dadurch sprechen wir in all diesen IoT-Szenarien in der Regel von einer hybriden Infrastruktur, wobei aber so viel wie möglich in die Cloud ausgelagert wird. Das ist in diesem Fall mit uns auch das Beispiel. In dem Fall ist der strategische Partner die Microsoft Azure Cloud von BMW und mit uns klärt man eben alles rund um die Datenintegration und das Data Streaming von den Anwendungen aus, indem sie von der Smart Factory die Daten direkt in die Cloud repliziert, und dort üben wir den Data Streaming Hub, verarbeiten und fertigen eben auch andere neue Anwendungen, die die Daten andocken lassen.

Das ist grob gesagt, das Szenario für diesen Use Case. Auch da fängt es eher klein an mit einer Fabrik und schiebt es in einer Region in die Cloud; aber generell ist das Ziel, dass das Ganze global geht, sodass ich mehrere Factorys über die ganze Welt hinweg an die Systeme andocken kann über die Zeit.

Hybrid heißt in dem Fall: Alles, was on the Edge läuft, sind harte Echtzeit-Use-Cases, wo man schnell reagieren muss, und dann hat man verschiedene Dienste ausgelagert. Oder sie laufen auf der Microsoft Azure Cloud, wo die einzelnen anderen Use Cases stattfinden, kann man das so sagen?

Kai

Ja, richtig. Letztendlich ist es so, dass die safety critical Use Cases, also wie ich den Roboter steuere, sodass er keinen Menschen erwischt … das ist harte Echtzeit, das sind embedded Systeme mit C oder Rust und Ähnlichem. Das hat nichts mit den IT Use Cases zu tun, über die wir sprechen.

Aber sobald es in die IT geht, egal ob wir über Data Warehouse sprechen oder eine SAP-Integration, dann geht es nicht um Echtzeitkritisch, sondern »nur noch« um Millisekunden oder Sekunden. Und das sind die Daten, die dann in den meisten Fällen sehr gut in die Cloud ausgelagert werden können.

Oftmals ist das Ganze auch bidirektional; also auf der einen Seite schiebe ich so viel wie möglich in die Cloud zum analysieren in Echtzeit, aber ich bilde dann auch immer mehr Steuerungsentscheidungen in der Cloud ab, sobald es nicht mehr safety critical ist, sondern ich zum Beispiel nur noch einen Forecast mache oder nur noch die Integration mit dem Inventory Management. Denn hier geht es nicht um Echtzeit, sondern um Millisekunden oder Sekunden, um eine Entscheidung automatisch in der Cloud zu treffen.

Ich glaube, es ist ganz wichtig euren Bereich abzugrenzen; euer Bereich umfasst die nicht-harten Echtzeit Use Cases.

Um mehr in die Herausforderungen von BMW einzutauchen: Wie seid ihr ins Spiel gekommen? BMW muss ja gesagt haben: »Wir machen das nicht selber, wir setzen jetzt auf ein System, das es schon gibt«

Kai

Bei Automobilherstellern ist es ja so, dass sie alle nicht von einer grünen Wiese anfangen, sondern bereits Systeme haben. Die Grundprobleme sind, dass sie Informationen für andere gar nicht bereitstellen können. Sie wissen gar nicht, was in einer Fabrik genau passiert. Wie sieht mein Inventory gerade aus? Ist bei diesem Roboter die Batterie schon dreiviertel leer? Das sind alles Informationen, die dieser Roboter oder der Shopfloor möglicherweise schon hat, aber nicht der Entscheidende, der dann nachbestellen kann.

Man kann dann immer mehr digitalisieren und automatisieren. Das Problem daran ist aber, je mehr ich automatisiere und digitalisiere, desto mehr Daten habe ich. Dann kommt das Thema Skalierbarkeit auf, weil ich nicht nur in Near Real Time oder in Echtzeit agieren möchte, sondern ich muss das Ganze skalieren können. Gleichzeitig muss ich dennoch Nicht-Echtzeit-Systeme anbinden. Wenn ich zum Beispiel mit einem alten ERP-System auch noch on premises im Datencenter bin, ist das auch noch nicht Echtzeit. Somit brauche ich genau diese Datendrehscheibe, die zwar hoch skalierbar und in Echtzeit Daten abarbeiten und korrelieren kann, aber deswegen genauso mit anderen Systemen, wie in einer klassischen Datenbank oder ERP-System Daten verbinden und anbinden kann.

Basierend darauf kommt man hin zu neuen Technologien, wo Data Streaming viele Lösungen bieten kann. DM und andere Komponenten in die Cloud, wenn immer es sinnvoll ist. Der Fokus dabei ist, die Business-Probleme zu lösen und eben nicht die Infrastruktur zu betreiben und hier den meisten Aufwand zu leisten.

Das größte Problem ist, nicht nur bei BMW, dass IT-Experten rar sind, und die paar, die ich habe, da möchte ich lieber, dass diese sich um Anwendungen kümmern können, anstatt um die Infrastruktur und ihren Betrieb. Das ist, was der Cloud Service Provider mit kritischen SLAs abdecken kann, sodass BMW sich wirklich um die Business Cases kümmern kann.

Eines der ganz großen Business-Probleme ist hier »Time to Market«. Ich kann, wenn ich die Datendrehscheibe einmal habe, die Daten von den Robotern und dem Shopfloor bekomme, in der ersten Linie das unter Umständen nur für die Visualisierung bauen. Wenn die Daten dann sowieso fließen, kann ich später an diese Daten auch von anderen Systemen andocken.

Die Daten müssen also für die Entscheider und verschiedenen Personen verfügbar sein. Kannst du noch andere Beispiele nennen, welche Datenpakete für BMW relevant waren?

Kai

Hier ist auch der spannende Punkt; es geht um die OT-Welt; dort geht es um große Datenmengen von Sensordaten. Also was aus den Maschinen kommt, was vom Shopfloor kommt, was von den Robotern oder was kommt zum Beispiel auch von historischen Data Historians, also von Legacy Technology, die eben auch noch proprietär, vielleicht in der Fabrik auf einem Windows Server läuft. Da kommen alle Daten aus der Fabrik.

Das sind oftmals sehr große Daten, und in solchen Fällen interessiert mich oftmals nicht die Information. Wenn ich zum Beispiel von einer Maschine die Temperatur messe, dann muss ich im ERP-System nicht all diese großen Datenmengen einfügen, sondern nur möglicherweise die Korrelation, also eine Aggregation der letzten Stunde. Oder wenn irgendwelche Thresh Holds erreicht werden, also wenn die Temperatur über einem gewissen Schwellenwert ist.

Ich möchte nicht alle großen Datenmengen irgendwo anders hineinschieben. Auch weil die Systeme dafür teilweise gar nicht gebaut sind, sondern nur relevante Daten von der OT-Welt. Aber dann, wenn ich in die IT-Welt gehe, dann geht es hier zum einen um klassische IoT-Integrations-Komponenten, wie eine SAP-Lösung für das MES- oder ERP-System, aber dann auch mit Kundenstammdaten, wo ich vielleicht in der Cloud eher ein Salesforce-CRM einsetze. Oder in Richtung Analytics, wo ich mein Data Warehouse und/oder mein Data Lake für Machine Learning und AI mit connecte. Oder wenn ich eigene Anwendungen baue mit Java, C++ oder .NET.

All diese Daten sind je nach Use Case relevant, und das ist das Spannende. Dann kann ich die Daten kombinieren und korrelieren. Deswegen kann ich nicht generisch sagen, was BMW hier oder dort einsetzt. Sie connecten die Daten und dann kann die Business Unit entscheiden, wie sie Daten korreliert. Das immer gemäß nach Vorschriften, wie GDPR in Europa zum Beispiel, damit das Ganze trotzdem auch datenschutzkonform ist.

Es ist wahrscheinlich so, dass BMW hunderte von Use Cases hat, je nach Business Impact und Unit, die intern laufen.

Kai

Oftmals ist jetzt auch noch gar nicht klar, was ich später mit den Daten alles machen kann. Aber wenn sie in Echtzeit durchfließen, wo ich das nächste Business frage: »Hey, hier sind die Daten in Echtzeit, dort drüben kriegst du sie später, was ist besser für dich?« Genau so kommen dann immer mehr auf diese Systeme zu und greifen die Daten mit ihrer eigenen Schnittstelle ab.

Das klingt alles relativ groß mit SAP, den Oracle-Daten und ich habe ebenso auch verschiedenste OT-Daten; wie fangen eure Kunden an? Nimmt man sich ein Datenpaket und schiebt das – das ist im Fall BMW etwas komplizierter, weil es eine Cloud-First-Strategie ist, aber da sind ja noch nicht alle. Wie ist die Denkweise eurer Kunden hier?

Kai

Sie fangen klein an. Es ist immer die Empfehlung von uns, mit einem ersten Pilotprojekt zu starten, wo ich zunächst nur an ein paar Schnittstellen andocke. Wenn das Ganze läuft, werden im ersten Fall – den Pipelines – die Daten nur in ein bis zwei Schnittstellen geschoben, zum Beispiel für die Visualisierung. Der erste Quick Win ist oftmals, einfach zu wissen, was im Shopfloor auf den verschiedenen Schnittstellen passiert.

Das erste Projekt muss immer Business Value bringen; in welcher Form auch immer. Ob es Kostenreduzierung ist oder eine bessere Kundenexperience. Nur so kann man anfangen, erfolgreich zu deployen. Dann kann ich das Ganze immer weiter ausrollen.

Es ist aber auch möglich, klein zu denken und anzufangen. BMW und andere Hersteller kommen nicht an und sagen: Okay, ich mache hier einen Big Bang und vernetze die gesamte Welt; sondern sie fangen mit einer Smart Factory an. Das ist eine strategische Methode, die eher digital veranlagt ist.

Das sieht man auch bei Mercedes aktuell. In Stuttgart haben sie ihre digitalisierte Fabrik, und natürlich fängt man eher mit etwas Leichterem an, weil es eher grüne Wiese ist und eher modern mit offenen Schnittstellen und den neuen Technologien ist, die sie dort auch in der Fabrik einsetzen. Wenn das läuft, kann ich das Ganze immer mehr strategisch ausrollen und dann wieder pro Fabrik entscheiden, wie ich das anbinde. Weil, wenn du zu BMW oder Mercedes gehst, da ist es nicht so, dass weltweit jede Fabrik gleich aussieht. Nur weil es hier in Deutschland läuft, heißt es nicht, dass es irgendwo in Mexiko genauso funktioniert.

Genau das ist diese Schritt-für-Schritt-Integration und das Ausrollen von neuen Systemen. Und während in diesem Beispiel mit BMW bei Fabriken auf der ganzen Welt ausgerollt wird und die Integration in die Cloud implementiert wird, können parallel in Deutschland beim ersten Use Case, der bereits live ist, hier schon wieder andere Business Units an die Daten andocken und weitere Use Cases bauen. Das ist separat und mehr Domain-driven Design genannt. Also dass ich agil und entkoppelt neue Anwendungen bauen kann; das ist ganz wichtig bezüglich Time to Market.

Wir in Deutschland müssen noch von diesem Motto weg, erst zu planen und dann zu machen. Das machen die Asiaten und Amerikaner bereits seit Jahren besser. Sie probieren erst Sachen aus, und bei uns soll es in die gleiche Richtung gehen. Gerade in der Cloud kann ich mal etwas neues starten und ausprobieren. Wenn es nicht klappt, schließe ich es einfach wieder ab, denn dann mache ich eben einen Shutdown im Cloud-Service und probiere etwas Neues aus.

Lösungen, Angebote und Services – Ein Blick auf die eingesetzten Technologien [19:36]

Wir sprechen über verschiedene Standards. Wie funktioniert bei euch die Datenaufnahme? Ich habe nun meine Schnittstellen, egal ob das in der OT-Welt ist oder in den verschiedenen Systemen; wie bekomme ich die Daten aus den Systemen und Datenquellen heraus?

Kai

Da gibt es diverse Möglichkeiten. Als Teildaten-Streaming-Plattform, ist das eine sogenannte »Cloud-Native-Integrations-Plattform«. Entweder, wenn ich moderne Schnittstellen habe, dann kann ich diese direkt in die Datendrehscheibe hereinschieben – da sprechen wir dann über moderne offene Schnittstellen, wie OPC UA oder MQTT, was jetzt in der IoT-Welt bekannt ist, oder oft immer noch ein http-Webservice, den ich andocke. Oder ich habe out of the Box Konnektoren zu verschiedenen Produkten, wie SAP S/4HANA zum Beispiel; das ist die einfachste Möglichkeit und eine ideale Lösung. Das ist auch genau der Grund, warum die meisten Kunden in solchen Projekten eher in der modernen Smart Factory anfangen, weil dann auch moderne Roboter involviert sind, die moderne Standard-Interfaces haben.

Die Realität Stand heute ist trotzdem, dass bei den meisten Kunden das Ganze ein Brownfield ist. Wir wissen alle, dass Fabriken nicht nur fünf oder zehn Jahre laufen, sondern 20 bis 40 Jahre. In solchen Fällen kann ich nicht über einen offenen Standard andocken, weil das proprietäre PLCs und Data Historians sind. Dann ist es oftmals so, dass ich immer noch eine Third Party brauche, um solche Schnittstellen anzudocken. Das ist dann häufig der Data Historian, der sowieso schon läuft, aus dem ich meine Daten schiebe. Oder ich installiere eine andere Technik oder binde die Dateien direkt an, die auf dem Windows Server noch laufen.

Das sind alles verschiedene Möglichkeiten; da bin ich relativ flexibel. Letztendlich muss ich die Daten irgendwie in die Drehscheibe bekommen. Von da an kann ich diese nach den definierten Standards in alle anderen Systeme hineinschieben; dann ist es einfach. Deswegen ist in diesen IoT-Projekten die letzte Meile, Integration hin zum Shopfloor, die schwierige in der Regel. Weil es hier nicht offen auf Standards basiert. Wenn ich in der Cloud bin, ist das alles in irgendeiner Form Standard-basiert.

Es sind oft immer noch proprietäre Protokolle. Auch bei Amazon, wenn ich einen S3 Object Store habe, ist dieser proprietär, aber dennoch ist es ein offenes Interface, sodass ich alles Nötige einschieben kann, mit ganz klar definierten Schnittstellen, und wieder Daten rausholen kann. Das ist der aktuelle Trend. Deswegen ist es in der Cloud viel einfacher, sowohl zu anderen Software-as-a-Service-Lösungen oder auch wenn ich eigene Schnittstellen bauen möchte.

Wenn du von der Datendrehscheibe und der Lösung von euch aus sprichst; was ist der erste Schritt? Ich bekomme Zugang zur Confluent Cloud mit allen Ressourcen und Möglichkeiten, die ich habe, um meine Daten an diese Datendrehscheibe anzubinden, oder wie ist das?

Kai

Genau das ist der Charme an der Cloud; nicht nur bei den Confluent Clouds, sondern auch bei den ganzen AWS Services oder Ähnlichem. Die sind dann »Serverless« oder »fully managed«. Das heißt, ich muss mich nicht darum kümmern, wie ich das Ganze betreibe und installiere, später skaliere oder supporte, weil genau das dann von der Confluent Cloud gemacht wird. Dadurch kann ich einfach ein neues Projekt starten – ich starte den Service und habe ein kostenloses Budget am Anfang, und kann dann einfach einen ersten Sensor connecten. Vielleicht auch noch früher: Ich will gar nicht erst den Sensor aus der Fabrik connecten, sondern ich probiere es generell zunächst in der Cloud und habe einen Dummy Service, der mir verschiedene Schnittstellen-Daten produziert. Dann fange ich an, konsumiere diesen Datenstrom und verarbeite ihn dann. Das mit dem gleichen Tool, wie zum Beispiel einer SQL Query, die ich dort in der Datenplattform eingebe. Dann filtere oder aggregiere ich Daten, weil es in der Regel so ist, dass gerade bei Daten aus der Fabrik nicht alle Daten ins SAP-System sollen. Sondern nur die Korrelation oder Aggregation der letzten Stunden oder falls es Temperaturausschläge gab.

Das sind die Daten, die ich wirklich in die Confluent Cloud gebe, also auf der Anwendungsseite. Ich kann entweder das Ganze über eine grafische Oberfläche machen, oder wenn ich sage: Nein, ich bin Data Scientist, ich verwende für alles Python, dann verwende ich eben meinen Python Client für die Data-Streaming-Lösung; so bin ich völlig flexibel.

Mittlerweile ist es so, dass viele andere proprietäre Lösungen und Data Historians eine Datenstreaming-Schnittstelle für Kafka und solche Technologien besitzen, damit ich auch das als Möglichkeit habe. In der Regel gilt auch da, man verwendet das, wo sich der Kunde am wohlsten fühlt.

Aber das wichtige ist, ich schiebe die Daten in unserem Fall in die Confluent Cloud, oder dass ich wissen muss, wie das Ganze dort betrieben und skaliert werden kann; das ist der riesige Mehrwert, warum ich mit der Time-to-Market-Sichtweise alles viel einfacher in der Cloud als Pilotprojekt starten kann.

Wichtig zu verstehen ist, dass ihr keine klassische IoT-Plattform seid, an die ich meine gesamten Assets anbinde, sondern dass ihr eine einzelne verteilte Speicherebene seid, wo ich die ganze Kapa und Leistung an Infrastruktur nutzen kann, um verschiedenste Use Cases dort aufzusetzen; kann man das so sagen?

Kai

Absolut, und deswegen sind wir auch keine Konkurrenz zu IoT-Plattformen, von Siemens MindSphere bis irgendwelche Open-Source-Eclipse-Projekte oder Ähnliches. Das ist genau komplementär. Sie machen zum Beispiel die letzte Meile Integration hin zum Modbus oder auch zur OPC-UA-Schnittstelle und unlined Gateways. Sie haben auch manche Use Cases, die sie umsetzen, aber über uns geht: der Rest of the Enterprise, so nenne ich es immer. Wenn ich verschiedene Schnittstellen miteinander korrelieren möchte, und das ist oftmals nicht nur die reine OT-Welt, sondern auch die IT-Welt. Das ist der Charme davon, wie es bei BMW auch der Fall ist. Ich schicke die Daten zunächst aus dem Shopfloor-Level in die Datendrehscheibe – oder wie es manche Kunden nennen: Zentrales Nervensystem für Echtzeit-Daten – und von hier kann dann jeder diese Daten wieder abgreifen. In den meisten Fällen beim Kunden ist es so, dass ich einige IoT Use Cases drumherum gebaut habe; manche direkt mit Data Streaming, manche wieder mit einer anderen Third-Party-Lösung oder es geht in die IT-Welt, dass ich das Ganze in Richtung Data Analytics schiebe, also in das Data Warehouse, den Data Lake und so weiter.

Der Charme davon ist, ich schiebe die Daten einmal rein, aber die Daten sind immer noch in Motion. Das heißt ich kann, egal ob in der OT- oder IT-Welt, meine Real-Time-Anwendungen bauen oder sie in einen Data Lake oder Data Store addressed schieben, um dort Badge-Analysen zu machen.

Das ist das, was diese Technologie dahinter so sehr von anderen Middleware Plattform unterscheidet, weil trotzdem Systeme völlig entkoppelt voneinander sind. Auch, weil jede Business Unit selber entscheiden kann, ob sie .NET oder Python verwendet, oder ein Third-Party-Produkt oder Software-as-a-Service-Produkt kauft.

Dass die Systeme voneinander entkoppelt sind, ist neben dem Real Time Messaging an sich ebenfalls sehr wichtig. Weil das System die Events und Informationen auch lagert und speichert, solange man möchte. Ich kann auch eine Woche später hingehen und historische Daten abspielen.

Wie machen das heutzutage die Kunden, die noch nicht auf euren Standard setzen? Baut man sich dann individuelle Lösungen?

Kai

Man muss ganz klar sagen, damit das nicht falsch rüber kommt, »Lösungen« ist hier vielleicht der falsche Begriff, weil das die Infrastruktur ist. Das ist kein Produkt, das du kaufst, womit du wirklich Predictive Maintenance oder Kundeninteraktionen machst. Deswegen nenne ich es auf Deutsch »Datendrehscheibe«, weil ich damit meine Datenströme integrieren kann. Sowohl aus der IoT-Welt als auch aus der Enterprise- und IT-Welt. Und dann die Daten weiter integriere oder filtere und verarbeite. Dann muss ich darauf aufbauend meine Anwendungen bauen.

Wie verwenden uns Kunden? Sie bauen den sogenannten »Modern Data Flow« auf Echtzeit-Daten und obendrauf bauen sie Anwendungen. Das ist etwas, was sie teilweise mit unseren Komponenten bauen können, aber das muss man entweder selber bauen oder wieder als Software as a Service einkaufen und integrieren.

Da ist das Schöne, dass das de facto Standard ist. Kafka wird mittlerweile von über 100 000 Organisationen weltweit eingesetzt. Es ist Open Source, also auch Teil der Idee dahinter. Man kann es kostenlos einsetzen und selber betreiben. Und man kann wenn man damit selbst anfängt, es später ohne Probleme und Downtime in unseren Cloud Service mitnehmen und übergeben.

Das ist genau die Idee, wie Kunden anfangen; viele direkt in der Cloud, es gibt aber auch schon oft Projekte, die das bereits ein paar Jahre machen und diese wollen dann aus Kosten- oder SLA-Gründen damit eine Cloud mit kreieren. Da gibt es diverse Möglichkeiten, wie man damit startet.

Wegen dem Thema Community; ihr seid hunderttausende Menschen, die daran arbeiten und es ist ein Open-Source-Standard. Das heißt, ich habe als Entwickler die Möglichkeit, das dort mitzugestalten. Das Ganze folgt eurem Gründungsgedanken dementsprechend; ist das so richtig?

Kai

Zur Historie; es ist so, dass diese Technologie, sie heißt »Apache Kafka«, vor über zehn Jahren von LinkedIn, also auf dem Silicon Valley gebaut wurde, weil es nichts Besseres gab, um in Echtzeit große Datenmengen zu verarbeiten. Sie wurde Open Source, und die Erfinder von Kafka haben Venture Capital bekommen, um Kafka enterprise-ready zu machen, vor etwa sieben bis acht Jahren.

Das Ganze hat sich mittlerweile so am Markt als De-facto-Standard etabliert, dass es kaum Firmen gibt, die es nicht einsetzen für solche Use Cases. Deswegen gibt es dort nicht nur einen Hersteller; unter anderem wir bei Confluent machen das. Da sind die Gründer von Kafka auch mit drin. Aber auch die großen Firmen, also egal ob du zu einer IBM gehst, zu Microsoft, Amazon oder auch zu IoT-Herstellern. Sie machen entweder alle selber etwas mit Kafka, oder zumindest integrieren sie mit Kafka, weil es der De-facto-Standard am Markt ist. Da ist die riesige Community hinter, wo man es selber als Open Source betreiben kann oder in einen Cloud Service gibt oder kombiniert.

Das ist der Gedanke dahinter. Also nicht nur den Datenstreaming zu betreiben, sondern das ganze Ecosystem außenrum, beispielsweise Konnektoren zu bedienen. Da gibt es kommerzielle Konnektoren, die wir in unserer Cloud hosten, damit ich mich nicht drum kümmern muss. Man kann sich aber genauso seine eigenen Konnektoren bauen. Das ist ein ganz anderer Gedanke als das, was viele andere aus dem OT-Umfeld kennen, mit den ganzen Data Historians und anderen Plattformen. Es ist sehr weit weg von den proprietären Schnittstellen, sondern hin zu offenen Interfaces. Es geht nicht darum, dass alles kostenlos oder Open Source sein muss, sondern es geht darum, dass ich selbst vielleicht etwas baue und damit Geld verdienen möchte, damit ich das dann trotzdem offen anbinden kann. Dann geht es wieder um das Thema Time-to-Market-Flexibilität, und nicht nur ein Vendor-Login zu einem Hersteller. Deswegen die Erfolgsgaranten, warum Kafka sich am Markt so etabliert hat.

Wir haben auch viele Partner, mit denen wir arbeiten und die euch alle erwähnen, weil ihr die Schnittstelle in die Integration dieser Full-Power-Infrastruktur seid, egal ob das eine Salesforce, SAP oder verschiedenste Partner sind, die dort anbindbar sind.

Um den USP von euch herauszuarbeiten mit der Skalierbarkeit; es geht ja auch darum, bis zu eintausend Maschinen anzubinden. Warum ist das, was ihr tut skalierbar?

Kai

Warum ist es skalierbar? Weil deswegen LinkedIn vor über zehn Jahren die Technologie genau so aus der Architektur gebaut hat, weil sie die Skalierbarkeitsprobleme hatten. De facto ist es so gebaut worden, deswegen gibt es das Problem »Skalierbarkeit« nicht, wie es das bei historischen Plattformen oft gab.

Ich kann heutzutage Kafka sowohl für Big Data Analytics Use Cases verwenden, wo ich mit einem Cluster 10 GB und mehr Daten verarbeite pro Sekunde – das sind sehr große Datenmengen, die aus dem Shopfloor kommen. Ich kann aber auch transaktionale Daten mit Echtzeit-Garantien verarbeiten und auch ohne Datenverlust. Zum Beispiel, wenn ich eine Transaktion mit SAP- und einem MES-System korrelieren möchte. Das ist der Charme davon.

In der Cloud ist es noch einfacher; da muss ich mich gar nicht drum kümmern, dort wird es komplett von uns übernommen. Ich kann auch Open Source Kafka verwenden und es selber skalieren. Da muss ich den Betrieb übernehmen und das Risiko einschätzen, wenn etwas ausfällt; wie mache ich ein Performance Tuning als Beispiel.

Das ist der Gedanke von fully managed und Serverless.

Dazu noch ein Hinweis: Wenn sich das jemand selber anschaut, nicht nur auf das Marketing schauen, sondern wirklich auf die Lösungen. Das ist das, was viele Hersteller leider nur behaupten. Was sie eigentlich machen, ist, sie provisionieren Infrastruktur und übergeben es dann an den Kunden, ohne das Ganze zu supporten oder automatisch zu skalieren. Das ist der Uniqe Selling Point; es ist bei uns fully managed und nicht nur die Drehscheibe, also das Messaging, sondern auch der Storage, auch die Datenintegration und die Datenverarbeitung. Sodass ich wirklich – inklusive Data Governance und Security – End-to-End-Lösungen bauen kann. Dann kommen solche Lösungen von Bosch für End to End Supply Chain and Logistics, BMWs Smart Factory Integration oder die Customer After Sales Scenarios, B2C und B2B zustande.

Ohne diese Lösungen geht im schlimmsten Fall das Netzwerk in die Knie, weil ich so viele unterschiedliche Datenpunkte habe, mit denen ich arbeiten muss. Diese Infrastruktur muss ich irgendwo auslegen. Ihr geht dort rein, händelt die Infrastruktur und bietet das Echtzeit Datenstreaming dazu.

Kai

Ganz wichtig aber auch, weil nicht alle Systeme Real Time können: Andere können auch nicht so skalieren, wie manche andere modern in der Cloud. Ein SAP-System erwartet nicht, dass ich große Datenmengen hineinschiebe und deswegen ist der weitere Unique Selling Point von Kafka, dass ich zwar viele Daten einschiebe, aber dann die Daten oft nur korreliere und relevante Daten ins nächste System schiebe. Oder ich kann die Daten auch in Echtzeit in ein Real Time Alerting System schicken, währenddessen auf der anderen Seite SAP nur manchmal anfragt und bestimmte Informationen bekommt. Das ist die wichtige Entkopplung, dass das SAP-System Daten zu einem anderen Zeitpunkt, zu einer anderen Menge anfragt als ein Monitoring oder MES-System.

Unabhängig hiervon ist eine Data-Analytics-Plattform, ein Data Lake in der Cloud, da schiebe ich trotzdem wieder alle Daten rein, weil es für andere Analysefunktionen gedacht ist. Oder für AI, Machine Learning, um Modelle zu trainieren. Das sind weiterhin Badge Work Clouds in diesen Systemen; aber auch diese Systeme sind nicht dafür gebaut, es in Real Time zu machen, weil es andere Use Cases sind; deswegen die Analytics-Plattform.

Normalerweise bekommen die Daten von Kafka eher Near Real Time oder Badge, weil es hier keinen Sinn macht, jeden Cent zu Information einzeln einzuschicken. Und so kann jede Business Unit mit ihren eigenen Technologien und Produkten, ihre eigenen Schnittstellen bauen und die Daten konsumieren; wann und wie sie es möchte. Das ist ein Beispiel von BMW und der Hauptgrund, warum Kafka so erfolgreich dort ist. Weil man flexibel die Daten abgreifen kann und nichts vorgeschrieben bekommt, über das Kommunikationsparadigma oder andere. Das kann jeder mit einer Freedom of Choice, mit seiner eigenen Technologie machen.

Ergebnisse, Geschäftsmodelle und Best Practices – So wird der Erfolg gemessen [33:55]

Wie sieht es mit eurem Business Case aus? Was war der Business Case von BMW und was ist der Outcome dafür, dass sie mit euch hier arbeiten?

Kai

Man muss fairerweise sagen, ein Business Case bei solchen Infrastruktur-Technologien zu finden, ist häufig schwer. Der Kernpunkt bei BMW oder auch generell bei den IoT-Projekten ist, erst mal die Daten wirklich anzubinden, um sie dann verschiedenen Business Units zur Verfügung zu stellen, sodass sie diese einfach abgreifen können. In diesem Fall ist Time to Market ein großer Win, weil ich die Daten nicht über Punkt-zu-Punkt immer wieder integrieren muss, was aus Datenübertragungssicht kostenintensiver ist, aber auch von der Implementierung, und dann alle diese Daten abgreifen können, für neue Projekte. Wie es das Business möchte; Real-Time-Anwendungen bauen, oder die Daten in ein eigenes Warehouse schicken, um Reports zu fangen.

Der andere Punkt ist, dass es auf einem De-facto-Standard basiert und ich es überall rausholen kann. Heute fange ich vielleicht auf Microsoft Azure an, aber morgen gibt es möglicherweise eine Fabrik in China als Mainland, und dort gibt es nur Tencent und Alibaba Cloud; dennoch kann ich genau die gleichen APIs dort ausrollen. Das sind die Mehrwerte, die man in IoT-Szenarien sehr oft sieht, und letztendlich der Business Case dahinter. Wenn ich auf die Euros schaue, da geht es um Themen, wie die Overall Equipment Effectiveness (OEE). Das sind im Shopfloor-Level die Standard-Messwerte. Dort geht es darum, dass jede Stunde Downtime unheimlich viel Geld kostet. Wenn ich Themen wie Monitoring, Predictive Maintenance oder Condition Monitoring mit Echtzeitdaten auch für große Datenmengen abbilden kann, ist der Business Case dahinter oft auch Risikominimierung.

Es gibt viele Beispiele, wie man das dort berechnen und definieren kann, wo der Business Value für mein Projekt und für die Infrastruktur ist.

Der Business Case ist zum einen also Skalierbarkeit. Es gibt eigentlich nichts, was Kafka in die Knie zwingen kann, egal mit wie vielen Daten ich arbeite. Ebenso die leichte Integrierbarkeit. Unabhängig davon, welche Konnektoren ich auch brauche. Nicht zu vergessen die ganze Thematik mit der Infrastruktur und die Rückverfolgbarkeit von einzelnen Datenpaketen.

Ich kann die Daten mit euch korrelieren. Auf der Datendrehscheibe kann ich – egal welche Daten – miteinander verarbeiten.

Kai

Sehr gut zusammengefasst. Das sagen auch wir unseren Kunden – fangt mit einem Use Case an, der wirklich Business Value bringt, denn wir sprechen dennoch über Daten. Wir haben über viele Jahre in den Data Lakes gesehen; nur alle Daten hereinzuschieben und später zu verarbeiten, ist kein Win oder Business Value. Das ist der Grund, warum wir mit unseren Kunden ein Pilotprojekt starten, aber es muss ein wirkliches Projekt sein, ansonsten macht es keinen Sinn. Wir können gerne bei Interesse im Nachgang noch mal darüber sprechen, in den entsprechenden Domains.

Noch mal zur Business-Value-Sicht, was Leute oft unterschätzen, aber auch zeigt, warum wir mit so vielen Kunden zusammenarbeiten und auch öffentlich mit ihnen sprechen: Auch aus Kundensicht ist es sehr schwer heutzutage gute Leute zu finden. Wenn diese Projekte nicht mehr auf einer proprietären Legacy-Technologie gebaut werden, sondern auf offenen De-facto-Standards, wie Kafka, was Leute bereits auf der Universität lernen, dann findet man dort auch Leute. Wenn ihr das nächste Projekt in der Cloud mit Kafka macht … das wollen die Leute machen und das ist nicht zu unterschätzen, auch aus Hiring-Sicht, um neue Experten zu finden. Weil es eine zukunftsträchtige, skalierbare und moderne Technologie ist.

Hast du Erfahrungen von Kunden, welche du aus den Berichten der Projekte, die ihr bislang gemacht habt, teilen kannst?

Kai

Ich möchte noch ein Beispiel aus einer anderen Kategorie ansprechen. Wenn wir über Porsche sprechen, das zeigt schön die Reise von Porsche. Was bei Porsche, die ähnlich wie BMW viele Datenprobleme haben, spannend ist, da sie ein Premium Anbieter sind und eines ihrer Mottos ist: Es ist kein Kunde, sondern ein Fan. Er muss sie wirklich lieben – Turn Customers into Fans. Das machen sie mit einer Plattform, die sie »Streamzilla« genannt haben. Das ist die große Plattform von ihnen, die zentral Data Streaming anbindet und worauf viele Anwendungen aufgebaut werden können. Viele dieser Use Cases sind nicht nur IoT-trächtig, zum Beispiel Over-the-Air-Updates, was sie mit abbilden, sondern auch Customer-facing Apps für After Sales. In vielen Use Cases ist es nicht Pflicht, aber zumindest besser für Kunden, wenn sie in Echtzeit funktionieren. Zum Beispiel, wenn ich eine neue Funktion im Auto kaufe, dass ich sie online bezahlen kann und dann direkt in Echtzeit das Feature erhalte.

Wenn das jemanden interessiert, Porsche hat bereits auf dem Kafka Summit gesprochen, wie sie mit Kafka das Thema umsetzen. Porsche hat nun intern Streamzilla zum De-facto-Standard für diese eventgetriebenen Anwendungen gemacht. Sie fangen also mit ein, zwei, drei oder auch vier unabhängigen Projekten an, gehen aber dann immer mehr auch in die Cloud. Dann definieren sie Standards, wie zum Beispiel auf Apache Kafka. Deswegen sind wir kundenübergreifend nicht nur im Automotive-Bereich, wo wir heute viel drüber gesprochen haben.

Themen wie Kundenbeziehungsmanagement oder After Sales; dort kann man viel von Retailern lernen, weil sie uns dort häufig ein paar Jahre voraus sind. Da gibt es auch hunderte von Beispielen, unter anderem die VOLLMER Group aus den USA. Kunden können dort gerne auf uns zukommen, um mehr Success Storys zu besprechen.

Ich verlinke euren Kafka Summit in den Shownotes, um das Ganze noch mal nachzulesen.

Vielen Dank, dass du heute da warst und dass du dein Wissen mit uns geteilt hast. Vor allem auch, damit Leute aus anderen Bereichen wissen, dass es das gibt, was die Vorteile sind, um das Thema Skalierbarkeit für die Zukunft auch anzugehen.

Kai

Mach es gut! Man hört sich.