© Vectorium/Shutterstock.com
Serverless Microservices am Beispiel von Azure

Functions und mehr - für alle


Warum muss es „Serverless oder Microservices“ sein? Es sollte vielmehr „Microservices mit Serverless“ heißen! Basierend auf einigen der allgemein anerkannten Prinzipien von Microservices können wir serverlose Architekturen und Technologien verwenden, um hochfokussierte Microservices zu bauen. Schauen wir uns gemeinsam und überblicksmäßig einen pragmatischen Ansatz zum Erstellen von Microservices mit Azure Functions, Azure Service Bus, Azure Storage und weiteren Diensten und Tools an. Und der funktioniert für fast alle Softwareentwickler: Java, .NET, Node.js und sogar Python.

Microservices sind seit einigen Jahren in aller Munde und es wird heftig über deren Vorzüge, aber auch über die damit verbundenen Nachteile diskutiert. Wenn man sich für einen Microservices-Ansatz entscheidet, stellt sich relativ schnell die Frage nach dem technologischen Lösungsstapel. Mit Serverless und Functions as a Service existiert seit relativ kurzer Zeit ein alternativer Weg für die Realisierung.

Microservices – aber pragmatisch

Ohne hier eine komplette Abhandlung über Microservices zelebrieren zu wollen – einige der zentralen Prinzipien für erfolgreiche Microservices-Architekturen möchte ich gerne thematisieren, um dann die Überleitung in die Serverless-Welt daran festmachen zu können. Die vier mir aus Architektursicht wichtigsten sind:

  • Single Responsibility: Ein Microservice macht eine (Business-)Sache, und die macht er richtig. Es ist in der Tat eine hohe Kunst, Microservices richtig zu schneiden und das Gleichgewicht von Zuständigkeit und Komplexität zu finden.

  • Isolation: Ein Microservice ist isoliert von anderen Services. Das bedingt eine physikalische Trennung und die Möglichkeit, mit dem Microservice über wohl definierte und technologieunabhängige Schnittstellen kommunizieren zu können. Zudem ist es manchmal sinnvoll, eine spezielle Technologie im Innenleben eines Microservices zu nutzen, um Use Cases optimal umsetzen zu können – die Wahl der Technologien pro Microservice sollte über Isolation gewährleistet sein.

  • Autonomie: Die Königsdisziplin bei der Gestaltung von Microservices-Architekturen – jeder Service hat seine eigene Datenhaltung und teilt sich keine Datenbank o. Ä. mit anderen Diensten. Dieses Prinzip konsequent umzusetzen, bedeutet eine weitgehende Entkopplung der Services – die allerdings einen Preis mit sich bringt.

  • Entkopplung: Um Services auf der Prozess- und Kommunikationsebene von einander zu entkoppeln und die Gesamtarchitektur dafür weniger fehlerfällig gestalten zu können, bietet sich der Einsatz asynchroner Kommunikationsmuster z. B. über Message-Queues an.

Vermutlich ist es für Sie als Leser am einfachsten, die Microservices-Prinzipien in einer Serverless-Welt anhand eines kleinen Beispiels vor Augen geführt zu bekommen. Also schauen wir uns mal eins an. Die Beispielanwendung ist auch mit komplettem Sourcecode in einem GitHub Repository zugänglich [1].

End-to-End-Betrachtungen

Wichtig für die Betrachtungen von Microservices – egal ob Serverless oder nicht – ist eine End-to-End-Sicht auf ein System. Es hilft meist nicht wirklich, sich nur einzelne Services oder gar einzelne Implementierungsdetails von Services anzuschauen: Eine Gesamtbetrachtung umschließt die Clientanwendungen ebenso wie auch nichtfachliche Services, wie z. B. einen Authentifizierungs- oder Notifizierungsdienst.

Unser exemplarisches Order-Monitoringsystem (Abb. 1) – das natürlich für den Zweck des Artikels stark vereinfacht dargestellt und implementiert wurde – ist vom Grundgedanken her recht simpel: Wann immer ein angemeldeter Benutzer über die Shoppingwebsite einkauft und eine Bestellung aufgibt, wollen wir mit einer mobilen App – als Cross-Plattform-SPA umgesetzt – als ebenfalls angemeldeter Benutzer benachrichtigt werden. Wir können zudem über diese SPA immer die aktuelle Liste von Bestellungen sowie deren Auslieferungszustand einsehen.

weyer_functions_1.tif_fmt1.jpgAbb. 1: Serverless-Microservices-Beispielarchitektur (Order-Monitoring)

Wie in Abbildung 1 zu sehen ist, sind hier fünf Microservices involviert. Die Interaktionen sind über nummerierte Schritte nachvollziehbar. Die Client-SPA ist in diesem Fall nicht als Sammelsurium von Microfrontends umgesetzt, das würde den Rahmen des Beispiels bei weitem sprengen. Vielmehr bedient sich die SPA der unterschiedlichen APIs der Microservices. Für ein vereinfachtes URL-Management und eine bessere Entkopplung der physikalischen Dienste wird in der Gesamtarchitektur ein API-Gateway [2] eingesetzt. Selbstverständlich ist ein API-Gateway kein Muss in einer solchen Architektur, wird aber oft und gerne zur weiteren Abstraktion angewendet.

Die erste Frage, die sich stellt, wenn man aus Sicht des Endanwenders auf die Anwendung schaut: Wo kommt die SPA her und wie kommt Sie in meinen Browser?

Zuhause für SPAs: Azure Blob Storage

Eine SPA ist am Ende des Tages ein Paket bestehend aus HTML, CSS, Bildern und anderen Assets. Dieses Paket muss man nicht umständlich und teuer auf einen Webserver oder gar Application-Server deployen. Bei jeder Cloudplattform bietet sich die sehr schlanke und zudem kostengünstige Option, die SPA einfach als statisches Gesamtgebilde über einen Storage-Service bereitzustellen. Im Fall von Microsofts Cloud ist das Azure Blob Storage.

Praxistipp: Azure Portal, CLI und REST API

Für alle Azure Services kann man die Erstellung und die Konfiguration entweder über das Azure Portal, über ein REST API oder aber über das sehr mächtige Azure CLI (Command Line Interface) [3] konfigurieren und automatisieren.

Ist der Storage-Account angelegt, kann man das Statische-Website-Feature aktivieren. Danach steht ein Container namens $web zur Verfügung. Dieser dient gewissermaßen als Root-Verzeichnis für einen statischen Webserver, nur eben über Blob Storage bereitgestellt. In Abbildung 2 kann man die Client-SPA aus dem Beispiel sehen, hier über das Werkzeug Azure Storage Explorer [4] manuell in die Cloud deployt.

weyer_functions_2.tif_fmt1.jpgAbb. 2: Angular SPA über Azure Blob Storage bereitgestellt

Selbstverständlich werden die Endpunkte für den Blob-Storage-basierten Webserver über HTTPS veröffentlicht. Mit zusätzlichen Azure-Diensten wie Azure DNS und Azure CDN lassen sich zudem eigene Domains, SSL-Zertifikate und letztendlich auch superschnelle CDN-Cacheknoten etablieren. Alles, ohne einen einzigen Server anfassen oder gar kennen zu müssen.

Wenn die SPA nun also per HTTPS in unserem Browser läuft und Daten abrufen möchte, dann braucht es freilich APIs und Schnittstellen in unseren Diensten. Die werden wir nun Serverless-like implementieren und bereitstellen.

Microservice-Code und Serverles...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang