Serverless: Ohne Server in die Azure-Cloud

Serverless ist derzeit in aller Munde. Microsoft Azure bietet eine Vielzahl von Cloud-Diensten. Doch welche davon eignen sich für Serverless-Architekturen?

In Pocket speichern vorlesen Druckansicht 103 Kommentare lesen
Serverless: Ohne Server in die Azure-Cloud

(Bild: Pixabay)

Lesezeit: 15 Min.
Von
  • Boris Wilhelms
Inhaltsverzeichnis

Im Angebot der großen Cloud-Provider wie Microsoft Azure, Amazon Web Services oder Google Cloud Platform findet sich eine große Fülle an Diensten, angefangen bei Infrastruktur über Plattformservices bis hin zu klassischen Web-Diensten/-APIs. Erklärtes Ziel von Serverless-Architekturen ist es, die Server, die Infrastruktur und das Betriebssystem sowie die genutzten Plattformen zu abstrahieren und somit Softwareentwicklern das Arbeiten zu erleichtern.

Das Serverless-Modell befindet sich derzeit noch in einer Evolution. Es gilt, bestehende Dienste um Serverless-Merkmale wie einfache beziehungsweise automatische Skalierung oder ein Preismodell nach Nutzung zu erweitern. Darüber hinaus kommen immer wieder neue Dienste hinzu, die von Anfang an als Serverless-Dienst ausgelegt sind. Dieser Artikel richtet am Beispiel von Microsoft Azure einen genaueren Blick auf die drei Bereiche, die in der Regel das Fundament für Serverless-Anwendungen bilden: Code, Datenhaltung und die Kommunikation zwischen Diensten.

Azure Functions ist der wohl bekannteste Serverless-Dienst in Microsoft Azure und ist Microsofts Implementierung von "Functions as a Service" (FaaS). Azure Functions sind Code, der sich durch ein Ereignis (Trigger) ausführen lässt. Neben gängigen Triggern wie einem HTTP-Aufruf, einer Nachricht in einer Queue oder einer definierten Uhrzeit stellt Microsoft auch eine Reihe von Triggern zur Verfügung, die sich aus anderen Azure-Diensten heraus auslösen lassen. Dazu zählen beispielsweise Azure Cosmos DB, Azure Event Grid oder Azure Event Hub. Neben den Triggern, die eine Azure Function aufrufen, ist es mittels Eingabe- und Ausgabe-Bindings möglich, deklarativ eine Verbindung mit Daten in anderen Systemen herzustellen.

Auch hier bietet Microsoft eine Vielzahl an bereits fertigen Bindings an, um andere Azure-Dienste einzubinden. Sollten die bereitgestellten Bindings nicht ausreichen, so ist es möglich eigene zu schreiben, um andere Systeme einzubinden. Durch die Vielzahl bereits vorhandener Trigger und Bindings lassen sich nicht nur schnell und einfach leichtgewichtige Web-APIs erstellen, sondern Azure Functions mutiert damit zu einer Art Schweizer Taschenmesser, um verschiedene Azure-Dienste zu verbinden und deren Daten zu verarbeiten.

Azure Functions lassen sich in einer ganzen Reihe von Programmiersprachen entwickeln. Allgemein verfügbar sind aktuell C#, JavaScript und F#. Andere Sprachen wie Java, Python, PHP, TypeScript, aber auch Shell-Sprachen wie Batch, Bash oder PowerShell sind aktuell als experimentelle Vorschau verfügbar. Je nach Sprache lassen sich Azure Functions ohne eine Entwicklungsumgebung direkt im Azure-Portal erstellen und testen.

Das folgende C#-Beispiel zeigt eine Azure Function, die Produkte für eine Produktliste lädt und zurück gibt. Die Funktion wird durch einen HTTP-Aufruf ausgelöst (HttpTrigger) und die möglichen HTTP-Methoden, Route und Zugriffsberechtigung in dem HttpTrigger-Attribut beschrieben. Zusätzlich wird die Verbindung zur Azure Cosmos DB deklarativ hergestellt.

public static class HttpTrigger {
[FunctionName("ProductList")]
public static IActionResult Run(
[HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "products/list")]HttpRequest req,
[CosmosDB("store", "products", ConnectionStringSetting = "CosmosDbConnectionString")] IEnumerable<Product> products)
{
return new OkObjectResult(products);
}
}

public class Product {
public Guid Id { get; set; }
public string Name { get; set; }
}

Im Gegensatz zum klassischen Web-App-/API-Hosting bietet Azure Functions mit dem Verbrauchsplan ein Serverless-Modell an, bei dem automatisch Computerleistung zur Verfügung steht und der Code horizontal skaliert, sobald eine entsprechende Last vorliegt. Endet die Code-Ausführung, skaliert der Dienst automatisch herunter. Beim Verbrauchsplan erfolgt die Abrechnung, ganz im Serverless-Stil, auf Grundlage der Anzahl der Ausführungen, der Ausführungszeit und des genutzten Arbeitsspeichers. Dank eines Freikontingents und den vergleichsweise günstigen Ausführungspreisen sind Azure Functions mit einem Verbrauchsplan derzeit oft preiswerter als eine klassische Web-App/API.

Azure Functions skalieren automatisch, je nach Last (Abb. 1).

(Bild: Microsoft Azure)

Dank der Trigger und Bindings und der damit verbundenen Möglichkeit, auf deklarativem Wege Verbindungen aufzubauen, sowie des Verbrauchsplans für die automatische Skalierung können sich Entwickler beim Einsatz von Azure Functions auf den Entwurf und die Umsetzung von Geschäftslogiken konzentrieren.