Was sind Microservices?

Microservices oder Microservice-Architektur ist ein cloudnativer architektonischer Ansatz, bei dem eine einzelne Anwendung aus vielen lose gekoppelten und unabhängig voneinander einsetzbaren kleineren Komponenten oder Diensten besteht.

Microservices:

• Verfügen über einen eigenen Technologie-Stack, einschließlich Datenbank und Datenverwaltungsmodell.
  
• Kommunizieren meist über eine Kombination aus Representational State Transfer (REST) APIs, Event Streaming und Message Brokern miteinander.
  
• Sind nach Geschäftsfunktion organisiert, wobei die Trennlinie zwischen den Diensten oft als begrenzter Kontext bezeichnet wird.

Während sich ein Großteil der Diskussion über Microservices um architektonische Definitionen und Merkmale drehte, lässt sich ihr Wert besser durch recht einfache geschäftliche und organisatorische Vorteile verstehen:

• Der Code kann einfacher aktualisiert werden – neue Funktionen oder Anwendungsmöglichkeiten können hinzugefügt werden, ohne die gesamte Anwendung zu verändern.
  
• Teams können verschiedene Stacks und verschiedene Programmiersprachen für verschiedene Komponenten verwenden.
  
• Komponenten können unabhängig voneinander skaliert werden, wodurch der Ausschuss und die Kosten reduziert werden, die mit der Skalierung ganzer Anwendungen verbunden sind, weil eine einzelne Funktion möglicherweise zu stark belastet wird.

Microservices können auch als Gegensatz von zwei vorhergehenden Anwendungsarchitekturen verstanden werden: der monolithischen Architektur und der serviceorientierten Architektur (SOA).

Der Unterschied zwischen Microservices und einer monolithischen Architektur besteht darin, dass Erstere eine einzelne Anwendung aus vielen kleineren, lose gekoppelten Diensten zusammensetzen, im Gegensatz zum monolithischen Ansatz einer großen, eng gekoppelten Anwendung.

Die Unterschiede zwischen Microservices und SOA sind nicht ganz so eindeutig. Zwar lassen sich technische Gegensätze zwischen Microservices und SOA ausmachen, insbesondere im Hinblick auf die Rolle des Enterprise Service Bus, aber es ist einfacher, den Unterschied als einen der Reichweite zu betrachten. SOA war ein unternehmensweites Bestreben, die Art und Weise zu standardisieren, wie alle Webdienste in einem Unternehmen miteinander kommunizieren und sich integrieren, während die Microservices-Architektur anwendungsspezifisch ist.

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:

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 Microservice-Modell passt genau zu diesem Trend. Das Modell ermöglicht es einem Unternehmen, kleine, funktionsübergreifende Teams rund um einen Dienst oder eine Reihe von Diensten zusammenzustellen und sie flexibel 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.

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.

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.

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 Nichtnutzer wahrscheinlich oder sehr wahrscheinlich Microservices innerhalb der nächsten zwei Jahre einführen werden. Folglich werden 78 % der derzeitigen Microservice-Benutzer wahrscheinlich mehr Zeit, Geld und Aufwand in Microservices investieren.

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:

Obwohl in einer Microservices-Architektur fast jedes moderne Tool oder jede Sprache verwendet werden kann, gibt es eine Handvoll Kern-Tools, die für Microservices unverzichtbar und geradezu definierend geworden sind:

Eines der wichtigsten Faktoren eines Microservices ist, dass er klein ist. Es gibt keine willkürliche Menge an Code, die bestimmt, ob etwas ein Microservice ist oder nicht, aber „Micro“ steckt schon im Namen.

Als Docker 2013 das moderne Container-Zeitalter einläutete, führte es auch das Rechenmodell ein, das am engsten mit Microservices in Verbindung gebracht werden würde. Da einzelne Container nicht den Mehraufwand eines eigenen Betriebssystems haben, sind sie kleiner und leichter als herkömmliche Virtual Machines und können schneller hoch- und heruntergefahren werden, sodass sie perfekt zu den kleineren und leichteren Services passen, die in Microservice-Architekturen zu finden sind.

