© best_vector/Shutterstock.com
Missverstandene Azure Functions – warum sie weit mehr als nur Serverless sind

Kolumne: Stropek as a Service


Serverless ist ein heißes Thema im Bereich Cloud-Computing. Entwicklungsteams können sich damit mehr auf ihre Kernaufgaben konzentrieren und machen sich noch weniger Gedanken über Server, als das schon bei Platform as a Service (PaaS) der Fall ist. Wenn man nach Serverless in der Microsoft-Azure-Cloud fragt, werden üblicherweise als erstes Azure Functions genannt. Sie kommen dem Versprechen, Server gedanklich außen vor lassen zu können, am nächsten. Bei meiner Arbeit mit Kunden, die in Richtung Cloud-Computing und im Speziellen in Richtung Azure gehen wollen, merke ich aber häufig, dass Azure Functions missverstanden werden. Sie sind weit mehr als nur die Serverless-Variante von Web-APIs.

Architektur und Programmiermodell

Wer sich für Azure Functions entscheidet, entscheidet sich nicht zwangsläufig für Serverless. Functions lassen sich in Azure auch in klassischen PaaS-App-Services betreiben. Eine Entscheidung für Functions bedeutet aber, sich auf Event-getriebene Softwarearchitektur einzulassen. Man muss außerdem bereit sein, auf viele der aus ASP.NET bekannten Mechanismen, wie z. B. Middleware-Pipelines, zu verzichten. Das Programmiermodell von Functions ist ein anderes als das von ASP.NET.

Event-driven Architecture

Die aus meiner Sicht wichtigste Änderung durch Functions ist, dass Anwendungsteile nicht mehr eng durch Funktionsaufrufe, sondern lose durch Events miteinander verknüpft sind. Eine Function kann beispielsweise über einen eingehenden HTTP Request ausgelöst (triggered) werden. Neben einer Antwort in Form einer HTTP Response signalisiert sie ein Event beispielsweise durch das Versenden einer Nachricht über einen Message Broker wie Azure Service Bus oder Event Grid. Darauf reagieren weitere Functions, die wiederum zu neuen Events führen. Events werden nicht immer explizit, sondern häufig auch implizit ausgelöst, indem man beispielsweise etwas in der Azure CosmosDB oder im Blob Storage speichert.

Listing 1 zeigt exemplarisch, wie das Functions-Programmiermodell in C# aussieht. Trigger und Bindings werden durch Attribute im Code festgelegt. Eine solche Function könnte bei einer Kennzeichenerkennungslösung eingesetzt werden. Die Function wird bei Upload eines Kamerabildes in den Blob Storage aktiviert, als Ergebnis erzeugt sie eine Nachricht in einem Topic im Service Bus. Nachgelagerte Funktionen könnten sich um die Prüfung der Durchschnittsgeschwindigkeit, des Vorhandenseins einer Vignette etc. kümmern.

Listing 1

[FunctionName("ProcessCarImage")]...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang