Bereitstellung nach dem Prinzip „Teile und herrsche“

Wo Microservice-Architekturen sinnvoll sind

| Autor / Redakteur: Filipe Pereira Martins & Anna Kobylinska / Stephan Augsten

Die abgegrenzten Serviceeinheiten in einer Microservices-Architektur müssen richtig interagieren und aufeinander abgestimmt werden.
Die abgegrenzten Serviceeinheiten in einer Microservices-Architektur müssen richtig interagieren und aufeinander abgestimmt werden. (Bild gemeinfrei: aitoff / Pixabay)

Leichtgewichtig, zustandslos und bedarfsgerecht skalierbar: Microservice-Architekturen haben es in sich. Gleichzeitig verändern sie die Art und Weise, wie Unternehmen ihre Software entwickeln und bereitstellen.

Der Markt für Microservice-basierte Lösungen boomt. Laut einer Prognose des Marktforschungsunternehmens Market Research Future (MRFR) vom August 2019 soll er bis 2023 eine CAGR (Compounded Annual Growth Rate) von etwa 25 Prozent verzeichnen. Bis zum Ende des Prognosezeitraums bedeutete dies ein Volumen von 2,15 Milliarden US-Dollar.

Startups wie Lyft haben ihre gesamte Anwendungsplattform als Microservices (Lyft setzt hierbei auf Kubernetes) ausgelegt und orchestrieren diese bedarfsabhängig und in der Cloud. IT-Häuser mit monolithischen Anwendungen haben diesen Trend zuerst einmal vorsichtig beobachtet und milde belächelt. Doch immer mehr Firmen mussten einsehen, dass althergebrachte Ansätze bei verteilten Anwendungen einfach zu kurz greifen.

Die führenden Entwicklungsframeworks für Microservices: Java-Entwickler setzen am liebsten auf Spring Boot.
Die führenden Entwicklungsframeworks für Microservices: Java-Entwickler setzen am liebsten auf Spring Boot. (Bild: Eclipse Foundation)

Einige Unternehmen wollen ihren Legacy-Code nun auf Biegen und Brechen auch in die Cloud bekommen. Microservice-Architekturen sind oft die erste Wahl. Bei der Implementierung von Cloud-basierten Java-Anwendungen greifen Unternehmen beispielsweise fast nur noch auf Microservices zurück, fand Eclipse Foundation in der aktuellen Jakarta EE Developer Survey heraus.

Leichtgewichtige Service-Einheiten

Der Begriff Microservice bezeichnet eine Cloud-native Technik der Softwareentwicklung, welche auf autarke, aufgabenspezifische, voneinander isolierte Kleinst-Anwendungseinheiten setzt. Diese Mikrodienste kommunizieren miteinander über APIs. Der Gedanke dahinter: „Teile und herrsche“.

Die beliebtesten IDEs für Cloud-native Anwendungen in Microservice-Architekturen: Mehr als jeder Zweite der befragten Java-Entwickler nutzt Eclipse und/oder IntelliJ IDEA, 28 Prozent setzen (auch) auf Visual Studio Code und nicht einmal jeder Fünfte Apache NetBeans
Die beliebtesten IDEs für Cloud-native Anwendungen in Microservice-Architekturen: Mehr als jeder Zweite der befragten Java-Entwickler nutzt Eclipse und/oder IntelliJ IDEA, 28 Prozent setzen (auch) auf Visual Studio Code und nicht einmal jeder Fünfte Apache NetBeans (Bild: Eclipse Foundation)

Die avisierte Applikation entsteht demnach als eine lose zusammenhängende Sammlung leichtgewichtiger Service-Einheiten, die miteinander über sprachagnostische Programmierschnittstellen kommunizieren. Beim Portieren bestehender Applikationen gilt es hierzu, die bestehende Codebasis in autarke Services aufzubrechen (zum Beispiel die Benutzerauthentifizierung, den Warenkorb, die Zahlungsabwicklung, etc.).

Diese sogenannten Microservices lassen sich dann in der Cloud via Code orchestrieren (also zur Laufzeit verwalten). So entsteht eine skalierbare, selbstheilende, Cloud-native Software. Im Grunde genommen handelt es sich bei Microservices um eine verteilte, Cloud-native Implementierung von SOA (Services Oriented Architecture).