Mit der zunehmenden Verbreitung von Services und Containern wurde die schnelle Koordination und Verwaltung großer Containergruppen zu einer der entscheidenden Herausforderungen. Kubernetes, eine Open-Source-Plattform für die Orchestrierung von Containern, hat sich zu einer der beliebtesten Orchestrierungslösungen entwickelt, weil sie diese Aufgabe so gut erfüllt.

Microservices kommunizieren oft über API, insbesondere bei der erstmaligen Festlegung ihres Status. Zwar können Kunden und Dienste direkt miteinander kommunizieren, doch sind API Gateways oft eine nützliche Vermittlungsebene, insbesondere wenn die Anzahl der Dienste in einer Anwendung im Laufe der Zeit zunimmt. Ein API Gateway fungiert als Reverse-Proxy für Kunden, indem es Anfragen weiterleitet, Anfragen auf mehrere Dienste verteilt und zusätzliche Sicherheit und Authentifizierung bietet.

Es gibt mehrere Technologien, die zur Implementierung von API-Gateways verwendet werden können. Zu diesen Technologien gehören API Management-Plattform, aber wenn die Microservices-Architektur mithilfe von Containern und Kubernetes implementiert wird, wird das Gateway in der Regel mit Ingress oder neuerdings Istio implementiert.

Obwohl es sich bewährt hat, zustandslose Services zu entwerfen, gibt es dennoch einen Zustand und die Services müssen sich dessen bewusst sein. Und während ein API-Aufruf oft eine effektive Möglichkeit ist, den Status eines bestimmten Services zunächst zu ermitteln, ist er nicht besonders effektiv, um auf dem neuesten Stand zu bleiben. Eine ständige Umfrage, „Sind wir schon da?“ Der Ansatz, die Dienste auf dem neuesten Stand zu halten, ist nicht praktikabel.

Stattdessen ist es notwendig, API-Aufrufe zur Bestimmung des Zustands mit Messaging oder Event Streaming zu koppeln, damit die Services Statusänderungen rund um die Uhr senden können. Auf diese Weise können andere Stakeholder auf diese Änderungen achten und sich entsprechend anpassen. Diese Aufgabe ist wahrscheinlich am besten für einen universellen Message Broker geeignet, aber es gibt Fälle, in denen eine Plattform für Event Streaming, wie z. B. Apache Kafka, gut geeignet sein könnte. Und durch die Kombination von Microservices mit einer ereignisgesteuerten Architektur können Entwickler verteilte, hoch skalierbare, fehlertolerante und erweiterbare Systeme erstellen, die sehr große Mengen an Ereignissen oder Informationen in Echtzeit verarbeiten können.

Serverlose Architekturen führen einige der Kernmuster von Cloud- und Microservices zu ihrem logischen Abschluss. Im Fall von serverlos ist die Ausführungseinheit nicht nur ein kleiner Service, sondern eine Funktion, die oft nur aus ein paar Zeilen Code besteht. Die Grenze zwischen einer serverlosen Funktion und einem Microservice ist fließend, aber im Allgemeinen werden Funktionen als noch kleiner als ein Microservice angesehen.

Serverlose Architekturen und Function-as-a-Service-Plattformen haben mit Microservices gemeinsam, dass sie beide daran interessiert sind, kleinere Bereitstellungseinheiten zu erstellen und genau nach Bedarf zu skalieren.

Microservices sind nicht unbedingt ausschließlich für Cloud Computing relevant. Es gibt jedoch einige wichtige Gründe, warum sie so häufig zusammen gehören – Gründe, die darüber hinausgehen, dass Microservices ein beliebter Architekturstil für neue Anwendungen und die Cloud ein beliebtes Hosting-Ziel für neue Anwendungen sind.

Zu den Hauptvorteilen der Microservice-Architektur gehören die Nutzen und die Vorteile, die mit der einzelnen Bereitstellung und Skalierung der 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:

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.

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.

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.

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.

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:

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.

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.

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.

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.

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?