Serverless und die Datenschicht – Über Flüsse, Seen und Dämme in Zeiten von Serverless

  • Serverless-Funktionen sind zustandslos, aber wie gestaltet sich der Umgang mit Daten?
  • Data Lake und Data Streams sind wichtige Komponenten von Serverless Architekturen
  • Datenschicht und Geschäftslogik müssen entkoppelt sein und bleiben, damit agile Entwicklungsmethoden und Skalierungseffekte greifen
  • Serverless-Applikationen bedeuten verteilte Anwendungen von Anfang an

Für Unternehmen ist die Nutzung von Serverless-Applikationen in ausgewählten und wohl definierten Einsatzszenarien eine sehr sinnvolle Ergänzung, wenn es um schnelle, schlanke, skalierbare und kostenoptimierte Lösungen geht. Dennoch benötigt auch diese Art von Applikationen Daten, die prozessiert werden müssen. Daher stellt sich die berechtigte Frage, welches die richtige Strategie bei der Konzeption einer Datenstrategie für Serverless-Applikationen generell und unter der Einbeziehung von einer ganzheitlichen Datenstrategie im Unternehmen ist. Betrachten wir dazu noch einmal kurz die Architektur von Functions-as-a-Service basierten Anwendungen.

Ein Ereignis stößt dabei die Ausführung von einer Funktion an, welche dann auch verteilt auf mehreren Rechnern laufen kann. Die Funktion wird also erst aktiv, wenn das Event eintritt. Daten können entweder in begrenztem Umfang durch das Event selbst übermittelt werden oder müssen durch die Funktion abgerufen werden. Dabei ist gleich eines der grundlegenden Probleme offensichtlich: Die Serverless-Anwendungen sind für Geschwindigkeit und Skalierung ausgelegt. Wenn Daten aus einem Hadoop-Cluster oder einer Datenbank abgefragt werden müssen, ist der Vorteil und auch das Konzept schnell ausgebremst. Zudem sieht das Konzept von Serverless vor, dass die Funktionen zustandslos sind. Folglich sollten keine Daten in der Funktion gespeichert werden. Kurz gesagt: Serverless verlangt die Entkoppelung von Datenschicht und Geschäftslogik. Dies bringt auch große Vorteile für die heutige agile Art der Anwendungsentwicklung à la DevOps und Co. mit sich. Wenn es notwendig wird die Geschäftslogik zu ändern, kann ich einfach neue Funktionen schreiben und den Daten- bzw. Informationsfluss durch die neuen Funktionen leiten. Damit habe ich keinen negativen Einfluss auf das Datenschema, welches in traditionellen Anwendungen aus gutem Grund erzeugt wird. Eine Änderung in der Logik bedingt somit keine Änderung des Datenschemas. Ferner können einzelne Teile der Anwendung komplett ersetzt werden, ohne die gesamte Applikation ändern zu müssen. Diesem Konzept folgen auch Microservices. Zusammenfassend könnte man sagen, dass eine Entkoppelung der sich in Bewegung befindlichen Daten von der Geschäftslogik stattfindet. Außerdem sollen keine Daten in den Funktionen vorgehalten werden.

Lambda, Kapp und Co. - Hatten wir das nicht schon?

Doch hatten wir nicht genau diese Art des Umgangs mit Daten bereits vor Jahren schon einmal diskutiert? In der Welt der Big Data und Streaming-Anwendungen gibt es seit einigen Jahren die sogenannten Lambda- und Kappa-Architekturen.

Bei der einen Variante (Lambda) gibt es eine Geschwindigkeits- und eine Batch-Schicht. In der einen werden schnelle Datenströme verarbeitet und in der anderen nicht so zeitkritische Daten oder deutliche größere Datenmengen aus unterschiedlichsten Datenquellen. Bei der Kappa-Architektur wird sogar ganz auf die Batch-Layer verzichtet, wodurch oftmals eine komplette Neuberechnung der Daten notwendig werden kann. Bei den Serverless-Anwendungen kommen diese beiden altbekannten Architekturmuster zum Einsatz. Ob Lambda oder Kappa hängt davon ab, ob noch Data Analytics und komplexere Jobs beispielsweise mittels Machine Learning verarbeitet werden sollen. Beide Architekturen bedingen, die für die Serverless-Welt ebenso notwendige unidirektionale Verarbeitung der Daten, welche in einem Data Lake endet.

Empfehlungen

Haben Sie bereits eine Big Data Datenstrategie, ist es einfach die neuen Serverless-Anwendungen in diese Strategie zu integrieren bzw. die bestehende zu erweitern. Sollte noch keine vorhanden sein, so müssen sich Unternehmen darüber klar werden, ob in Zukunft auch Daten für länger laufende Analysen benötigt werden oder ob eine Prozessierung während der Laufzeit der Anwendung ausreicht. Wichtig ist es die Serverless-Funktionen zustandslos und leichtgewichtig zu halten, damit die Vorteile der Architektur ausgespielt werden können. Wird dieser Maxime Folge geleistet, steht der erfolgreichen Nutzung von Daten in Kombination mit Serverless-Funktionen nicht mehr viel im Weg. Die Daten fließen (Flüsse) dann ohne Probleme in den Data Lake (See) und eine agile Entwicklung benötigt keine komplexe Änderung der bestehenden Applikation (Dämme), um eine Änderung der Geschäftslogik durchzuführen.