Microservices sind wahrscheinlich bei Führungskräften und Projektleitern mindestens genauso beliebt wie bei Entwicklern. Dies ist eine der etwas ungewöhnlicheren Eigenschaften von Microservices, da Begeisterung für eine bestimmte Architektur normalerweise nur in Softwareentwicklungsteams zu finden ist. Der Grund dafür ist, dass Microservices besser die Art und Weise widerspiegeln, wie viele Führungskräfte in Unternehmen ihre Teams und Entwicklungsprozesse strukturieren und einsetzen wollen.

Anders ausgedrückt: Microservices sind ein Architekturmodell, das die Umsetzung des gewünschten Betriebsmodells einfacher macht. In  einer aktuellen Umfrage von IBM mit über 1.200 Entwicklern und IT-Managern waren sich 87 % der Nutzer von Microservices einig, 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ängig voneinander bereitstellbar

Die vielleicht wichtigste Eigenschaft von Microservices ist, dass die Services kleiner sind und unabhängig voneinander bereitgestellt werden können, so dass es nicht mehr erheblichen Aufwand bedeutet, eine Codezeile zu ändern oder eine neue Funktion in die Anwendung einzufügen.

Microservices versprechen Unternehmen ein Gegenmittel für das hohe Frustpotenzial in Verbindung mit kleinen Änderungen, die extrem viel Zeit beanspruchen. Man braucht keinen Doktortitel in der Informatik, um den Wert eines Ansatzes, der Geschwindigkeit und Agilität besser unterstützt, zu sehen oder zu verstehen.

Aber Geschwindigkeit ist nicht der einzige Vorteil dieser Art der Servicegestaltung. Ein oft anzutreffendes, neu entstehendes Organisationsmodell besteht darin, funktionsübergreifende Teams rund um ein Geschäftsproblem, eine Dienstleistung oder ein Produkt zusammenzubringen. Das Microservices-Modell passt gut zu diesem Trend, da es einer Organisation ermöglicht, kleine, funktionsübergreifende Teams um einen Service oder eine Sammlung von Services herum zu bilden und sie auf agile Art und Weise arbeiten zu lassen.

Da Microservices nur lose miteinander verknüpft sind, ist automatisch auch ein gewisses Maß an Fehlerisolierung und bessere Ausfallsicherheit in Anwendungen gegeben. Und die geringe Größe der Services, verbunden mit ihren klaren Grenzen und Kommunikationsmustern, macht es neuen Teammitgliedern leichter, die Codebasis zu verstehen und schnell zu ihr beizutragen – ein klarer Vorteil in Bezug auf Geschwindigkeit und Mitarbeitermoral.

Das richtige Werkzeug für den Job

In traditionellen n-Tier-Architekturmustern teilt sich eine Anwendung normalerweise einen gemeinsamen Stack, wobei eine große relationale Datenbank die gesamte Anwendung unterstützt. Dieser Ansatz hat mehrere offensichtliche Nachteile – und der Hauptnachteil ist, dass jede Komponente einer Anwendung einen gemeinsamen Stack, ein gemeinsames Datenmodell und eine gemeinsame Datenbank nutzen muss, selbst wenn es für bestimmte Elemente ein Werkzeug gibt, das eindeutig besser für diese Aufgabe geeignet ist. Das führt zu einer schlechten Architektur, und es ist frustrierend für Entwickler, die sich ständig bewusst sind, dass es einen besseren, effizienteren Weg zur Erstellung dieser Komponenten gibt.

Im Gegensatz dazu werden in einem Microservices-Modell die Komponenten unabhängig voneinander bereitgestellt und kommunizieren über eine Kombination aus REST, Ereignis-Streaming und Nachrichtenbrokern. Und daher kann der Stack jedes einzelnen Services für diesen Service optimiert werden. Die Technologie wandelt sich ständig, und eine Anwendung, die aus mehreren, kleineren Services besteht, lässt sich wesentlich einfacher und kostengünstiger mit besseren Technologien weiterentwickeln, sobald diese verfügbar sind.

