Was sind Microservices?

Microservices sind bei Führungskräften und Projektleitern wahrscheinlich mindestens genauso beliebt wie bei Entwicklern. Dies ist eine der eher ungewöhnlichen Eigenschaften von Microservices, da der Begeisterung für Softwarearchitekturen in der Regel Softwareentwicklungsteams vorbehalten sind. Der Grund dafür ist, dass Microservices dem Bedürfnis vieler Führungskräfte entsprechen, ihre Teams und Entwicklungsprozesse zu strukturieren und zu verwalten.

Anders ausgedrückt sind Microservices ein Architekturmodell, das ein gewünschtes Betriebsmodell besser unterstützt. In einer IBM-Umfrage aus dem Jahr 2021 unter mehr als 1.200 Entwicklern und IT-Führungskräften stimmten 87 % der Microservice-Nutzer zu, dass die Einführung von Microservices die Kosten und den Aufwand wert ist. 

Hier sind nur einige der Vorteile von Microservices für Unternehmen:

Unabhängige bereitstellbar

Das vielleicht wichtigste Merkmal von Microservices ist, dass es aufgrund der Tatsache, dass die Services kleiner und unabhängig voneinander einsetzbar sind, nicht mehr eines geschäftlichen Riesenaufwandes bedarf, um eine Codezeile zu ändern oder eine neue Funktion in der Anwendung hinzuzufügen.

Microservices versprechen Unternehmen ein wirksames Mittel gegen die Frustrationen, die mit kleinen Änderungen verbunden sind, die viel Zeit in Anspruch nehmen. Man muss kein promovierter Informatiker sein, um den Wert eines Ansatzes zu erkennen oder zu verstehen, der Geschwindigkeit und Agilität besser fördert.

Aber Schnelligkeit ist nicht der einzige Vorteil dieser Art der Service-Gestaltung. Ein gängiges Organisationsmodell, das sich immer mehr durchsetzt, besteht darin, funktionsübergreifende Teams um ein Geschäftsproblem, einen Service oder ein Produkt herum zusammenzubringen. Das Microservices-Modell passt perfekt zu diesem Trend, da es Unternehmen ermöglicht, kleine, funktionsübergreifende Teams um einen Services oder eine Sammlung von Services herum zu bilden und diese agil arbeiten zu lassen.

Die lose Kopplung von Microservices sorgt außerdem für eine gewisse Fehlerisolierung und eine bessere Ausfallsicherheit in Anwendungen. Und die geringe Größe der Dienste, kombiniert mit ihren klaren Grenzen und Kommunikationsmustern, erleichtert es neuen Teammitgliedern, die Codebasis zu verstehen und schnell dazu beizutragen – ein klarer Vorteil in Bezug auf Geschwindigkeit und Arbeitsmoral.

Das richtige Tool für den Job

In traditionellen n-Tier-Architekturmustern teilt sich eine Anwendung in der Regel einen gemeinsamen Stack, wobei eine große, relationale Datenbank die gesamte Anwendung unterstützt. Dieser Ansatz hat mehrere offensichtliche Nachteile – der größte davon ist, dass alle Komponenten einer Anwendung einen gemeinsamen Stack, ein gemeinsames Datenmodell und eine gemeinsame Datenbank verwenden müssen, selbst wenn es für bestimmte Elemente ein klar besseres Tool für die Aufgabe gibt. Das führt zu schlechter Architektur und ist frustrierend für Entwickler, die ständig wissen, dass es eine bessere, effizientere Möglichkeit gibt, diese Komponenten zu bauen.

Im Gegensatz dazu werden in einem Microservice-Modell die Komponenten unabhängig voneinander bereitgestellt und kommunizieren über eine Kombination aus REST, Event Streaming und Message Brokern. So kann der Stack jedes einzelnen Dienstes für diesen Dienst optimiert werden. Die Technologie ändert sich ständig, und eine Anwendung, die aus mehreren kleineren Services besteht, lässt sich viel einfacher und kostengünstiger weiterentwickeln, wenn eine wünschenswertere Technologie verfügbar wird.

Präzise skalieren

