Am Puls von Microsoft

Entwicklertagebuch MyLife #5: Noch mehr function-nierendes Azure

Entwicklertagebuch MyLife #5: Noch mehr function-nierendes Azure

Im letzten Beitrag begannen wir unsere MyLife.NET Reise in die Welt von Microsoft Azure und seitdem überlege ich, wie man die kostenfreien Dienste der Cloud weiter in MyLife.NET integrieren könnte. Durch einen tollen Kommentar auf LinkedIn von Jens kam die Idee auf, einmal Azure Functions auszuprobieren. Wie diese Evaluation lief, erfahrt ihr in diesem Tagebucheintrag.

Für alle, denen diese Artikelreihe noch unbekannt ist – das habt ihr bislang verpasst, könnt euch aber natürlich nachträglich einlesen:

Use-case: Zufälliger Spitzname

Keine Lust auf eine neue Technologie bringt etwas, wenn man nicht weiß, für was man diesen Einsätzen möchte und woran man sich an die neue Cloud-Welt herantasten kann. Deswegen habe ich für den Anfang den einfachen Use-case einer “Gibt mir einen zufälligen Spitznamen des Leben-Objekt“ entschieden.

Kurzum: Durch einen GET-Web-Request auf eine bestimmte URL soll ein zufällig ausgewählter Spitzname (“Nickname”) in einer JSON-Struktur zurückgegeben werden. Durch den Einsatz von „serverless computing“ muss man hierzu also keinen kompletten Server betreiben, sondern wirft der Cloud nur den Quelltext hin, welcher in genau diesem Falle ausgeführt werden soll.

Eine Azure Function erstellen

Um eine neue Funktion zu erstellen, reicht es in Visual Studio aus, ein entsprechendes weiteres Unterprojekt in der Solution zu erstellen. Microsoft bietet hierfür verschiedene Vorlagen an. Für diese Bastelei ist das Template “Azure Function mit HTTP-Trigger” jenes, welches für uns in Frage kommt. Das Projekt trägt den Namen MyLife.Azure.Functions (GitHub), da mehrere Funktionen innerhalb eines Projektes abgebildet werden können.

Dank der Möglichkeit, bereits erstellte Teilprojekte wie “MyLife.Core” einzubinden, stehen uns theoretisch alle Möglichkeiten offen, an unser digitales Leben zu kommen. Dies gestaltet die eigentliche Implementierung, wenn man einmal eine gute Solution-Struktur und Domain denken außen vor lässt, sehr einfach.

Die Implementierung

Je C#-Klasse eine Azure Function. Diese klare Aufteilung hält wohl auch in großen Projekten die Übersichtlichkeit am Leben und sorgt dafür, dass der Lebenszyklus einer Wolkenfunktion klar ersichtlich ist. Für unseren kleinen Use-case reicht hierfür die “Run(…)”-Methode aus.

In dieser lade ich von einem weiteren Endpunkt das JSON und gebe ein zufälliges Listenelement aus dem Datenfeld MyLife.Persona.Nicknames als Response zurück.

Die Ausführung

Hierbei muss man klar unterscheiden, ob man diese zu Entwicklungszwecken lokal startet oder es dann später in die Wolke geschoben wird. Lokal startet der Azure Functions Simulator, was sich anfühlt und auch aussieht wie eine moderne Terminal-Applikation – inklusive Localhost URLs zu jeder gestarteten Funktion. Diese lassen sich wie gewohnt aufrufen, was in unserem einfachen Fall einfach im Browser möglich ist.

Möchte man die Funktion in der Azure Cloud starten, beinhaltet Visual Studio einen Wizard, um über das gewohnte “Rechtsklick -> Publish”-Menü ein neues Deployment anzulegen und schlussendlich durchzuführen.

Im Endeffekt werden hierdurch automatisch Ressourcen in der hinterlegten Azure Umgebung aufgesetzt und das Function Projekt hochgeladen. Dies ist nicht die einzige Möglichkeit. Im Azure Portal an sich stehen weitere Varianten wie das Erstellen der benötigten Ressourcen sowie dem Deployment via GitHub oder gar das komplette Schreiben einer Function im Browser zur Verfügung.

Ich muss noch viel lernen

Die Komplexität mit dem, was ich mir mittlerweile in MyLife.NET aufgebaut habe, sorgt dafür, dass manche Lernkurven herausfordernder sind als andere. Plötzlich gibt es nicht nur neue Frameworks zu verstehen, sondern auch wie man zustandslose Sessions bespielen kann oder, im Falle von Azure, wie man einen brennenden Geldbeutel vermeidet.