Präzise Skalierung

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

Es gibt auch Herausforderungen

Die wichtigsten Vorteile aus dem Einsatz von Microservices sind mit erheblichen Herausforderungen verbunden. Die Umstellung von monolithischen Anwendungen auf Microservices bringt erheblich höhere Komplexität beim Management mit sich – erheblich mehr Services, die von erheblich mehr Teams erstellt und an erheblich mehr Orten bereitgestellt werden. Probleme in einem Service können Probleme in anderen Services verursachen oder von diesen verursacht werden. Protokolldaten (die für Überwachung und Problemlösung verwendet werden) sind umfangreicher und können außerdem zwischen verschiedenen Services inkonsistent sein. Neue Versionen können Probleme mit der Abwärtskompatibilität verursachen. Anwendungen sind mit mehr Netzwerkverbindungen verbunden, was zusätzliche Möglichkeiten für Latenz- und Konnektivitätsprobleme verursachen kann. Eine DevOps-Lösung (wie weiter unten zu lesen) kann viele dieser Probleme beheben, aber die Einführung von DevOps bringt eigene Herausforderungen mit sich.

Dennoch halten diese Herausforderungen Nichtbenutzer nicht davon ab, Microservices einzuführen – oder hindern Anwender nicht daran, ihre Bemühungen hinsichtlich Microservices zu vertiefen. Neue IBM Umfragedaten belegen, dass 56 % der derzeitigen Nichtbenutzer in den nächsten zwei Jahren wahrscheinlich oder sehr wahrscheinlich Microservices einführen werden, und 78 % der derzeitigen Nutzer von Microservices geben an, dass ihr Unternehmen wahrscheinlich mehr Zeit, Geld und Aufwand in Microservices investieren wird.

Während im Prinzip jedes moderne Tool oder jede moderne Sprache in einer Microservices-Architektur verwendet werden kann, gibt es eine Handvoll wichtiger Tools, die essentiell geworden sind und definitorisch an Microservices angrenzen:

Container, Docker und Kubernetes

Eines der wichtigsten Merkmale eines Microservice ist, dass er im Allgemeinen recht klein ist. (Es gibt keine beliebige Codemenge, die bestimmt, ob etwas ein Microservice ist oder nicht, aber das „micro“ ist nicht umsonst im Namen enthalten.)

Als Docker 2013 die Ära des modernen Containers einleitete, wurde damit auch das Rechenmodell eingeführt, das mit Microservices am stärksten in Verbindung gebracht werden sollte. Da einzelne Container nicht über den Systemaufwand ihres eigenen Betriebssystems verfügen, sind sie kleiner und schlanker als herkömmliche virtuelle Maschinen und können schneller den Betrieb aufnehmen und beenden. Das macht sie zur perfekten Ergänzung für kleinere Services mit weniger Speicherbedarf, die in Microservices-Architekturen zu finden sind.

Mit der Verbreitung von Services und Containern wurde die Orchestrierung und Verwaltung großer Containergruppen schnell zu einer der kritischen Herausforderungen. Kubernetes, eine Open-Source-Plattform für Containerorchestrierung, hat sich zu einer der beliebtesten Orchestrierungslösungen entwickelt, weil sie sich hervorragend bewährt hat.

API-Gateways

Microservices kommunizieren häufig über API, insbesondere beim erstmaligen Feststellen des Zustands. Es stimmt zwar, dass Clients und Services direkt miteinander kommunizieren können, aber API-Gateways stellen oft eine nützliche Zwischenschicht dar, insbesondere da die Anzahl der Services innerhalb einer Anwendung im Laufe der Zeit zunimmt. Ein API-Gateway fungiert als Reverse Proxy für Clients, weil er Anforderungen weiterleitet, sie über mehrere Services hinweg ausfächert und zusätzliche Sicherheit und Authentifizierung bereitstellt.