Diagramm einer Microservices-Referenzarchitektur von Microsoft auf der Basis eines Kubernetes-Clusters in Microsoft Azure.
Diagramm einer Microservices-Referenzarchitektur von Microsoft auf der Basis eines Kubernetes-Clusters in Microsoft Azure. (Bild: Microsoft)

Microservice-Architekturen haben mit monolithischen Anwendungen konzeptionell nichts gemeinsam und bieten gegenüber konventionellen Web-Anwendungen eine Menge relevanter Vorteile. Dazu zählen:

  • Autonome Skalierbarkeit: Die einzelnen Bestandteile einer Microservice-Anwendung skalieren ganz individuell, um Kosten zu sparen und Ausfallzeiten zu reduzieren.
  • Service-Isolation: Der Lebenszyklus der einzelnen Microservice-Einheiten lässt sich unabhängig steuern; ein einzelner Bug kann niemals die gesamte Anwendung außer Betrieb setzen.
  • Flexibilität bei der Auswahl von Tools und Technologien: Die beteiligten Entwickler können für jeden Service einen anderen Ansatz befolgen, eine andere Programmiersprache wählen und eine andere Laufzeitumgebung bereitstellen; das erleichtert das Experimentieren mit neuen Ansätzen.
  • Kürzere Entwicklungszeiten: Die Bereitstellung neuer Anwendungskomponenten dauert nicht ganz so lange wie bei konventionellen Lösungen; mehrere verschiedene Teams können gleichzeitig an verschiedenen Diensten tüfteln, ohne sich gegenseitig in die Quere zu kommen.

Der größte Nachteil einer Microservice-Architektur besteht in dem hohen Aufwand der Orchestrierung der verschiedenen Infrastrukturelemente der Ausführungsumgebung. Nichts macht sich hier von selbst.

Anders als im Falle von Serverless-Funktionscode zeichnen die Entwickler von Microservices für die Gesamtlösung verantwortlich. Sie sind also sowohl für den Anwendungscode als auch für die Orchestrierung zuständig, denn nur so lässt sich die ununterbrochene Betriebsbereitschaft von Microservices gewährleisten.

Bei der Wahl der Programmiersprachen und Frameworks für Microservices besteht weitgehend Flexibilität. Die offizielle Referenzarchitektur von Nginx für Microservice-Anwendungen (kurz: MRA) erlaubt zum Beispiel den Einsatz einer Vielzahl von Programmier- und Skriptsprachen – von Java über PHP, Python und NodeJS bzw. JavaScript bis hin zu Ruby.

Alternativen zu Microservices beinhalten Ansätze wie Serverless und Mesosphere. In diesen beiden Fällen beschränken sich die Stellschrauben auf die APIs des Anbieters. Wer stattdessen auch noch das Betriebssystem seiner Laufzeitumgebung kontrollieren will, liegt bei Microservices genau richtig.

Interprozesskommunikation in verteilten Microservice-Architekturen

Eine der größten Änderungen im Anwendungsdesign beim Wechsel von monolithischen Architekturen zu Microservices betrifft die Kommunikation zwischen den verschiedenen Funktionskomponenten der Anwendung.

  • In monolithischen Apps erfolgen die Methoden- oder Funktionsaufrufe auf Sprachebene. Die verschiedenen Anwendungskomponenten kommunizieren im Arbeitsspeicher der jeweiligen Instanz miteinander. Diese Tatsache steht der Skalierbarkeit im Wege.
  • Microservices kommunizieren über das Netzwerk in IPC-Manier (Inter-Process Communication) via gut definierte APIs und machen sich hierbei eine Form der Serviceerkennung zu Nutze, zum Beispiel Kubernetes DNS.

Solange die Konnektivität funktioniert, ist praktisch jede beliebige Kombination der übrigen Elemente zulässig; auch die Integration mit Serverless-Komponenten lässt sich relativ leicht implementieren.

