Die Cloud ist das neue Framework

Um die Idee, die in diesem Beitrag transportiert werden soll, besser zu veranschaulichen, betrachten wir folgende Beispielanwendung: Es soll ein System entwickelt werden, welches möglichst performant Bilder entgegen nimmt und eine Reihe von Filtern und Transformationen auf diese Bilder anwendet, um schließlich das Ergebnis final abzuspeichern. Solche Verarbeitungsstrecken finden wir heutzutage häufig im Kontext von Redaktionssystemen, Stock-Fotografie, Online-Shops, medizinische Bildbearbeitung und vielen anderen.

Setzen wir uns für einen Moment unsere monolithische Mütze auf. Wie würden wir das o.g. System umsetzen, wenn wir "nur" einen dedizierten Server, eine high-level Programmiersprache und vielleicht noch einen Applikationsserver zur Verfügung hätten? Ein erster Gedanke könnte sein, die Bildbearbeitungs-Strecken zu parallelisieren. Das Mittel der Wahl wären Threads, die im Kontext des Applikationsservers laufen. Da wir einen Server mit endlichen Ressourcen haben, müssten wir womöglich Bilder bzw. deren Strecken-Threads in eine Queue puffern, da mehr Bilder eingehen könnten, als das System selbst bei hoher Parallelität abarbeiten kann. Weiter müsste die Anzahl der parallelen Threads ebenfalls beschränkt werden, um in Sachen CPU und Speicher-Auslastung die Server-Grenzen nicht zu überschreiten. Da es trotzdem passieren kann, dass eine Bearbeitungsstrecke während der Ausführung abbricht, müssten Mechanismen implementiert werden, die ggf. den erzeugten Zwischenstatus aufräumen.

Selbstverständlich kann man die Überlegungen zu dem skizziertem System auf architektureller Ebene immer weiter verfeinern, für unser Beispiel reicht diese Detailtiefe allerdings bereits aus. Würden wir so ein System als Monolithen implementieren, würden wir vielleicht den Code grob in zwei Aufgabenbereiche unterteilen, und zwar in Framework und Anwendung. Diese Unterteilung war damals gar nicht so unüblich. Als Anwendung würde man den Code bezeichnen, der die fachlichen Anforderungen abbildet, etwa Parameter der Transformationen wie Bildgrößen, Kompressionsraten, Reihenfolge der Transformationen, usw. Die eigentlichen Transformationen sowie deren Verwaltung wären eher ein Bestandteil des Frameworks.

Mit anderen Worten, wir müssten das Framework und das auf das Framework aufbauende Programm entwickeln.

Nun katapultieren wir uns gedanklich ins Cloud- und Microservices-Zeitalter. Wie würden wir so ein System heute umsetzen? Eine mögliche Umsetzung könnte als eine orchestrierte Abfolge von serverless Funktionen, die jeweils einen Bildbearbeitungsschritt umsetzen, erstellt werden. Die Queue, die eingehende Bilder puffert, wäre eine native Queue des jeweiligen Cloud-Anbieters. Die parallele Verarbeitung wäre durch die implizite Skalierung von FaaS (Function as a Service) Clouds bereits abgedeckt. Plattenplatz steht in Form von Buckets quasi unbegrenzt zur Verfügung. Einzig die Themen RAM und Dauer der Verarbeitung sind Variablen, die in einem solchen System tatsächlich begrenzt sind. Damit beschäftigen wir uns in einem zukünftigen Beitrag. Für unser Thema in diesem Beitrag ist es nur wichtig zu erkennen, dass im Gegensatz zum Monolithen, das Framework immer noch da ist. Funktional hat sich dieses nicht wesentlich verändert - die Architekturen sind sich auf den ersten Blick sehr ähnlich. Der große Unterschied besteht aber darin, dass das Framework in der zeitgenössischen Variante vollständig in die Cloud gewandert ist.

Heißt das, dass wir das Framework heute nicht mehr entwickeln müssten? Ja und nein. Wir müssten, genauso wie bei der monolithischen Variante, die eingehenden Bilder puffern, auf parallele Verarbeitung zur Performance-Steigerung setzen, Grenzen für die Ressourcen-Nutzung festlegen usw. Der Unterschied besteht darin, dass anstatt das Framework selber zu programmieren, wir diesen eher deklarativ mit einem Tool wie bspw. terraform beschreiben würden. Tatsächlicher Code wäre "nur" noch in Form von bspw. serverless Funktionen, die jeweils eine Transformation implementieren, und die deklarativ zu einer Strecke konfiguriert werden können.

Dadurch findet eine Verschiebung der Verantwortlichkeiten statt, mit dem Ergebnis, dass wir uns noch stärker auf die rein fachlichen Aufgaben konzentrieren können.