Es gibt mehrere Technologien, die für die Implementierung von API-Gateways, einschließlich API-Management-Plattformen, verwendet werden können. Wenn jedoch die Microservices-Architektur mit Containern und Kubernetes implementiert wird, erfolgt die Implementierung des Gateways in der Regel mit Ingress oder neuerdings mit Istio.

Messaging und Event Streaming

Es wäre vielleicht das beste Verfahren, zustandsunabhängige Services zu konzipieren, dennoch existiert der Zustand, und Services müssen ihn beachten. Und obwohl ein API-Aufruf oftmals eine effektive Methode ist, den Zustand für einen bestimmten Service zu etablieren, ist es keine besonders effektive Möglichkeit, um auf dem neuesten Stand zu bleiben. Der permanente „Sind wir schon da?“-Abruf, um die Services auf dem neuesten Stand zu halten, ist einfach nicht praktikabel.

Stattdessen ist es erforderlich, die API-Aufrufe zur Feststellung des Zustands mit Messaging oder Ereignis-Streaming zu koppeln, damit die Services Änderungen im Zustand übertragen können und andere interessierte Parteien auf diese Änderungen achten und sich entsprechend anpassen können. Diese Aufgabe eignet sich wahrscheinlich am besten für einen Mehrzwecknachrichtenbroker, aber es gibt Fälle, in denen eine Event-Streaming-Plattform, wie z. B. Apache Kafka, eine passende Wahl sein könnte. Und durch die Kombination von Microservices mit ereignisgesteuerter Architektur können Entwickler dezentralisierte, hoch skalierbare, fehlertolerante und erweiterbare Systeme erstellen, die sehr große Mengen an Ereignissen oder Informationen in Echtzeit nutzen und verarbeiten können.

Serverlos

Serverlose Architekturen verwenden für ihre logischen Schlussfolgerungen einige der zentralen Cloud- und Microservices-Muster. Bei „Serverlos“ ist die ausführende Einheit nicht nur ein kleiner Service, sondern eine Funktion, die oftmals lediglich aus wenigen Zeilen Code besteht. Die Linie, die serverlose Funktionen von Microservices trennt, ist verschwommen, aber Funktionen sind im Allgemeinen sogar kleiner als Microservices.

Die Schnittstelle der Affinität von serverlosen Architekturen und Functions-as-a-Service-Plattformen (FaaS) mit Microservices ist, dass beide daran interessiert sind, kleinere Bereitstellungseinheiten zu erstellen und präzise in Übereinstimmung mit der Nachfrage zu skalieren.

Microservices sind nicht zwangsläufig ausschließlich relevant für Cloud-Computing, aber es gibt einige wichtige Gründe, warum sie so häufig Hand in Hand gehen – Gründe, die darüber hinausgehen, dass Microservices ein beliebter Architektur-Stil für neue Anwendungen sind und die Cloud ein beliebtes Hosting-Ziel für neue Anwendungen darstellt.

Zu den primären Vorteilen der Microservices-Architektur gehören die Auslastung und Kostenvorteile, die mit der individuellen Bereitstellung und Skalierung von Komponenten verbunden sind. Obwohl diese Vorteile noch in gewissem Maße mit einer On-Premises-Infrastruktur vorhanden wären, stellt die Kombination von kleinen, unabhängig skalierbaren Komponenten, die mit einer nutzungsorientierten On-Demand-Infrastruktur verbunden sind, die Basis für reelle Kostenoptimierungen dar.

Zweitens, und vielleicht noch wichtiger, ist ein anderer primärer Vorteil von Microservices, nämlich dass jede einzelne Komponente den Stack nutzen kann, der sich für den jeweiligen Job am besten eignet. Die zunehmende Verbreitung von Stacks kann bei Selbstverwaltung zu schwerwiegender Komplexität und Systemaufwand führen, der Verwaltungsaufwand lässt sich jedoch drastisch minimieren, wenn der unterstützende Stack als Cloud-Service genutzt wird. Anders formuliert: Es ist zwar nicht unmöglich, eine eigene Microservices-Infrastruktur umzusetzen, aber es ist nicht ratsam, insbesondere, wenn man gerade am Anfang steht.

