Dr. Felix Nendzig Accso – Accelerated Solutions GmbH

„Der Einsatz von Microservices zielt darauf ab, komplexe Anwendungen, die als Monolith nur schwer zu managen wären, durch Dezentralisierung und Autonomiemaximierung skalierbar, wartbar und leicht erweiterbar zu machen. Jeder Microservice erfüllt dabei genau eine Funktion im Sinne der fachlichen Logik.“

Wie zu erwarten zieht das heißdiskutierte Thema Microservices auch an Microsoft nicht vorüber. Grund genug, einmal näher zu betrachten, wie man als .NET-Entwickler bei der Entwicklung von Microservices mit Docker von technischer Seite unterstützt wird.

Mit „.NET Microservices: Architecture for Containerized .NET Applications“ hat Microsoft nun ein mehr als dreihundertseitiges E-Book veröffentlicht, in dem das Unternehmen seine Sicht auf das Thema umfassend vorstellt und insbesondere die Benutzung von Docker bei der Entwicklung von Anwendungen mit Microservices-Architektur empfiehlt.

In diesem Beitrag soll Microsofts Sicht auf das Thema Microservices näher beleuchtet und mit Blick auf unsere eigene Erfahrung kommentiert werden. Weiterhin werden wir darauf eingehen, wie Docker bei der Entwicklung von Microservices genutzt werden kann.

Was ist eine Microservices-Architektur?

Das zentrale Erkennungsmerkmal einer Microservices-Architektur ist, dass sich die gesamte Anwendung aus einzelnen, voneinander unabhängigen Services zusammensetzt. Durch Dezentralisierung und Autonomiemaximierung soll auch bei komplexen Anwendungen eine gute Skalierbarkeit in der Entwicklung – gegenüber einer monolithischen Architektur – erreicht werden. Die Entwicklung kann in kleinen, unabhängigen Teams mit geringem Kommunikationsbedarf untereinander stattfinden. Um einen Vorteil gegenüber einer monolithischen Anwendung zu erreichen, sollten die Microservices jeweils folgende Bedingungen erfüllen:

  • Ein Service erfüllt genau einen fachlichen Zweck und diesen vollständig
  • Jeder Service ist unabhängig deploybar
  • Jeder Service umfasst sämtliche benötigte Schichten, Teams arbeiten unabhängig voneinander (vertikaler Schnitt)
  • Asynchrone Kommunikation zwischen Services (keine zentral steuernde Einheit)
  • Keine gemeinsamen Daten oder Code (Shared Nothing)
  • Unabhängige Datenmodelle und minimale APIs zur Gewährleistung eigenständiger Entwicklungszyklen

Der Name „Microservices“ impliziert, dass die einzelnen Services klein sein sollen. Diese Charakterisierung bezieht sich aber nicht auf die Lines of Code oder die Anzahl der Klassen je Service. Stattdessen bedeutet es, dass ein Service nur genau eine sinnvolle Funktion im Sinne der fachlichen Logik erfüllen soll. Diese Idee folgt dem Konzept des Bounded Context aus dem Domain-driven Design. Danach wird ein großer fachlicher Themenbereich in kleinere Bereiche, die Bounded Contexts (Abb. 1), aufgeteilt, die jeweils ihre eigenen, eindeutigen Fachbegriffe benutzen (Ubiquitous Language). Ein Microservice überschreitet keinesfalls die Grenzen eines Bounded Contexts. Er implementiert maximal den gesamten Bounded Context, typischerweise aber nur einen Teilbereich.

 

Abb. 1: Illustration zweier Bounded Contexts (Quelle)

Abb. 1: Illustration zweier Bounded Contexts (Quelle)

 

Man sollte die kleinsten Microservices implementieren, die die oben genannten Bedingung erfüllen. Wird die optimale Größe unterschritten, wachsen die Abhängigkeiten der Services untereinander. Das verschlechtert die Performance der Anwendung zur Laufzeit und während der Entwicklung durch erhöhten Kommunikationsbedarf über Service- und Teamgrenzen hinweg.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 5.19 - "Strategisches Design"

Alle Infos zum Heft
579886922Entwicklung von Microservices mit Microsoft .NET
X
- Gib Deinen Standort ein -
- or -