Mit Microservices können einzelne Services individuell bereitgestellt werden – aber sie können auch individuell skaliert werden. Der daraus resultierende Vorteil liegt auf der Hand: Richtig eingesetzt, benötigen Microservices weniger Infrastruktur als monolithische Anwendungen, da sie eine präzise Skalierung nur der Komponenten ermöglichen, die sie benötigen, anstatt der gesamten Anwendung im Fall von monolithischen Anwendungen.

Auch Mikrodienste haben ihre Herausforderungen:

Die erheblichen Vorteile von Microservices gehen mit erheblichen Herausforderungen einher. Die Umstellung von Monolithen auf Microservices bedeutet eine viel höhere Komplexität des Managements – viel mehr Dienste, die von viel mehr Teams erstellt und an viel mehr Orten bereitgestellt werden. Probleme in einem Dienst können Probleme in anderen Diensten verursachen oder durch diese verursacht werden. Die Protokolldaten (die zur Überwachung und Problemlösung verwendet werden) sind umfangreicher und können je nach Service inkonsistent sein. Neue Versionen können zu Problemen mit der Abwärtskompatibilität führen. Anwendungen erfordern mehr Netzwerkverbindungen, was wiederum mehr Möglichkeiten für Latenz- und Verbindungsprobleme bedeutet. Ein DevOps-Ansatz kann viele dieser Probleme lösen, aber dessen Einführung bringt auch eigene Herausforderungen mit sich.

Dennoch halten diese Herausforderungen Nichtanwender nicht davon ab, Microservices zu übernehmen – oder Anwender davon, ihr Engagement für Microservices zu vertiefen. Die oben genannten IBM-Umfragedaten zeigen, dass 56 % der derzeitigen Nichtanwender wahrscheinlich oder sehr wahrscheinlich innerhalb der nächsten zwei Jahre Microservices einführen werden und 78 % der derzeitigen Microservice-Nutzer wahrscheinlich mehr Zeit, Geld und Aufwand in Microservices investieren werden.

Die Microservices-Architektur wird oft als für DevOps und kontinuierliche Integration oder kontinuierliche Bereitstellung optimiert beschrieben, und im Zusammenhang mit kleinen Diensten, die häufig bereitgestellt werden können, ist es leicht zu verstehen, warum.

Man kann die Beziehung zwischen Microservices und DevOps aber auch anders betrachten: Microservice-Architekturen benötigen DevOps, um erfolgreich zu sein. Monolithische Anwendungen haben zwar eine Reihe von Nachteilen, die bereits in diesem Artikel besprochen wurden, aber sie haben den Vorteil, dass sie kein komplexes verteiltes System mit mehreren beweglichen Teilen und unabhängigen Technologie-Stacks sind. Angesichts der enormen Zunahme an Komplexität, beweglichen Teilen und Abhängigkeiten, die mit Microservices einhergehen, wäre es jedoch unklug, sich Mikrodiensten ohne erhebliche Investitionen in Bereitstellung, Überwachung und Lebenszyklusautomatisierung zu nähern.

Rosalind Radcliffe bietet im Video einen tieferen Einblick in DevOps:

Microservices sind nicht unbedingt ausschließlich für Cloud Computing relevant, aber es gibt einige wichtige Gründe, warum sie so häufig zusammen auftreten – Gründe, die über die Tatsache hinausgehen, dass Microservices ein beliebter Architekturstil für neue Anwendungen sind und die Cloud ein beliebter Hosting-Standort für neue Anwendungen ist.

Zu den Hauptvorteilen der Microservices-Architektur gehören die Nutzungs- und Kostenvorteile, die mit der individuellen Bereitstellung und Skalierung von Komponenten verbunden sind. Diese Vorteile wären zwar auch bei einer lokalen Infrastruktur in gewissem Umfang gegeben, aber echte Kostenoptimierungen lassen sich durch die Kombination kleiner, unabhängig voneinander skalierbarer Komponenten mit einer bedarfsgerechten, nutzungsbasierten Infrastruktur erzielen.