Die NGINX-MRA nutzt Docker-Container und NGINX‑gesteuerte Konnektivität. In der anspruchsvollsten Ausbaustufe, dem sogenannten Fabric Model, übernimmt NGINX die Kontrolle über die Kommunikation der Microservices unter Gewährleistung einer lückenlosen TLS-Verschlüsselung (dank persistenter Verbindungen möglich). Für das Konfigurationsmanagement zeichnet Apache ZooKeeper verantwortlich.

Etablierte Best-Practices für die Entwicklung von Microservices beinhalten etwa die folgenden Erkenntnisse:

  • Einzelne Microservices sind als autonome Softwareeinheiten zu handhaben; sie benötigen separaten Datenspeicher.
  • Einzelne Microservices im Rahmen einer Softwareanwendung sollten einen ähnlichen Reifegrad aufweisen, aber in separaten Builds kompiliert werden.
  • Server-Instanzen in Microservice-Architekturen sind immer als zustandslos zu behandeln.

Die Notwendigkeit zur sauberen Trennung von Microservices untereinander hat weitgehende Implikationen im Hinblick auf den Datenspeicher. In einer Microservices-Applikation sollte jeder Dienst seine eigenen privaten Daten in einem separaten logischen Speicher aufbewahren. Nur so lässt sich die Entstehung von versteckten Abhängigkeiten zwischen Diensten verhindern. Die gemeinsame Nutzung von Datenschemata würde die betreffenden Dienste de facto aneinander koppeln.

Stolperfallen

Trotz all ihrer Vorteile stellen Microservices deren Entwickler vor eine ganze Menge neuer Herausforderungen. Spätestens wenn es darum geht, die Abwicklung von Transaktionen in verteilten Anwendungen auf der Basis von Microservices zu implementieren, greifen bisherige Ansätze einfach zu kurz.

Die beliebtesten Ausführungs-Engines für Microservices: Nahezu acht von zehn der Entwickler in der Jakarta EE-Umfrage nutzen Docker, drei von vier (auch) Kubernetes.
Die beliebtesten Ausführungs-Engines für Microservices: Nahezu acht von zehn der Entwickler in der Jakarta EE-Umfrage nutzen Docker, drei von vier (auch) Kubernetes. (Bild: Eclipse Foundation)

RESTful-APIs sind einfach nicht dafür geeignet, robuste, fehlertolerante und elastisch skalierbare Microservices zu implementieren. Aspekte eines Deployments wie die Diensterkennung und die Lastverteilung zustandsloser Komponenten, die mit REST-Aufrufen einhergehen, bieten sich hierzu einfach nicht an.

Die abgegrenzten Serviceeinheiten in einer Microservices-Architektur (MSA) müssen miteinander effizient kommunizieren können. Dabei soll die Agilität und Elastizität der Anwendung gewahrt bleiben. Die Antwort auf diese Herausforderungen bietet eine Ereignisverarbeitung durch Messaging-Dienste.

Messaging-Dienste entkoppeln die einzelnen Microservices einer MSA voneinander: Nachrichten wandern stets durch eine Vermittlungsstelle (z.B. eine sogenannte Warteschlange oder einen Broker) – und zwar asynchron – an einen oder mehrere Empfänger. Die MSA gewinnt dadurch an Widerstandsfähigkeit und Elastizität.

Der Ausfall eines der Microservices führt nicht mehr zum Ausfall der gesamten Anwendung. Die Notwendigkeit der Verfügbarkeit von Diensterkennung (engl. service discovery) entfällt. Die resultierende Softwarelösung arbeitet Ereignis-getrieben, autonom und weist eine hohe Anpassungsfähigkeit auf.

Fazit

Cloud-native Anwendungen müssen bedarfsgerecht skalieren, Microservices bieten hierzu einen geeigneten Weg. In Microservice-Architekturen können sich kleine Teams von Entwicklern die Arbeit einfacher aufteilen und sich jeweils einem Teil der Funktionalität widmen. Das vereinfacht wiederum das Debugging und verkürzt die Time-to-Market. Microservices auf der Basis von Messaging-Diensten läuten das Aufkommen ereignisgetriebener Anwendungen ein. Es wird richtig spannend.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46149807 / Microservices)