© Vectorium/Shutterstock.com
Entwickler Magazin
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.

Christian Weyer


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 wi...

Entwickler Magazin
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.

Christian Weyer


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 wi...

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