Das optimale System-Design Microservices – nicht ohne die richtige Infrastruktur

Microservices können aller Vorteile zum Trotz die grundlegende Infrastruktur komplexer machen, denn sie setzen einen höheren Automatisierungsgrad und eine operationelle Reife voraus. Wie also sieht eine ideale Infrastruktur für Microservices aus? Und wie betreibt man eine Microservice-Architektur?

Anbieter zum Thema

IBM Deutschland GmbH

Vogel IT-Medien GmbH

AixpertSoft GmbH

CA Deutschland GmbH

Microservices stützen sich auf einen Grundgedanken: Unabhängigkeit. Um sie aufrecht zu erhalten, muss jeder Microservice als autonomer Bestandteil einer Umgebung gut designt, entwickelt und releast werden – das hat Konsequenzen für die Gestaltung dieser Umgebung. Man könnte natürlich grundsätzlich einen physikalischen Server oder eine virtuelle Maschine pro Microservice einsetzen, doch das wäre nicht finanzierbar.

Der nächste Gedanke gilt Packaging Formaten wie JAR, WAR oder EAR, denn sie wurden für die Verteilung von Code und Ressourcen, also für alles, was unabhängige Applikationen ausmacht, entwickelt. Leider aber bieten diese Formate nicht genügend Modularität. Auch das Maß der Isolation reicht nicht, denn WAR-Files oder Gemfiles (für Ruby) teilen noch Systemressourcen wie Disk, Memory, Shared Libraries oder das Betriebssystem.

Der Königsweg: Container

Container bieten hier einen Ausweg: Sie basieren auf einer Linux Kernel Extension (LXC) und erlauben es, viele isolierte Linux-Umgebungen (Container) auf einem einzigen Linux-Host zu betreiben und den Betriebssystem-Kernel zu teilen.

Container bieten damit die ideale Einsatzumgebung für Microservices: Man kann Hunderte von ihnen auf einem einzigen Server oder in einer VM laufen lassen und dennoch eine hohe Isolation und Autonomie erreichen. Und dass Container weit über Linux-Umgebungen hinausreichen werden, ist nur eine Frage der Zeit.

Ein Paradebeispiel für Container-Lösungen ist derzeit Docker, das durch seine Kompatibilität überzeugt. Dazu bündelt man alle erforderlichen Abhängigkeiten mit den korrekten Versionsnummern. So können andere sie zuverlässig in jeder Cloud oder on-premises einsetzen, ohne sich über die Zielumgebung und Kompatibilität Gedanken zu machen.

Linux-Container nutzen eine Layered-Filesystem-Architektur – „Union Mounting“. Damit haben sie im Vergleich zu VMs eine extreme Erweiterbarkeit und Wiederverwendbarkeit. Erweiterungen ‚erben‘ die Veränderungen an der Grundlage, dem „Base Image“. Diese Konstruktion fördert kollaborative Entwicklung und macht die Teams effizienter. Zentralisierte Registries, Discovery Services und Community-orientierte Plattformen wie Docker Hub und GitHub erleichtern die schnelle Einsetzbarkeit noch weiter.

Service Discovery

Service Discovery ist ein System, mit dem man nachvollziehen kann, welcher Service gerade welche Kombination von IP- und Port-Adresse nutzt. Normalerweise laufen viele Services auf demselben Host. Damit wird es unmöglich, einen Microservice nicht einfach nur mit einer IP-Adresse anzusprechen – notwendig ist eine Kombination aus IP-Adresse (für den Host) und Port-Nummer. Service Discovery stellt zum Beispiel sicher, dass nicht mehrere Teams, die unabhängig voneinander Microservices auf einem geteilten Pool hosten müssen, dieselben Ports nutzen.

Um Service Discovery zu gewährleisten, gibt es mehrere Wege. Mit Docker Container kann man mit einer einfachen Docker Compose Konfiguration viele Microservices (und ihre Container) in eine zusammenhängende Applikation orchestrieren. Bleibt man damit auf einem einzigen Host (Server), erlaubt es diese Konfiguration den Microservices, sich gegenseitig zu finden und miteinander zu kommunizieren – was sich insbesondere bei lokaler Entwicklung oder schnellem Prototyping anbietet.

In Produktionsumgebungen wird es komplizierter: Die Anforderungen an Zuverlässigkeit und Redundanz machen es unwahrscheinlich, dass nur ein Docker-Host verwendet wird. Sollen die Services sehr unterschiedlich beansprucht werden, macht es Sinn, nur die hoch-belasteten Services auf einer Auswahl an Hosts laufen zu lassen. Auch Erwägungen in Richtung Security oder Business legen nahe, manche Services auf dedizierten Hosts zu betreiben und andere anderswo.

Es gibt dafür einige Lösungen mit unterschiedlichem Automatisierungs- und Abstraktionsgrad am Markt – Kubernetes von Google dürfte wohl das bekannteste sein. Statt vorzugeben, welcher Container auf welchen Servern läuft, bestimmen diese Tools, wie viele Ressourcen aus dem Host-Pool für einen bestimmten Service zur Verfügung stehen sollen. Die Lösung übernimmt das Balancing/Rebalancing der Container auf den Hosts auf Basis dieser Kriterien. Im Extremfall wird das gesamte Service-Cluster fast wie ein einziger Superserver betrieben.

Skalierbar – aber wie?

In einer Container-Umgebung ist horizontale Skalierbarkeit bereits gegeben. Dafür sorgt das Entkoppeln von Applikationen in multiple Container hinein – mit dem Nebeneffekt der einfacheren, erneuten Nutzung von Containern.

Die (Teil-)Nutzung der Cloud hat dabei noch einen weiteren Effekt: Sollte ein Teil des Systems oder ein Microservice unter extrem hoher Last stehen, kann man diesen Teil in eine Umgebung mit mehr Ressourcen in die Cloud schieben, ohne die Hardware-Kapazität für das gesamte System zu skalieren. Man kann so genau auswählen, welche Funktionen on-premises und welche Cloud-basiert sein können. Das spart Geld und bietet eine weitgehende Flexibilität.

Gesichert mit einem API-Gateway

Mit einer Microservice-Architektur kann eine außerordentlich hohe Flexibilität erreicht werden. In Unternehmen mit einem vollentwickelten Microservice-Konzept, deren Architektur für komplexe Unternehmensanwendungen ausgelegt ist, ist es ganz normal, dass hunderte Microservices bereitgestellt werden. In diesem Fall spielt Security eine entscheidende Rolle.

Bei nahezu allen Microservice-Implementierungen werden API-Endpunkte von verschiedenen Microservices bereitgestellt, die über ein entsprechendes API-Gateway gesichert werden. Die von den Microservices bereitgestellten APIs können sich gegenseitig aufrufen, sind von (öffentlichen) Front-End-APIs aufrufbar oder können direkt von API-Clients wie mobilen Anwendungen, Webanwendungen und Partnersystemen aufgerufen werden.

Ein API-Gateway ist eine zentrale Komponente einer Microservice-Architektur und dient als Brücke zwischen Service-Implementierung und allen sie nutzenden Clients. API-Gateways bieten:

• Regelbasierte Sicherheit für die Vielzahl der APIs

• Orchestrierung über anwenderfreundliche Konfiguration API-Interfaces, die die eigentliche Granularität der Anfragen an Microservices verstecken. Das APS-Gateway arbeitet parallel und bietet so schnelle und effiziente Aggregierung.

• Routings von einer Client-App zu einem Microservice. Ein API-Gateway kann eine Schnittstelle bieten über http oder DNS Schnittstellen, wenn eine externe URI, die mit dem Microservice verbunden ist, angefragt wird.

Ständig überwacht

In einer Microservice-Architektur verändert sich dauernd etwas. Es ist deshalb essenziell, systemweit zu monitoren und Fehlerkaskaden zu vermeiden. Service Discovery Tools bieten meist auch diese Funktionalitäten. Sie wissen beispielsweise, welche Container es für einen bestimmten Service gibt, bemerken einen fehlerhaften Service und erlauben es, jeden auf seine Funktionsfähigkeit zu untersuchen.

Im „Pull“-Modus prüft eine solche Lösung, ob der Microservice antwortet oder die gewünschten Antwortdaten liefert. Im „Push“-Modus übergibt der Microservice aktiv eine vordefinierte Payload an das Tool und „meldet sich so gesund“ – was vor allem dann interessant ist, wenn bestimmte Services zu einer festgesetzten Zeit laufen müssen. Sind die Health-Checks aufgesetzt, kann auch eine Alerting-Funktion mit ausgefeilten Reaktionsbäumen dahinter gehängt werden.

Fazit

Georg Lauer

Gute Systemarchitektur ist eine wesentliche Grundlage für den Erfolg einer Microservice-Umgebung. Und doch muss auch sie so dynamisch sein wie der Ansatz selbst. Dynamik ist einer der großen Vorteile von Microservices, denn Veränderungen sind weder teuer noch aufwändig. Entsprechend wäre es auch ein Fehler, bestimmte Ressourcen nur für eine gewisse Zeit freizugeben: Microservices sind ein Weg, der von allen immer weiter gegangen werden muss.

Auch sollte man berücksichtigen, dass die Technik nur ein Spiegel der Organisation ist. Es empfiehlt sich also, erst das eigene Unternehmen zu hinterfragen. Auf diesen Punkt werden wir in unserem folgenden, letzten Beitrag eingehen.

* Georg Lauer ist als Senior Principal Business Technology Architect bei CA Technologies tätig.

(ID:45189703)