© best_vector/Shutterstock.com
Windows Developer
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.

Rainer Stropek


Architektur und ProgrammiermodellEvent-driven ArchitectureListing 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")][return: ServiceBus("plate-read", Connection = "SECCTRL_SEND_PLATE_READ", EntityType = EntityType.Topic)]public async Task Run( [BlobTrigger("car-images/cameras/{camera}/{name}", Connection = "SECCTRL_CAR_IMAGES")]CloudBlockBlob imageBlob, string camera, string name, ILogger log){ ... }[FunctionName("ProcessCarImage")][return: ServiceBus("plate-read", Connection = "SECCTRL_SEND_PLATE_READ", EntityType = EntityType.Topic)]public async Task Run( [BlobTrigger("car-images/cameras/{camera}/{name}", Connection = "SECCTRL_CAR_IMAGES")]CloudBlockBlob imageBlob, string camera, string name, ILogger log){ ... } Die Zusammenhänge sind durch die lose Kopplung weniger offensichtlich. Es ist schwierig, sich in eine komplexe Anwendung, die nur als Sammlung lose gekoppelter Functions vorliegt, einzuarbeiten. Fehlersuche (z. B. Debugging, Analyse von Traces) ist aufwendiger und setzt in der Praxis spezielle Monitoringkomponenten wie Azure Application Insights oder Jaeger [1] voraus. Durch lose Kopplung mit Hilfe eines Message Broker sind Verarbeitungsschritte von Haus aus asynchron. Innerhalb eines C#-Programms steht mit async/await ein Werkzeug zur Verfügung, das asynchrone Programmierung drastisch vereinfacht. Über lose gekoppelte Functions hinweg funktioniert dieser Mechanismus aber nicht mehr. Die Gesamtlogik wird schwieriger zu schreiben, schwerer zu verstehen und dadurch fehleranfälliger. Für die Authentifizierung zwischen den Microservices müssen neue Strategien gefunden und erlernt werden. Die aus ASP.NET gewohnten Middleware-Pipelines, z. B. für die Validierung von OpenID-Connect-Tokens im HTTP-Header, gibt es in dieser Form nicht. Serverless Functions setzen eine hochentwickelte Basisinfrastruktur wie die von Azure voraus. Wer auf eine Public-Cloud wie Azure verzichten will, braucht lokal ein entsprechend konfiguriertes Kubernetes-C...

Windows Developer
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.

Rainer Stropek


Architektur und ProgrammiermodellEvent-driven ArchitectureListing 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")][return: ServiceBus("plate-read", Connection = "SECCTRL_SEND_PLATE_READ", EntityType = EntityType.Topic)]public async Task Run( [BlobTrigger("car-images/cameras/{camera}/{name}", Connection = "SECCTRL_CAR_IMAGES")]CloudBlockBlob imageBlob, string camera, string name, ILogger log){ ... }[FunctionName("ProcessCarImage")][return: ServiceBus("plate-read", Connection = "SECCTRL_SEND_PLATE_READ", EntityType = EntityType.Topic)]public async Task Run( [BlobTrigger("car-images/cameras/{camera}/{name}", Connection = "SECCTRL_CAR_IMAGES")]CloudBlockBlob imageBlob, string camera, string name, ILogger log){ ... } Die Zusammenhänge sind durch die lose Kopplung weniger offensichtlich. Es ist schwierig, sich in eine komplexe Anwendung, die nur als Sammlung lose gekoppelter Functions vorliegt, einzuarbeiten. Fehlersuche (z. B. Debugging, Analyse von Traces) ist aufwendiger und setzt in der Praxis spezielle Monitoringkomponenten wie Azure Application Insights oder Jaeger [1] voraus. Durch lose Kopplung mit Hilfe eines Message Broker sind Verarbeitungsschritte von Haus aus asynchron. Innerhalb eines C#-Programms steht mit async/await ein Werkzeug zur Verfügung, das asynchrone Programmierung drastisch vereinfacht. Über lose gekoppelte Functions hinweg funktioniert dieser Mechanismus aber nicht mehr. Die Gesamtlogik wird schwieriger zu schreiben, schwerer zu verstehen und dadurch fehleranfälliger. Für die Authentifizierung zwischen den Microservices müssen neue Strategien gefunden und erlernt werden. Die aus ASP.NET gewohnten Middleware-Pipelines, z. B. für die Validierung von OpenID-Connect-Tokens im HTTP-Header, gibt es in dieser Form nicht. Serverless Functions setzen eine hochentwickelte Basisinfrastruktur wie die von Azure voraus. Wer auf eine Public-Cloud wie Azure verzichten will, braucht lokal ein entsprechend konfiguriertes Kubernetes-C...

Neugierig geworden?


    
Loading...

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