Innerhalb von Microservices-Architekturen gibt es viele allgemeine und nützliche Design-, Kommunikations- und Integrationsmuster, die dazu beitragen, einige der häufigeren Herausforderungen und Chancen anzugehen, wie z. B.:

Backend-for-Frontend-Muster (BFF). Dieses Muster fügt eine Schicht zwischen dem Benutzererlebnis und den Ressourcen ein, auf denen das Erlebnis beruht. Eine App, die auf einem Desktop verwendet wird, verfügt beispielsweise über eine andere Bildschirmgröße, Anzeige und Leistungsgrenzen als bei Nutzung eines mobilen Geräts. Das BFF-Muster ermöglicht es Entwicklern, einen Back-End-Typ pro Benutzerschnittstelle mit den besten Optionen für diese Schnittstelle zu erstellen und zu unterstützen, anstatt zu versuchen, ein generisches Back-End zu unterstützen, das mit jeder beliebigen Schnittstelle arbeitet, jedoch die Frontend-Leistung negativ beeinflussen kann.

Entitäts- und Aggregat-Muster. Eine Entität ist ein Objekt, das sich durch seine Identität auszeichnet. Auf einer E-Commerce-Site kann z. B. ein Produktobjekt durch Produktnamen, Typ und Preis unterschieden werden. Ein Aggregat ist eine Sammlung zusammengehöriger Entitäten, die als eine Einheit behandelt werden sollen. Für die E-Commerce-Site wäre also eine Bestellung eine Sammlung (Aggregat) von Produkten (Entitäten), die von einem Käufer bestellt wurden. Diese Muster werden verwendet, um Daten in aussagekräftigen Methoden zu klassifizieren.

Serviceerkennungs-Muster. Diese Hilfsanwendungen und -services finden einander. In einer Microservices-Architektur ändern sich Serviceinstanzen dynamisch und abhängig von Skalierung, Upgrades, Servicefehlern und sogar Servicebeendigung. Diese Muster stellen Erkennungsmechanismen bereit, um diese Flüchtigkeit zu bewältigen. Lastausgleich kann Serviceerkennungsmuster verwenden, indem Statusprüfungen und Servicefehler als Auslöser für die Neuverteilung des Datenverkehrs verwendet werden.

Adapter-Microservices-Muster. Denken Sie bei Adaptermustern an Steckeradapter, die Sie bei der Reise in ein anderes Land verwenden. Der Zweck von Adaptermustern besteht darin, zu helfen, Beziehungen zwischen Klassen oder Objekten zu übersetzen, die andernfalls nicht kompatibel sind. Eine Anwendung, die auf APIs anderer Anbieter angewiesen ist, muss möglicherweise ein Adaptermuster verwenden, um sicherzustellen, dass die Anwendung und die APIs miteinander kommunizieren können.

Strangler-Anwendungsmuster. Diese Muster unterstützen die Umstrukturierung einer monolithischen Anwendung in Microservices-Anwendungen. Der anschauliche Name (zu deutsch „Würger“) bezieht sich darauf, wie sich eine Weinrebe (Microservices) langsam und allmählich um einen Baum (eine monolithische Anwendung) windet und ihn umschlingt.

Weitere Informationen über diese Muster erhalten Sie in „Verwendung von Entwicklungsmustern mit Microservices (Teil 4)“. IBM Developer bietet auch zahlreiche Informationen, wenn Sie mehr über andere Microservices-Codemuster erfahren möchten.

Es gibt zwar zahlreiche Muster für die erfolgreiche Bereitstellung von Microservices, jedoch besteht eine ebenso signifikante Anzahl von Mustern, die jedes Entwicklerteam schnell in Schwierigkeiten bringen können. Einige von ihnen – bei Microservices als „Don'ts“ bezeichnet – lauten wie folgt:

