Gegenstand unserer Wahrnehmung sind Phänomene und ihre Repräsentationen. Einige sind dabei diskret und andere kontinuierlich. Temperatur oder Zeit kann beides sein. In der IT hat man sich bisher vor allem auf die Speicherung und Verarbeitung diskreter Informationen beschränkt. Dadurch konnten viele Anwendungsfälle nicht ausreichend abgebildet werden. Heute entwirft man statt eines Systems, das Daten austauscht und verarbeitet, viele Systeme als Strom von Events. Das geht über den nachrichtenorientierten Ansatz hinaus und stellt die Art der zeitnahen Verarbeitung großer Datenmengen komplett auf den Kopf. Stand bei Big Data am Anfang die Verarbeitung großer und schwach strukturierter Daten im Vordergrund, so geht es beim FastData darum, die Daten schon vor dem Speichern analysieren und auswerten zu können.
Grundsätzlich können beliebige Formate, also auch unstrukturierte, verwendet werden. Es hat sich jedoch als universelles Datenbeschreibungsformat JSON-Schema durchgesetzt. Ein festes Schema macht nicht nur die Verarbeitung und frühzeitige Validierung der Daten einfacher. So sind inzwischen viele Industriestandards rund um JSON entstanden, das ursprünglich im Web-Bereich als JavaScriptObjectNotation entstanden ist. Um die Gültigkeit und eine Versionierung der JSON-Schemas zu erreichen, bietet sich die Confluent-Registry an, für die Landoop eine Opernfläche kostenlos zur Verfügung stellt.
Ein vielversprechenderer Ansatz für FastData bietet das Produkt Apache Kafka, das sowohl zur Nachrichten- als auch für die Stream-Verarbeitung gut geeignet ist. Ursprünglich wurde dieses Produkt für die schnelle Verarbeitung von sozialen Ereignissen bei LinkedIn entwickelt und später unter der Apache-Open Source-Lizenz verfügbar gemacht. Inzwischen hat sich das Produkt Kafka selbst weiterentwickelt und es ist eine große Anzahl von Zusatzprodukten entstanden. Das vergrößert nicht nur seine Einsatzgebiete, sondern erleichtert Erweiterungen und einen schnellen Einsatz. Nach dem letzten Apache Kafka Usage Report von Confluent, der Firma, die sich um die Weiterentwicklung und den professionellen Support von Kafka kümmert, wird dabei das Deployment in Kubernetes Cluster immer beliebter.
Inzwischen gibt es nicht nur offiziell gepflegte Docker-Container-Images von Confluent, Bitnami oder Wurstmeister, sondern auch fertige Helm-Installations-Pakete für Kubernetes, die diese verwenden. Am Einfachsten wird man hier in dem Helm-Chart-Repository Kubeapps fündig. In dessen Service-Katalog werden nicht nur Kafka-Komponenten, sondern auch bewährte Monitoring-Erweiterungen mit Dashboards, wie Grafana, Jaeger, Prometheus oder dem EFK-Stack (Elasticsearch + Fluentd + Kibana) angeboten.
Als einen weiteren Schritt, die Verwendung von Kafka in Kubernetes zu vereinfachen, gibt es ebenso von Confluent den dann kostenpflichtigen Operator. Dieser vereinfacht das Deployment, das Management und die Konfiguration von Kafka Cluster erheblich. Eine Alternative, die auch die Origin Community Distribution of Kubernetes (OKS) von Red Hat OpenShift unterstützt, ist der Strimzi Operator. Damit lassen sich eigene Kafka Cluster sowohl in der Private als auch in der Public Cloud betreiben. Es ist davon auszugehen, dass der bisher immer noch von Kafka verwendete Cluster-Manager Apache Zookeeper in Zukunft komplett wegfallen wird, um den Betrieb von Kafka Cluster sicher und einfacher zu machen. Wer selbst den Aufwand und den dafür nötigen Know-How-Aufbau sparen möchte, wird bei den etablierten Cloud-Anbietern fündig. So bieten Amazon mit Managed Streaming for Kafka (MSK), Microsoft mit Azure Event Hubs for Apache Kafka bzw. Apache Kafka für HDInsight an. Alternativ kann man auch die von Confluent angebotene Kafka Cloud unter AWS oder der Google Cloud Platform (GCP) nutzen. Dadurch, dass die Cloud-Anbieter immer Geld mit Open Source-Sofware-Diensten verdienen, jedoch selbst sich nur wenig an der Weiterentwicklung beteiligen, hat dazu geführt, dass einige professionelle Open Source-Anbieter ihr Lizenzmodell angepasst haben, um genau das zu verhindern. Das betrifft aktuell nur die Kafka-Komponenten Schema-Registry, REST-Proxy, Confluent-Connectoren und KSQL für SaaS (Software-as-a-Service) -Anbieter, die diese verwenden und nicht Software-Hersteller, die Kafka in ihre Anwendungen integrieren oder selbst betreiben.
Da Kafka nicht nur für Stream-Verarbeitung allein, sondern auch für die Datenintegration in Unternehmen und von Microservices eine immer größere Rolle spielt, sollte wie immer davor gewarnt werden, Kafka für alles einsetzen zu wollen.
Dadurch, dass Kafka, nur aus einem Satz von Java-Bibliotheken besteht, lässt es sich sehr gut in die bestehenden Entwicklungs- und heutige Cloud-native Deployment-Prozesse integrieren. Gerade für die ebenso auf der Cloud basierenden Trends wie Edge Computing oder Machine Learning lässt sich Kafka nicht nur als ein neuartiger „Enterprise-Stream-Bus“ einsetzen, sondern es gibt immer mehr Einsatz- und Mitfahrgelegenheiten. Am besten starten Sie mit einem kleinen Proof-of-Concept, wie viele unserer Kunden, um diesen dann schnell ausrollen zu können, um aus toten Daten, lebende Informationen und Entscheidungen machen zu können.
