Interview 28.09.2021, 16:00 Uhr

"Container sind nicht in jedem Fall der einzige oder beste Weg."

Stateless, Statefull und Durable: Um zu klären, was es mit diesen Eigenschaften von Cloud-Funktionen auf sich hat, sprach dotnetpro mit Damir Dobric, Chefarchitekt von daenet, der zudem gerade seine PhD-Dissertation über Künstliche Intelligenz schreibt.
(Quelle: Damir Dobric)
Auf der .NET Developer Conference (DDC '21), die vom 29. November bis zum 3. Dezember digital stattfindet, hält Damir eine vierstündige DevSession zum Thema "Modern Serverless Applications with Azure Durable Functions, ACI and Docker". Als Experte für Microsoft Azure haben wir Damir befragt, was es mit diesen Begriffen auf sich hat.

Was genau sind Durable Functions?

Damir Dobric: Durable Functions sind ein Serverless-Dienst in der Microsoft Azure Cloud, der die einfache Implementierung von Statefull, Long-Running Services bietet, also langlaufenden Prozessen, die ihren Zustand nicht vergessen. Die meisten Dienste heute sind Stateless, also zustandslos konzipiert - wie zum Beispiel ein REST Webservice, der von einer App oder Web-Anwendung verwendet wird. Solche Abfragen sind als Request-Response bekannt, werden in einem zustandlosen Dienst schnell verarbeitet und halten typischerweise den Zustand in einer Datenbank.
Manche Anforderungen lassen sich leider mit dieser Vorgehensweise nicht implementieren. Manchmal dauert die Verarbeitung einer Anfrage sehr lange wie zum Beispiel bei einem Human Workflow, der von mehreren Personen systemübergreifend verarbeitet werden soll. Um solche Szenarien zu vereinfachen, bietet Microsoft eine Erweiterung von Azure Functions, nämlich Durable Functions an.
In diesem Zusammenhang muss noch etwas erwähnt werden. Die Technologie der Durable Functions bietet sogenannte Durable Entities an. Dabei handelt es sich um eine Serverless-Implementierung eines Actor Programming Models.

Muss ich denn, wenn ich Serverless Functions nutzen will, mit Containern arbeiten oder kann ich den Code beispielsweise auch über ein gewöhnliches Deployment in Azure laden und ausführen lassen?

Damir: Grundsätzlich sollte man sich beim Konzipieren einer Lösung von der darunterliegenden Infrastruktur befreien. Das heißt, man muss zuerst die Entscheidung treffen, ob man die Lösung als Stateless oder Statefull implementieren soll. Da es sich in diesem Fall um ein Statefull- und Long-Running-Szenario handelt, sucht man sich dafür die passende Plattform. Um diese zu realisieren, könnte man das Durable Task Framework [1] verwenden und alles selbst On-Prem oder in irgendeiner Cloud betreiben. Microsoft hat dieses Framework in die Azure Functions integriert, um eine einfachere Entwicklung und einen einfacheren Betrieb zu ermöglichen.
Wenn man sich für Durable Functions entscheidet, kann zum Beispiel die in .NET implementierte Anwendung ganz gewöhnlich ohne Docker installiert und betrieben werden. Aufgrund der Popularität von Docker wird häufig die Lösung im allgemeinen als Docker Container betrieben. Um dies zu ermöglichen, bietet Microsoft im Rahmen von Durable Functions die Option eines Docker Containers als Host an.

Ist nicht der zeitliche Overhead/die Turnaround-Zeiten mit Kompilieren, Container bauen, Hochladen und Testen sehr groß?

Damir: Absolut. Das ist ein großer Overhead. Docker und Container sind definitiv eine wichtige Technologie, die in der Welt von Cloud und Multicloud fast unverzichtbar sind. Es ist aber falsch zu denken, dass dies der einzige und beste Weg wäre, eine Anwendung zu betreiben. Das Verpacken einer Anwendung in Container ist häufig keine einfache Angelegenheit. Ich persönlich mag diesen Overhead nicht, weil es keine wirklich kreative Aufgabe ist und sie Zeit und Geld kostet.
Wenn aber die Anforderung lautet, einen Container zu liefern, ist Docker vermutlich die beste Wahl. Ich sehe aber häufig in den Projekten, dass Container unnötig verwendet werden. Wenn man beispielsweise eine Anwendung im AppService betreibt (zum Beispiel eine Azure Function), ist die Verwendung von Docker nicht unbedingt in allen Szenarien die bessere Wahl. Ich stelle aber fest, dass diese dennoch verwendet werden, weil man denkt, es wäre die bessere Lösung.

Wie kann mich die Cloud über eventuelle Fehler im Code informieren?

Damir: Das hängt in der Regel vom jeweiligen Service- und Cloud-Anbieter ab. Azure bietet hierzu vieles an, zum Beispiel einen Health-Mechanismus, der im Hintergrund nach Fehlern sucht, die Dienste im Falle eines Fehlers neu startet oder diese komplett auf nicht defekter Hardware installiert, ohne dass man involviert wird. Die Azure Plattform bietet ebenso verschiedene Logging-Mechanismen an wie zum Beispiel Live-Stream, Persisted Log File im Storage oder sogar Azure Insights.

Langlaufende Funktionen sind gerade im Web-Umfeld eher ungeliebt. Wie sieht das bei Serverless aus?

Damir: Das ist korrekt. Web ist Stateless und verarbeitet die Anfragen sehr schnell (Request-Response). Langlaufende Funktionen sind etwas anderes. In Azure kann man diese jedoch auch mit anderen Mitteln ohne Durable Functions umsetzen – zum Beispiel mit Azure Web Jobs, Azure Batch oder Azure Container Instances.

Für welche Anwendungen oder besser, für welche Einsatzszenarien würdest du Serverless Applications empfehlen?

Damir: Es gibt dafür keine goldene Formel. Die Frage kann ich nur aus meiner Projekterfahrung beantworten. Wenn man eine komplexe Anwendung implementiert, würde ich nicht den Serverless-Weg gehen. Serverless Applications bieten sich sehr gut für Integrationsszenarien zwischen verschiedenen Systemen an.

Sind auch hybride Applikationen denkbar: Ein Teil auf einem Client oder Server im Unternehmen, ein Teil als Serverless Application in der Cloud?

Damir: Das ist genau der richtige Weg. Häufig hat man in den Projekten die Anforderung, eine Komponente getrennt vom restlichen System zu implementieren. Solche einfacheren Anforderungen brauchen aber genau die Infrastruktur wie der Rest der Anwendung. Gerade in solchen Fällen ist Serverless extrem hilfreich. Man bringt die Funktionalität in eine bereits existierende, mächtige und günstige Infrastruktur ein.

Welche Voraussetzungen sollte das Entwicklungsteam erfüllen, um diese Funktionen einsetzen zu können?

Damir: Das Schöne daran ist, dass fast keine zusätzlichen Anforderungen nötig sind. Allerdings, die Betonung liegt auf zusätzliche. Wenn das Team sich mit Statefull und Long-Running gut auskennt, ist die Verwendung von Azure Functions sehr einfach. Ich muss aber feststellen, dass die meisten Teams sich erfahrungsgemäß mit diesen Themen nicht gut auskennen. Wenn Ihnen die Begriffe wie Distributed Lock, Actor Model, Partitioning, Orchestration, Persistence und so weiter gut bekannt sind, wird für Sie der Einsatz von Azure Durable Functions eine Selbstverständlichkeit sein. Alle anderen sollten sich mit der Thematik erst einmal intensiv auseinandersetzen, um entscheiden zu können, ob der Einsatz einer Durable-Technologie überhaupt die eigentliche Anforderung lösen kann.

Momentan schreibst du an deiner Dissertation für den PhD. Es geht um irgendwas mit Künstlicher Intelligenz. Magst du Genaueres verraten?

Damir: Sehr gerne. Vereinfacht ausgedrückt erforsche ich die Intelligenz. Das hört sich etwas seltsam oder nahezu unmöglich an. Ich lese sehr viele Publikationen aus dem Bereich Neural Sciences oder Psychologie und so weiter. Die Wissenschaft hat ein Jahrhundert lang in diesen Gebieten viele Experimente durchgeführt. Es besteht dadurch eine fundierte Basis an verwertbaren Informationen.
Das Thema KI haben sich die Mathematiker auf die Fahne geschrieben. Wir haben zahlreichen Algorithmen entdeckt, die fähig sind zu lernen. Das macht diese aber noch lange nicht zu intelligenten Algorithmen. Basierend auf Ideen vom Hierarchical Temporal Memory habe ich ein Framework in .NET Core unter dem Namen NeoCortexAPI [2] entwickelt. Dieses Open-Source-Projekt enthält alle Forschungsergebnisse in Form eines .NET API.
Stellt euch einen Algorithmus vor, der in der Lage ist, Bilder oder Sequenzen zu erlernen und ähnliche Dinge zu erkennen. Der robust gegen Fehler agieren kann und so weiter. Ist dies nicht dem sehr ähnlich, wie unser Gehirn funktioniert? Kein Supervised Learning, kein Unsupervised Learning, kein Clustering und fast keine Mathe.
Ich forsche in diesem Gebiet und habe eine der ersten Implementierungen überhaupt in C# gemacht. Einmal etwas anderes als Python.
Für eine von meinen Publikationen erhielt ich in diesem Jahr den Best Industrial Paper Award. In dieser Publikation habe ich gezeigt, warum es wichtig ist, dass ein Algorithmus, genau wie ein Gehirn eine Neugeborenen-Phase durchlaufen muss. Einen bestehenden Teil eines Algorithmus habe ich erweitert und somit ermöglicht, dass sich der Algorithmus am Anfang wie ein Baby verhält. Nachdem diese Phase abgelaufen war, waren die finalen Ergebnisse perfekt. Ein Algorithmus, der diese Phase nicht durchläuft, leidet später an Vergesslichkeit.
Also, es handelt sich um die Grundlagen Forschung der wahren Intelligenz. Viele Stimmen in der Community [3][4] gehen davon aus, dass diese Art von Algorithmen die nächste KI wird.

Derzeit hat man das Gefühl, dass viele Firmen KI ausprobieren, aber die Einsatzgebiete dann doch sehr begrenzt sind. Wie siehst du das?

Damir: Das stimmt. Es ist wie bei jeder anderen Technologie. Beispiel Blockchain. Blockchain ist eine tolle Technologie mit faszinierenden Möglichkeiten. Aber die Einsatzmöglichkeiten sind sehr eingeschränkt. So ist es auch mit KI. KI ist eine sehr vielschichtige und vielseitige Technologie. Wenn man eine Lösung beherrscht wie zum Beispiel die Wettervorhersage, heißt es noch lange nicht, dass man Experte für Image Recognition ist. In unseren Entwicklerwelten geht es meistens um das Anwenden von bestehenden Algorithmen. Das Schöne an dieser sog. Demokratisierung ist, dass die Entwickler die Algorithmen anwenden können. Da hat Microsoft wirklich einen guten Job mit ML.NET und den Cognitive Services gemacht.
Man muss keinen PhD in KI haben und man kann trotzdem relativ einfach wirklich gute und funktionierende KI-Lösungen bauen. Aber, wie bereits erwähnt, nicht jede Lösung braucht KI. Die meiste Lösungen brauchen KI - falls überhaupt - als ein ergänzendes Feature. Hier möchte ich auf ein Interview hinweisen, das ich mit Microsoft geführt habe [5].

Mit dem im Hinterkopf: Kannst du ein bisschen Orakel spielen und sagen, was wir in fünf Jahren zu erwarten haben?

Damir: Irgendwann wird das Marketing für die Künstliche Intelligenz verblassen. Wenn das passiert, wird KI als eine Selbstverständlichkeit eingesetzt werden. Ich bin zuversichtlich, dass wir bald Algorithmen haben werden, die sich in einem abgespeckten Kontext wirklich intelligent verhalten. Ich bin mir auch sicher, dass wir sobald keinen Terminator haben werden. Eine intelligente Maschine zu haben heißt nicht, eine Maschine mit einem Willen zu haben. Durch Unwissen vermischen wir in der Gesellschaft die Begriffe Intelligenz, Emotionen, Bewusstsein oder sogar Geist miteinander.

Sollten sich Entwickler also mit KI auseinandersetzen?

Damir: Ich persönlich beschäftige mich mit fast allen Technologien, die mir wichtig und fundiert erscheinen. Aus diesem Gesichtspunkt würde ich die Frage mit Ja beantworten. Auch wenn man KI nicht verwendet oder braucht, sollte man darüber etwas wissen. Ansonsten entsteht eine Entwicklerbildungslücke. Ich würde jedem Entwickler empfehlen, irgendein Sample aus ML.NET durchzuspielen, damit man das Gefühlt bekommt, wie eine solche Lösung funktioniert. Ein Wochenende würde dafür ausreichen.

Publikationen:

Artikel drucken
Das könnte Sie auch interessieren
SoftwareOne
Ausbau von KI-, Datenmanagement- und Analyselösungen
 
22.02.2024
Kubermatic
Ausblicke zu Cloud Native und Kubernetes
 
17.01.2024
Teradata
Vorschau von Teradata AI Unlimited auf AWS verfügbar
 
07.12.2023
Cloudflare
Mistral KI für Cloudflare Workers
 
23.11.2023