Dies soll nicht negativ klingen. Ich sehe es als Herausforderung, welche die moderne Softwareentwicklung mit sich bringt. Außerdem zeigt dies auf, welche Möglichkeiten einem mit C# und dem .NET Ökosystem offen stehen.

Ein wirklicher Mehrwert fehlt

Auch wenn das Basteln in der Wolke Spaß bereitet, suche ich noch den wirklichen Mehrwert davon. Klar: Wäre MyLife.NET ein produktives Stück Software, würde es anders aussehen. Als Hobby und Feierabendbastelei bleibt es spannend zu sehen, wie sich hier die verschiedenen Azure Dienste gewinn- aber auch spaßbereitend einsetzen lassen

MyLife ist nicht Cloud-ready

Bei all dem Basteln fiel mir immer wieder auf, dass die aktuelle Struktur, wie MyLife.NET aufgebaut ist, nicht Cloud-ready ist. Allein der Ort, wo man sein eigenes Leben definieren kann und wie man schlussendlich in den verschiedenen Teilprojekten wie Blazor, MAUI oder nun Functions darauf zugreift, sprengt alle Grenzen des Domain Patterns und muss baldmöglichst angepasst werden. Die Vermischung aus “wann erstelle ich das Leben” und “wann lese ich es von einem Endpunkt” schränkte mich im Stateless Azure Functions Experiment stark ein.

Die Sorge vor Kosten bleibt

Es war mir trotz dem Studium der “Always free”-Sektion in der Dokumentation als auch den Preislisten nicht klar, ob, und falls ja, ab wann Azure Functions etwas kostet. Da mein Code nicht nur statisch ausgeführt, sondern auch JSON-Dateien von extern lädt, entsteht Datenverkehr, welcher meist nicht komplett kostenfrei zur Verfügung gestellt wird. Anders als bei den Azure Static Web Apps fand ich auch irgendwo den “Hobby”- beziehungsweise “Free”-Plan angeschrieben.

Für Experten in diesem Gebiet ist die Information hierüber wohl leicht zu finden, ich als Bastler tue mir schwer, hier eine für mich aufschlussreiche Aussage zu treffen. Aus diesem Grund habe ich die öffentlichen Deployments nach meinen Tests wieder gestoppt und alle Ressourcen sogar gelöscht. Der Schwabe in mir fand ansonsten kein ruhiger Schlaf um die Sorge einer glühenden Kreditkarte.

Wie geht es weiter?

Wie angesprochen muss die Struktur, wie die einzelnen Teilprojekte ineinandergreifen, verbessert werden, um in Zukunft eine bessere Trennung zwischen dem Erstellen und dem Konsumieren der MyLife Datenquellen zu gewährleisten. Es bleibt auch die Frage, ob beispielsweise die erstellte JSON-Datei der Quell aller Informationen ist oder ob dies das erstellte C#-Objekt sein sollte. Falls letzteres, wo lebt dieses, wie greifen andere Teilprojekte darauf zu und wie macht alles eigentlich überhaupt Sinn? Viele offene Fragen, welche beantwortet werden wollen.

Bevor ich diesen Brocken angehe, wird wohl allerdings erst der Startschuss für die MAUI-App fallen – einfach, weil ich zurzeit auf dieses Thema mehr Lust habe und dank dem Umstand, dass dies ein Feierabend- und Bastelprojekt ist, ich mir die Aufgaben so priorisieren kann, wie ich es gern möchte. Ach, wie schön.

Ihr habt Lust mitzuwirken?

Falls ihr euch beteiligen wollt, weil ihr mir zeigen wollt, wie etwas richtig oder einfacher geht, oder ihr euch zum ersten Mal an einer noch übersichtlichen .NET-Solution beteiligen wollt, seid ihr herzlich eingeladen, auf GitHub vorbeizusehen, das Repository zu forken, Issues mit Problemen oder Hinweisen zu eröffnen oder einfach zu stöbern. Wir alle sind hier, um zu lernen und, noch wichtiger, um Spaß an der Softwareentwicklung zu haben!

Artikel im Forum diskutieren (0)

Über den Autor

Tobias Scholze

Tobias Scholze

Bayrischer Open Source- und Community-Enthusiast, Verfechter des neuen Microsoft und Wandler zwischen den Betriebssystemwelten. #communityrocks Von Herzen ein Nerd mit der festen Überzeugung, dass man gemeinsam und durch den Einsatz von moderner IT die Welt für jeden ein Stückchen besser machen kann.

Anzeige
Anzeige