Zweitens, und das ist vielleicht noch wichtiger, besteht ein weiterer Hauptvorteil von Microservices darin, dass jede einzelne Komponente den Stack übernehmen kann, der für ihre spezifische Aufgabe am besten geeignet ist. Die Verbreitung von Stacks kann zu einer erheblichen Komplexität und zu einem hohen Aufwand führen, wenn Sie sie selbst verwalten. Wenn Sie jedoch den unterstützenden Stack als Cloud-Service nutzen, können Sie die Verwaltungsherausforderungen drastisch minimieren. Anders ausgedrückt: Es ist zwar nicht unmöglich, eine eigene Microservice-Infrastruktur aufzubauen, aber nicht ratsam, insbesondere wenn man gerade erst anfängt.

Innerhalb von Microservices-Architekturen gibt es viele häufige und nützliche Design-, Kommunikations- und Integrationsmuster, die dabei helfen, einige der häufigsten Herausforderungen und Chancen zu bewältigen, darunter die folgenden:

Backend for Frontend (BFF)-Muster

Dieses Muster fügt eine Ebene zwischen der Benutzererfahrung und den Ressourcen ein, auf die die Erfahrung zugreift. Zum Beispiel hat eine App, die auf einem Desktop verwendet wird, andere Bildschirmgrößen, Anzeigen und Leistungsgrenzen als ein Mobilgerät. Mit dem BFF-Muster können Entwickler einen Backend-Typ pro Benutzeroberfläche erstellen und unterstützen, wobei die besten Optionen für dieses Interface verwendet werden, anstatt zu versuchen, ein generisches Backend zu unterstützen, das mit jedem Interface funktioniert, sich aber negativ auf die Frontend-Leistung auswirken kann.

Entitäts- und Aggregatmuster

Eine Entität ist ein Objekt, das sich durch seine Identität auszeichnet. Auf einer E-Commerce-Website kann ein Produktobjekt beispielsweise nach Produktname, Typ und Preis unterschieden werden. Ein Aggregat ist eine Sammlung verwandter Entitäten, die als eine Einheit behandelt werden sollten. Für die E-Commerce-Website wäre eine Bestellung also eine Sammlung (Aggregat) von Produkten (Entitäten), die von einem Käufer bestellt wurden. Diese Muster werden verwendet, um Daten auf sinnvolle Weise zu klassifizieren.

Muster der Service-Erkennung

Diese helfen Anwendungen und Services, einander zu finden. In einer Microservice-Architektur ändern sich Service-Instanzen aufgrund von Skalierung, Upgrades, Service-Ausfällen und sogar Service-Beendigungen dynamisch. Diese Muster bieten Entdeckungsmechanismen, um mit dieser Kurzlebigkeit umzugehen. Die Lastverteilung kann Service-Discovery-Muster verwenden, indem sie Zustandsprüfungen und Service-Ausfälle als Auslöser für die Neuverteilung des Datenverkehrs nutzt.

Adapter-Microservices-Muster

Stellen Sie sich Adaptermuster so vor, wie Sie sich Steckdosenadapter vorstellen, die Sie verwenden, wenn Sie in ein anderes Land reisen. Der Zweck von Adaptermustern besteht darin, Beziehungen zwischen Klassen oder Objekten zu übersetzen, die ansonsten nicht kompatibel sind. Eine Anwendung, die auf Drittanbieter-APIs basiert, muss möglicherweise ein Adaptermuster verwenden, um sicherzustellen, dass die Anwendung und die APIs miteinander kommunizieren können.

Strangler-Anwendungsmuster

Diese Muster helfen bei der Umgestaltung einer monolithischen Anwendung in Microservices. Der farbenfrohe Name (dt. Würgepflanze) bezieht sich darauf, wie eine Rebe (Microservices) langsam und mit der Zeit einen Baum (eine monolithische Anwendung) überwuchert und erstickt.

Es gibt zwar viele Muster, um Microservices sinnvoll zu nutzen, aber es gibt ebenso viele Muster, die jedes Entwicklungsteam schnell in Schwierigkeiten bringen können. Einige davon – umformuliert als „Don'ts“ für Microservices – sind die Folgenden:

Erstellen Sie keine Microservices

Genauer gesagt: Beginnen Sie nicht mit Microservices. Microservices sind eine Möglichkeit, Komplexität zu bewältigen, wenn Anwendungen zu groß und unhandlich geworden sind, um einfach aktualisiert und gewartet zu werden. Erst wenn Sie spüren, wie das Ausmaß und die Komplexität des Monolithen allmählich zunehmen, sollten Sie darüber nachdenken, wie Sie diese Anwendung in kleinere Services umwandeln können. Solange dies nicht der Fall ist, muss ihre monolithische Anwendung nicht refaktoriert werden.

Verzichten Sie bei Microservices nicht auf DevOps oder Cloud-Services

Der Aufbau von Microservices bedeutet den Aufbau verteilter Systeme, und verteilte Systeme sind schwierig – und sie sind besonders schwierig, wenn Sie Entscheidungen treffen, die es noch schwieriger machen. Der Versuch, Microservices ohne eine ordnungsgemäße Bereitstellung und Überwachungsautomatisierung oder verwaltete Cloud-Services zur Unterstützung Ihrer inzwischen weitläufigen, heterogenen Infrastruktur zu betreiben, ist ein Garant für viele vermeidbare Probleme. Ersparen Sie sich die Mühe, damit Sie sich um den Zustand kümmern können. 

Erstellen Sie nicht zu viele Microservices, indem Sie sie zu klein machen

Wenn Sie bei Microservices zu weit mit dem „Micro“ gehen, könnten Sie leicht einen Mehraufwand und eine Komplexität erhalten, die die Gesamtvorteile einer Microservice-Architektur überschatten. Es ist besser, sich auf größere Dienste zu konzentrieren und diese erst dann aufzuteilen, wenn sie Eigenschaften entwickeln, für die Microservices eine Lösung bieten – nämlich wenn es schwierig und zeitaufwendig wird, Änderungen bereitzustellen, ein gemeinsames Datenmodell zu komplex wird oder wenn verschiedene Teile des Dienstes unterschiedliche Anforderungen an die Last/Skalierung haben.

Verwandeln Sie Microservices nicht in SOA

Microservices und SOA werden oft miteinander verwechselt, da beide auf der grundlegendsten Ebene daran interessiert sind, wiederverwendbare Einzelkomponenten zu erstellen, die von anderen Anwendungen genutzt werden können. Der Unterschied zwischen Microservices und SOA besteht darin, dass Microservice-Projekte in der Regel die Umgestaltung einer Anwendung beinhalten, damit sie einfacher zu verwalten ist, während es bei SOA darum geht, die Art und Weise zu ändern, wie IT-Services unternehmensweit funktionieren. Ein Microservice-Projekt, das in ein SOA-Projekt umgewandelt wird, wird wahrscheinlich unter seinem eigenen Gewicht zusammenbrechen.

Versuchen Sie nicht, Netflix zu sein

Netflix zählte zu den Pionieren der Microservice-Architektur, als das Unternehmen eine Anwendung entwickelte und verwaltete, die ein Drittel des gesamten Internetverkehrs ausmachte – eine Art „perfekter Sturm“, der es erforderlich machte, dass das Unternehmen viele benutzerdefinierte Codes und Dienste entwickelte, die für eine durchschnittliche Anwendung nicht notwendig sind. Es ist viel besser, mit einem Tempo zu beginnen, das Sie bewältigen können, Komplexität zu vermeiden und so viele Standardtools wie möglich zu verwenden.

Wenn Sie mehr über die Verwendung von Microservices erfahren möchten oder Ihre Kenntnisse über Microservices erweitern möchten, probieren Sie eines dieser Tutorials aus:

• Einführung in Microservices
  
• Kurzübung: Erstellen Sie hoch skalierbare Microservices für Webanwendungen mit Node.js
  
• Erste Schritte mit Java Microservices mit Spring Boot und Cloudant
  
• Erstellen, Ausführen und Bereitstellen von Spring Microservices in fünf Minuten
  
• Microservices, SOA und APIs: Freunde oder Feinde?