Das heutige Thema ist eines, von dem fast jeder schon einmal gehört hat, das aber kaum jemand erklären kann. Serverless. Was genau ist das? Ist es wirklich nur Code, der auf nichts läuft, oder ist es etwas viel Größeres? Es bedeutet, dass man sich keine Gedanken über sie macht, und diese Unterscheidung verändert die Art und Weise, wie man Software entwickelt, grundlegend. Am Ende dieser Folge wirst du verstehen, was Azure Functions eigentlich ist, wie die Preisgestaltung wirklich funktioniert und wann du sie verwenden solltest. Wir werden das Ganze in seine einzelnen Bausteine aufschlüsseln und mit dem größten Mythos beginnen. Was Serverless eigentlich bedeutet? Lassen Sie uns gleich ein paar Mythen aufklären. Der Begriff Serverless ist der schlechteste Marketingbegriff, den sich Microsoft hier ausgedacht hat. Er suggeriert den Leuten, dass buchstäblich keine Server im Spiel sind. Das stimmt nicht. Es gibt Server jede Menge. Man muss sie nur nie anfassen. Vor 20 Jahren musste man viel Arbeit investieren, um einen Code im Internet auszuführen. Sie würden eine virtuelle Maschine mieten, ein Betriebssystem installieren, einen Webserver konfigurieren und ihre Anwendung bereitstellen. Dann würden sie jedes Wochenende damit verbringen, Sicherheitsupdates zu patchen und sicherzustellen, dass das Ding nicht um drei Morgens abstürzt. Und hier ist der Clou. Sie haben für diesen Server bezahlt, unabhängig davon, ob ihr Code lief oder nicht. Er stand einfach da und brummte vor sich hin und verbrannte Geld, während sie schlug. Serverless stellt dieses gesamte Modell auf den Kopf. Sie schreiben ihren Code, laden ihn hoch und die Plattform kümmert sich um alles Weitere. Das Betriebssystem, die Sicherheitspatches, die Skalierung und die Verfügbarkeit. Ihre Aufgabe steht nur darin, die wichtige Logik zu schreiben. Stellen Sie sich das wie den Unterschied zwischen dem Betrieb einer Restaurantküche und der Nutzung eines Verkaufsautomaten vor. Eine Restaurantküche benötigt volles Personal, ständige Versorgung und Wartung. Sie kostet jeden Tag Geld, selbst wenn niemand durch die Tür kommt. Ein Verkaufsautomat steht einfach in der Ecke und tut nichts, bis jemand einen Knopf drückt. Dann erwacht er zum Leben, erledigt seine Arbeit und geht wieder in den Ruhezustand. Sie zahlen nur für den Strom, wenn er tatsächlich funktioniert. Das ist Serverless in aller Kürze. Azure Functions ist die Version von Microsoft. Sie führt kleine Codestücke als Reaktion auf Ereignisse aus. Ihr Code ruht, bis er durch etwas aktiviert wird. Dann wird er ausgeführt beendet und wechselt wieder in den Ruhezustand. Wie sieht dieser Code nun konkret aus? Was sind Azure Functions? Eine Funktion ist ein einzelner Code-Ausschnitt, der eine bestimmte Aufgabe ausführt. Es handelt sich nicht um eine komplette Anwendung mit einer Anmeldeseite einer Datenbank und 20 Bildschirten. Es handelt sich um eine einzelne fokussierte Aufgabe. Stellen Sie sich das wie ein Lichtschalter in Ihrem Haus vor, der entweder ausgeschaltet ist, um zu funktionieren, und dann wieder ausgeschaltet wird. Ein herkömmlicher Webservice ist das Gegenteil. Er lässt beispielsweise alle Lichter in Ihrem Haus 24 Stunden am Tag, 7 Tage die Woche an, selbst wenn niemand zu Hause ist. Azure Functions unterstützt eine Reihe verschiedener Programmiersprachen. Sie können jede Sprache verwenden, mit der Sie vertraut sind. JavaScript, Python, C, Java oder PowerShell. Hier gibt es keine richtige Antwort. Wählen Sie die Sprache, mit der Sie bereits verdranken. Nun wollen wir eine häufige Verwirrung ausräumen. Eine Funktions-App ist nicht dasselbe wie eine Funktion. Die Funktions-App ist der Container. Stellen Sie sich wie eine Toolbox. Sie erstellen eine Funktions-App und fügen dieser Toolbox mehrere Funktionen zu. Jede Funktion ist ein separates Tool, das eine eigene Aufgabe führt. Sie können eine Funktion haben, die Benutzeranmeldungen verarbeitet, eine andere, die hochgeladene Bilder verarbeitet, und eine dritte, die nächtliche Berichte sendet. Sie alle befinden sich in derselben Toolbox, aber unabhängig von anderen. Noch ein wichtiger Punkt zu Funktionen. Sie sind standardmäßig zustandslos. Das bedeutet, dass Sie sich zwischen den Ausführungen nichts merken. Wenn Ihre Funktion eine Datei verarbeitet und abgeschlossen ist, ist das erledigt. Bei der nächsten Ausführung wird sie neu gestartet, ohne sich an die letzte Ausführung. Das klingt nach einer Einschränkung, ist aber genau das Feature, das Sie so leistungsstark macht. Da Funktionen keinen Arbeitsspeicher oder Zustand speichern, kann Azure bei Datenverkehrsspitzen sofort 100 Kopien Ihrer Funktion hochfahren und sie genauso schnell wieder herunterfahren, wenn der Datenverkehr abnimmt. So erhalten Sie Skalierbarkeit, ohne für ungenutzte Server zu bezahlen. Hier stellt sich die Frage, wenn eine Funktion einfach nur da sitzt und nichts tut, bis sie durch etwas aufgeweckt wird, was weckt sie denn eigentlich auf? Wir kommen Trigger ins Spiel. Trigger, das Wann. Jede Funktion muss genau einen Trigger haben und das ist nicht optional. Der Trigger ist das Ereignis, das Deine Funktion aufweckt. Ohne ihn sitzt Dein Code einfach nur da und tut absolut nichts. Stell Dir Trigger wie eine Türklingel vor. Deine Funktion wartet im Haus. Sie könnte ewig warten. Es passiert nichts, bis jemand an der Tür klingelt. Dann wird die Funktion aktiv, öffnet die Tür, erledigt ihre Arbeit und wartet wieder. Es gibt vier Trigger, auf die Anfänger am häufigsten stoßen. Der HTTP Trigger ist der häufigste Ausgangspunkt. Jemand besucht eine URL oder tätigt einen API-Aufruf und Deine Funktion wird ausgelöst. Auf diese Weise erstellst Du schlanke APIs, ohne einen ganzen Web-Server einzurichten. Dann gibt es noch den Timer Trigger, der nach einem Zeitplan ausgeführt wird. Du legst einen Kronausdruck fest, etwa jede Stunde ausführen oder jede Nacht um Mitternacht ausführen und Deine Funktion wird genau zu diesen Zeiten ausgelöst. Perfekt für Wartungsaufgaben, Bereinigungsaufträge oder das Generieren von nächtlichen Berichten. Der Blob-Trigger wird ausgelöst, wenn eine Datei in den Azure-Speicher hochgeladen wird. Angenommen, jemand lädt eine PDF-Datei in einem bestimmten Ordner hoch. Der Blob-Trigger erkennt diesen Upload und führt ihre Funktion automatisch aus. Dies ist von großer Bedeutung für die Bildverarbeitung, Dokumentkonvertierung und Dateiüberprüfung. Der Warteschlang-Trigger wird ausgelöst, wenn eine Nachricht in einer Warteschlange. Warteschlangen sind eine Möglichkeit, verschiedene Teile Ihres Systems zu entkommen. Ein Dienst stellt eine Nachricht in eine Warteschlange und ihre Funktion ruft sie ab und verarbeitet sie, sobald sie bereit ist. Dadurch wird verhindert, dass ein langsamer Dienst alles andere blockiert. Das ist der entscheidende Punkt. Wenn ein Trigger ausgelöst wird, übergibt er automatisch Daten an ihre Funktionen. Sie müssen diese nicht abfragen oder prüfen, ob etwas passiert ist. Der Trigger übergibt Ihnen alles, was Sie benötigen und Ihre Funktion verarbeitet es einfach. Eine Funktion ohne Trigger ist einfach nur Code, der herumliegt und nichts tut. Der Trigger gibt Ihren Zweck. Der Trigger teilt Ihre Funktion also mit, wann sie ausgeführt werden sollen. Aber woher kommen die Daten und wo werden sie hingeschickt? Hier kommen Bindungen ins Spiel. Bindungen, Daten rein, Daten raus. Bindungen sind eine Möglichkeit, deiner Funktion mitzuteilen, welche Daten sie lesen und wohin die Ergebnisse gesendet werden sollen und dass du dafür zusätzlichen Code schreiben musst. Das ist ganz schön viel, deshalb möchte ich es hier vereinfacht. Es gibt zwei Typen. Eingabebindungen bringen Daten in deine Funktion. Ausgabebindungen senden Daten raus. Ohne Bindungen müsstest du jedes Mal SDK-Code schreiben, wenn du mit einem Speicherkonto, einer Datenbank oder einer Warteschlange kommunizieren möchtest. Du müsstest Verbindungszeichenfolgen verarbeiten, Wiederholungsversuche verwalten, Daten serialisieren und Antworten deserialisieren. Das sind eine Menge Boilerplate-Coden, um eine Datei zu lesen. Mit Bindungen deklarierst du einfach, was du benötigst. Du sagst, ich möchte aus diesem Block-Container lesen oder ich möchte in diese Warteschlange schreiben. Die Runtime kümmert sich um den Rest. Sie öffnet die Verbindung, liest die Daten und übergibt sie als Parameter an deine Funktion. Wenn deine Funktion abgeschlossen ist, übernimmt sie den Rückgabewert und schreibt ihn an die von dir angegebene Stelle. Stelle dir Bindungen wie Pipes vor. Sie verbinden ihre Funktion mit einem Speicherkonto, einer Datenbank und einer Warteschlange. Die Daten fließen automatisch durch diese Pipes. Ihre Funktion muss nicht wissen, wie die Pipes funktionieren. Sie empfängt lediglich die eingehenden Daten und sendet die Daten, die ausgegeben werden. Hier ist ein konkretes Beispiel. Angenommen, Sie verfügen über eine Blob-Eingabebindung. Wenn Ihre Funktion startet, liest sie automatisch eine Datei aus dem Blob-Speicher und übergibt sie ihn als Parameter. Sie schreiben keinen Code für das Storage-SDK. Sie rufen lediglich die Daten ab und verarbeiten. Ein weiteres Beispiel, eine Warteschlange-Ausgabebindung. Ihre Funktion verarbeitet etwas und gibt am Ende einen Wert zurück. Die Runtime serialisiert diesen Wert und legt ihn in der Warteschlange ab. Sie schreiben keinen Warteschlange. Sie geben lediglich einen Wert zurück. Bindungen sind optional. Sie können null, ein oder viele Bindungen verwenden. Einige Funktionen benötigen lediglich einen Trigger ohne jegliche Bindung. Andere verfügen möglicherweise über drei oder vier Bindungen, die eine Verbindung mit verschiedenen Diensten. Die Kombination aus Triggern und Bindungen macht Azure Functions so leistungsstark. Sie schreiben die Geschäftslogik, den eigentlichen Entscheidungsfindungscode. Die Plattform übernimmt die gesamte Integration. Ihre Funktion bleibt klein, fokussiert und leicht verständlich. Die Preisgestaltung. Die Preisgestaltung überrascht die meisten Anfänger. Für die meisten Leute ist der Verbrauchsplan die Standardauswahl und Sie sollten ihn in 90% der Fälle verwenden. Und so funktioniert es. Sie zahlen nur, wenn Ihre Funktion tatsächlich ausgeführt wird. Wenn Sie inaktiv ist, zahlen Sie nichts. Null, keine Cent. Die Rechnung setzt sich aus zwei Komponenten zusammen. Erstens die Anzahl der Ausführungen, also wie oft Ihre Funktion ausgelöst wird. Zweitens die Ausführungszeit, gemessen in GB-Sekunden. Das ist im Grunde die Ausführungsdauer Ihrer Funktion multipliziert mit dem von Ihr verwendeten Arbeitsspeichel. Der kostenlose Zuschuss ist großzügig. Sie erhalten eine Million Ausführungen pro Monat und 400.000 Gigabyte Sekunden völlig kostenlos. Für die meisten kleinen Projekte, Hobby-Apps und Prototypen zahlen Sie keinen Cent. Niemals. Selbst wenn Sie den kostenlosen Zuschuss überschreiten, sind die Tarife immer noch unglaublich. 20 Cent pro Million Ausführung. Das ist kein Tippfehler. 20 Cent für eine Million Ausführung. Stellen Sie sich vor, Sie zahlen nur für Strom, wenn Sie ihn einschalten. Es gibt keine monatliche Grundgebühr für die Verkabelung in Ihren Wänden. Sie zahlen nur für den Strom, den Sie tatsächlich verbrauchen. Es gibt jetzt noch andere Pläne. Flex Consumption ist neuer und bietet Unterstützung für virtuelle Netzwerke. Premium hält Ihre Funktion immer betriebsbereit, sodass es keine Verzögerungen beim Kaltstatt gibt. Dedicated bietet Ihnen eine feste Kapazität in einem herkömmlichen App-Service-Plan. Für den Einstieg ist Consumption jedoch fast immer die richtige Wahl. Eine Warnung jedoch. Die kostenlose Zuteilung wird auf alle Ihre Funktions-Apps im selben Abonnement aufgeteilt. Wenn Sie über 10 Funktions-Apps verfügen, greifen alle auf dieselben 1 Million kostenlosen Ausführungen zu. Behalten Sie dies also im Auge, wenn Sie mehr als nur ein paar Funktions-Apps erscheinen. Die Preise sind großartig. Aber lassen Sie uns dies anhand eines konkreten Beispiels verdeuteln. Ein Szenario aus der Praxis. Dählen Sie sich vor, Sie betreiben eine Website auf der Benutzerprofilbilder hochladen. Diese Bilder sind riesig, etwa 10 Megabyte pro Bild. Und das verursacht einige echte Probleme. Große Dateien kosten mehr beim Speichern, verlangsamen Ihre Website jedes Mal, wenn jemand eine Seite lädt und frustrieren Ihre Benutzer, die warten müssen, bis Sie Fotos erhalten. Daher benötigen Sie eine Möglichkeit, diese Bilder automatisch zu verkleinern. Ohne Azure Functions müssten Sie einen Hintergrund-Worker von Grund auf neu erstellen. Das bedeutet, dass Sie einen separaten Server benötigen, eine Warteschlange zum Verwalten der Arbeitslast einrichten und Code schreiben müssen, um alle beweglichen Teile zu verarbeiten. Das ist eine Menge unnötiger Komplexität für etwas so Einfaches wie das Verkleinern eines Bildes. Mit Azure Functions benötigen Sie lediglich einen Blob-Trigger und eine Funktion. Sie müssen sich keine Gedanken ums Server machen. Ich erkläre Ihnen, wie es funktioniert. Ein Benutzer lädt ein Foto über Ihre Website hoch und diese Datei wird im Azure Blob Storage abgelegt. Sobald die Datei eintrifft, wird automatisch ein Blob-Trigger ausgelöst. Ihre Funktion wird aktiviert, führt den Komprimierungscode aus und speichert die kleinere Version wieder im Speicher. All dies geschieht innerhalb von Sekunden. Der Benutzer muss nie warten, da der gesamte Prozess völlig unsichtbar im Hintergrund abläuft. Hier ist ein weiteres Beispiel aus dem Alltag. Senden einer Willkommens-E-Mail, wenn sich jemand für Ihren Dienst anmeldet. Ein HTTP-Trigger findet die Registrierungsanforderungen von Ihrer Website an. Ihre Funktion wird ausgelöst, ruft die E-Mail-Adresse des Benutzers ab, sendet eine Willkommensnachricht über SendGrid und schon ist sie fertig. Der Benutzer erhält seine E-Mail fast sofort. Kein E-Mail-Server muss eingerichtet oder eine Sendewarteschlange verwaltet werden. Nur eine Funktion, ein Auftrag fertig. Genau für solche Aufträge wurde Azure Functions entwickelt. Kleine, fokussierte, ereignisgesteuerte Aufgaben. Keine riesigen Anwendungen, keine komplexen Workflows, sondern einfach nur eine Sache, die gut erledigt wird und durch ein Geschehen an einer anderen Stelle ausgelöst wird. Wann sollten Azure Functions verwendet werden? Wann sollten Sie also auf eine Funktion zurückgreifen und wann auf etwas anderes? Hier ist eine schnelle Möglichkeit, die zu entscheiden. Fragen Sie sich, ob es sich um eine kurze Aufgabe handelt, ob sie eigenes gesteuert ist und ob sie zustandslos ist. Wenn Sie alle drei Fragen mit Ja beantwortet haben, ist Azure Functions wahrscheinlich das richtige Tool. Beginnen wir mit den guten Anwendungsfällen. APIs und Webhooks passen perfekt zusammen. Sie benötigen einen schlanken Endpunkt, der auf eine HTTP-Anforderung reagiert, eine Aufgabe ausführt und ein Ergebnis zurückgibt. Genau dafür sind HTTP-Trigger konzipiert. Die Datei in Bildverarbeitung ist ein weiterer wichtiger Aspekt. Eine Datei landet im Speicher, ihre Funktion wird ausgelöst, transformiert sie und speichert das Ergebnis alles ohne Server. Geplante Aufgaben wie die nächtliche Bereinigung oder die Berichterstellung funktionieren hervorragend mit Timer-Triggern. Auch die Datentransformation für ETL-Pipelines ist üblich. Und Funktionen sind das perfekte Integrations-Element, da sie zwei Dienste miteinander verbinden, die normalerweise nicht miteinander kommunizieren. Sprechen wir nun darüber, wann Funktionen nicht gut geeignet sind. Prozesse mit langer Ausführungszeit sind ein Problem, da Funktionen im Verbrauchstarif standardmäßig ein Time-Out-Limit von fünf Minuten haben, das bei Konfiguration auf bis zu zehn Minuten erhöht werden kann. Wenn Ihr Auftrag länger dauert, benötigen Sie eine andere Lösung. Zustandsbehaftete Anwendungen sind ein weiteres Problem. Funktionen speichern zwischen den Ausführungen nichts. Wenn Sie den Sitzungsstatus beibehalten oder den Fortschritt über Schritte hinweg verfolgen müssen, verstoßen Sie gegen das Design. Hohe Compute-Workloads sind ebenfalls nicht geeignet. Wenn Sie über Minuten oder Stunden hinweg eine anhaltende CPU-Auslastung benötigen, ist eine virtuelle Maschine der bessere Wahl. Komplexe Workflows, bei denen eine Aufgabe von einer anderen abhängt, werden besser von dauerhaften Funktionen oder Logic Apps verarbeitet. Hier ist ein kurzer Überblick über die Alternativen. Azure Logic Apps ist die No-Code-Option zum Verbinden von Diensten. Wenn Sie keinen benutzerdefinierten Code schreiben müssen, kann Logic Apps die Aufgabe mit einem visuellen Designer erledigen. Azure App Service eignet sich für vollständige Web-Anwendungen, die rund um die Uhr ausgeführt werden. Wenn Sie eine vollständige Website oder API benötigen, die man verfügbar ist, ist dies das richtige Tool für Sie. Azure Container Apps bietet Ihnen containerisierte Microservices mit mehr Kontrolle über die Laufzeit. Und Azure Virtual Machines gibt Ihnen bei Bedarf die volle Kontrolle über das Betriebssystem. Hier ist eine einfache Faustregel. Wenn Sie den Auftrag in einem Satz beschreiben können, ist er wahrscheinlich ein guter Kandidat für eine Funktion. Komprimieren Sie Bilder, wenn Sie hochgeladen werden. Senden Sie eine Willkommens-E-Mail, wenn sich jemand anmeldet. Führen Sie jeden Abend um Mitternacht den Bereitungsauftrag auf. Ein Satz, ein Auftrag, eine Funktion. Häufige Anfängerfehler, die Sie vermeiden sollten. Sprechen wir nun über ein paar Dinge, auf die Sie achten sollten. Das sind die Fehler, die fast jeder zu Beginn begeht. Ein häufiger Anfängerfehler ist zu glauben, Funktionen seien immer kostenlos. Die kostenlose Bereitstellung ist groß. Ich weiß, eine Million Ausführungen klingen nach viel. Aber wenn Ihre Funktion viral geht oder von einem Bot attackiert wird, summieren sich diese Ausführungen schnell. Überwachen Sie daher Ihre Nutzung, richten Sie in Azure eine Budgetwarnung ein und erhalten Sie am Ende des Monats keine überraschende Rechnung. Ein weiterer Fehler ist das Ignorieren von Kaltstarts. Wenn Ihre Funktion nach einer Zeit im Leerlauf zum ersten Mal ausgeführt wird, dauert dies länger. Beim Verbrauchstarif kann das ein paar Sekunden dauern. Für die meisten Anwendungsfälle ist das in Ordnung. Wenn Sie jedoch eine latenzempfindliche API erstellen, bei der jede Millisekunde zählt, sollten Sie den Premium-Tarif in Betracht ziehen oder Always-Ready-Instanzen aktivieren. Dann gibt es noch das Schreiben von Funktionen, die zu lange dauern. Der Verbrauchstarif hat ein Timeout, standardmäßig 5 Minuten, maximal 10 Minuten. Wenn Ihre Funktion 15 Minuten benötigt, um eine Datei zu verarbeiten, wird sie auf halbem Weg beendet. Teilen Sie den Auftrag in kleinere Teile auf oder verwenden Sie einen anderen Hosting. Ein weiterer Fehler, den man leicht übersehen kann, ist die Nichtverwendung von aus Paketbereitstellung aus. Dabei handelt es sich um eine einfache Konfigurationsänderung, die Kaltstarts verbessert und Bereitstellungen zuverlässiger macht. Anstatt einzelne Dateien zu kopieren, stellen Sie ein ZIP-Paket bereit, aktivieren Sie dazu einfach das Kontrollkästchen im Portal. Das Verfügbarmachen von HTTP-Endpunkten ohne Authentifizierung ist eine weitere Falle. Es ist leicht, eine Funktion während des Tests auf anonym zu belassen und dann zu vergessen, sie zu sperren. Legen Sie die Autorisierungsebene von Anfang an richtig fest. Verwenden Sie Funktions- oder Administrativschluss. Lassen Sie die Tür nicht auf. Die Wiederverwendung von Speicherkonten in mehreren Funktions-Apps ist ebenfalls ein Problem. In der Entwicklung ist die gemeinsame Nutzung ein Problem. In der Produktion sollte jede Funktions-App über ein eigenes Speicherkonto verfügen. Andernfalls treten Probleme mit lauten Nachbarn auf, bei denen der Datenverkehr einer Funktion verlangsamt. Und schließlich darf Application Insights nicht aktiviert werden. Ohne Application Insights blieben. Sie sehen keine Fehler, Störungen oder Leistungsprobleme. Sie erfahren nicht, ob Ihre Funktion zu lange ausgeführt wird oder unbemerkt fehlschlägt. Aktivieren Sie Application Insights. Es dauert 30 Sekunden und erspart stundenlanges Debuggen. Die goldene Regel für all dies lautet, halten Sie Ihre Funktion klein, fokussiert und zustandslos. Ein Auftrag pro Funktion, nicht mehr. Es ist also das System auf. Azure Functions ist eine serverlose Compute-Lösung, die kleine Codestücke als Reaktion auf Ereignisse ausführt. Sie zahlen nur, wenn Ihr Code ausgeführt wird. Trigger teilen Ihrer Funktion mit, wann sie aktiviert werden soll. Bindungen verbinden Sie mit den benötigten Daten. Und der Verbrauchstarif sorgt dafür, dass die Funktion für kleine Projekte nahezu kostenlos ist. Im Moment ist es am besten, eine einfache, über HTTP ausgelöste Funktion im Azure-Portal zu erstellen. Das dauert fünf Minuten und ist kostenlos. Abonnieren Sie Microsoft Knowledge Nuggets, um weitere einfache englische Aufschlüsselungen zu erhalten. Und teilen Sie dies mit allen, die immer wieder nachfragen, was serverlos bedeutet. Hau.