Die erste Regel von Microservices ist, keine zu erstellen. Genauer gesagt, starten Sie nicht mit Microservices. Microservices sind eine Methode, um Komplexität zu verwalten, sobald die Anwendungen zu groß und unübersichtlich geworden sind, um sie auf einfache Weise aktualisieren und warten zu können. Erst wenn sich langsam die monolithische Schwerfälligkeit und Komplexität ausbreitet, wird es erwägenswert, diese Anwendung in kleinere Dienste umzustrukturieren. Solange dieser Schmerzpunkt nicht erreicht wurde, ist es kein Monolith, der einer Umstrukturierung bedarf.

Keine Microservices ohne DevOps- oder Cloud-Services. Microservices zu erstellen bedeutet, verteilte Systeme zu erstellen, und verteilte Systeme sind schwierig (und sie sind besonders schwierig, wenn Sie Entscheidungen treffen, die es noch schwieriger machen). Wenn man versucht, Microservices ohne a) eine geeignete Implementierung und Überwachung auszuführen oder b) nicht über Managed Cloud-Services verfügt, um die nunmehr ausufernde, heterogene Infrastruktur zu unterstützen, drohen Ihrem Unternehmen dadurch eine Menge unnötiger Probleme. Sparen Sie sich den Ärger, damit Sie Zeit haben, sich über den Zustand Gedanken zu machen. 

Nicht zu viele Microservices, indem sie zu klein werden. Wenn Sie das „Micro“ in Microservices zu wörtlich nehmen, werden Sie womöglich schnell mit Systemaufwand und Komplexität konfrontiert, die den Gesamtnutzen der Bereitstellung einer Microservices-Architektur überwiegen. Es ist besser, größere Services zu verwenden und diese dann erst aufzubrechen, wenn sie beginnen, Eigenschaften zu entwickeln, die sich mit Microservices lösen lassen. Beispielsweise wenn es schwierig wird, Änderungen zu implementieren, wenn ein gemeinsames Datenmodell zu komplex wird oder wenn verschiedene Servicebestandteile unterschiedliche Anforderungen an das Laden/Skalieren haben.

Microservices nicht in SOA umwandeln. Microservices und serviceorientierte Architektur (SOA) werden oft miteinander verbunden, da beide auf ihrer grundlegendsten Ebene an der Erstellung wiederverwendbarer Einzelkomponenten interessiert sind, die von anderen Anwendungen genutzt werden können. Der Unterschied zwischen Microservices und SOA besteht darin, dass Microservices-Projekte in der Regel die Umstrukturierung einer Anwendung zwecks einfacherer Verwaltung erfordern, während es bei SOA um die Änderung der Art und Weise geht, wie IT-Services unternehmensweit arbeiten. Ein Microservices-Projekt, das in ein SOA-Projekt umgewandelt wird, wird wahrscheinlich unter seinem eigenen Gewicht zusammenbrechen.

Nicht zu Netflix werden. Netflix war einer der frühen Pioniere der Microservices-Architektur beim Erstellen und Verwalten einer Anwendung, die ein Drittel des gesamten Internetverkehrs ausmachte – eine Art perfekter Sturm, der sie dazu brachte, eine Menge von benutzerdefiniertem Code und Services zu erstellen, die für die durchschnittliche Anwendung unnötig sind. Sie sind wesentlich besser damit beraten, in einem Tempo zu beginnen, das für Ihr Unternehmen angemessen ist. Vermeiden Sie Komplexität, und verwenden Sie so viele Standardtools wie möglich.

Wenn Sie bereit sind, mehr über die Verwendung von Microservices zu erfahren, oder wenn Sie auf Ihrem Know-how über Microservices aufbauen müssen, versuchen Sie es mit einem dieser Lernprogramme:

• Einführung in Microservices
  
  
• Quick Lab: Hochskalierbare Microservices für Webanwendungen mit Node.js erstellen
  
  
• Erste Schritte mit Java-Microservices mit Spring Boot und Cloudant
  
  
• Spring-Microservices in fünf Minuten erstellen, ausführen und implementieren
  
  
• Microservices, SOA und APIs: Freunde oder Feinde?