Bereitstellung von Rechenressourcen

Um Ressourcen gut nutzen zu können, hat sich im letzten Jahrzehnt Container-Technologie als gewinnbringendes Konzept herausgestellt. Hierbei werden einzelne Prozesse durch Linux-Kernel-Features voneinander abgekapselt, was eine gemeinsame Nutzung von Rechenressourcen durch voneinander unabhängige Prozesse erleichtert. Wesentlich für die Nutzung von Container-Technologie ist, dass einzelne Container jederzeit (etwa auf einem anderen Rechner) neu gestartet werden können, da so eine orchestrierte hohe Auslastung der verfügbaren Rechenzeit erreicht wird. Der de-facto-Standard für die Orchestrierung von Containern ist das Open-Source-System Kubernetes, das bei guter Konfiguration eine Schnittstelle für Entwickler zum einfachen Deployment von Containern (und anderen Ressourcen) bereitstellt.

Da eine gute Konfiguration eines Kubernetes-Clusters eine relativ komplexe Aufgabe ist, sollte hierfür ein spezialisiertes Team etabliert werden, dass sich unter anderem mit der Netzwerkarchitektur, Kommunikation zwischen Containern, Secret Management und grundlegendem Logging und Monitoring in Zusammenhang mit Kubernetes beschäftigt.

Netzwerk-Konnektivität

Die innere Einfachheit von Microservices wird dadurch erkauft, dass viel Komplexität in die Kommunikation zwischen Services verlagert wird. Dafür ist es wichtig, dass Microservices eine Netzwerkverbindung zueinander und in Richtung Internet aufbauen können. Die Verbindung sollte automatisch durch mTLS abgesichert werden. Diese Automatisierung kann am besten auch durch ein zentrales Infrastruktur-Team gewährleistet werden.

Auch grundlegende Allow-Lists für den Zugriff auf Services sollten durch die Microservice-Teams einfach eingerichtet werden können, und gegebenenfalls sollten aus Compliance-Gründen manche Netzwerkregeln durch das Infrastruktur-Team verbindlich festgesetzt werden. Die Kommunikation zwischen Microservices ist erheblich leichter zu erreichen, wenn die Infrastruktur bei einem einzelnen Cloud-Provider gehostet wird.

Persistenz

Microservice-Container sollten jederzeit neu gestartet werden können, ohne Daten zu verlieren. Das impliziert, dass persistente Datenhaltung außerhalb der Microservices stattfinden muss, typischerweise in Datenbanken oder in persistenten Volumes. Neben allgemeinen Schwierigkeiten wie Authentifizierung und Autorisierung, sowie der Konnektivität zu den Datenhaltungssystemen bestehen hier spezialisierte Herausforderungen wie die Erstellung von Daten-Backups und Snapshots, um die Wiederherstellbarkeit persistenter Daten gewährleisten zu können.

Für verschiedene Bedürfnisse sollten verschiedene Typen von Datenbanken zur Verfügung gestellt werden, aus denen Microservice-Teams auswählen können: etwa eine SQL-Datenbank, eine Dokumentendatenbank und ein Cache-System. Das ist wichtig, um die Technologieoffenheit bei der Umsetzung von Microservices zu gewährleisten, sodass die Microservice-Teams die beste Technologie für ihren Anwendungsfall auswählen können.

Die Bereitstellung von Datenbanken oder Volumes sollte möglichst automatisiert erfolgen, wofür eine enge Zusammenarbeit mit dem Kubernetes-Team notwendig ist.

API-Design

Je nach Microservice können die Anforderungen an die APIs zur Kommunikation mit dem Microservice sehr unterschiedlich sein. Dennoch kann es sinnvoll sein, gemeinsame Anforderungen an die API-Struktur (beispielsweise HATEOAS oder gRPC) zu stellen, die nur in begründeten Ausnahmefällen nicht berücksichtigt werden. Für HTTP-APIs kann OpenAPI eine gute Lösung für die Dokumentation darstellen.

Gegebenenfalls kann man sich dafür entscheiden, die Bereitstellung von OpenAPI-Spezifikationen für Microservices verpflichtend zu gestalten, sodass sich die Entwickler von Clients auf die Existenz dieser Spezifikationen verlassen können. In jedem Fall sollte ein gemeinsames Schema für die Dokumentation von APIs (inklusive Fehlerfällen) geschaffen werden, damit es einfacher wird, relevante Dokumentation zu finden.

Messaging

Asynchrone Kommunikation über Messaging-Systeme kann wesentlich dabei helfen, das Gesamtsystem resilient zu gestalten. Die durch die Asynchronität entstehende temporäre Inkonsistenz bei der Datenhaltung wird bewusst in Kauf genommen („Eventual Consistency“), um schnellere Requests und eine Entkopplung verschiedener Microservices zu erreichen.

Damit Kommunikation über Messaging zwischen verschiedenen Microservices funktioniert, sollte das Messaging-System selbst von einem zentralen Team bereitgestellt und verwaltet werden. Das Format der Messages sollte wie bei den APIs mithilfe eines gemeinsamen Schemas dokumentiert werden.

Authentifizierung und Autorisierung

Authentifizierung und Autorisierung sind zentrale Aufgaben, die nicht von einzelnen Microservice-Teams erledigt werden können. Hierfür sollte eine zentrale Lösung, beispielsweise basierend auf OpenID, bereitgestellt werden.

Zusammenfassung

Eine Microservice-Architektur kann gerade für komplexe Systeme eine gute Lösung sein, um schnell Verbesserungen am System sowie neue Features zu implementieren. Dadurch entstehen allerdings Abhängigkeiten zwischen Microservices und somit auch zwischen den Microservice-Teams.

Die hier beschriebenen Querschnittskonzepte helfen dabei, Konsistenz, Sicherheit und Effizienz in einem Microservice-Umfeld sicherzustellen.

Microservices werden durch die folgenden Eigenschaften charakterisiert:

• Single Purpose: Wie bei den Unix-Prinzipien sollte ein Microservice genau eine Aufgabe gut erfüllen.

• Encapsulation: Microservices haben das alleinige Eigentum an ihren Daten. Sie interagieren mit der Außenwelt über wohldefinierte Schnittstellen.

• Ownership: Ein einzelnes Team (bestenfalls bestehend aus 5-9 Personen) ist verantwortlich für einen Microservice über seine gesamte Lebenszeit.

• Autonomy: Das für den Microservice zuständige Team darf ohne Absprache zu jeder Zeit den Microservice bauen und deployen. Das Team ist frei in Implementationsentscheidungen.

• Multiple Versions: Es ist möglich, dass zur gleichen Zeit verschiedene Versionen eines Microservices existieren.

• Choreography: Es gibt kein zentralisiertes System, das einen Workflow orchestriert. Stattdessen ist jeder Microservice in der Lage sich selbstständig mit den Informationen zu versorgen, die er für seine Funktionalität braucht.

• Eventual consistency: Eine kurzzeitige Inkonsistenz von Daten zwischen Microservices ist akzeptiert, solange die Daten schließlich wieder konsistent werden.

Herausforderungen von Microservices

Microservices sind durch ihre innere Einfachheit generell besser skalierbar und leichter und schneller zu ändern als Monolithen, in denen die gesamte Logik in einem einzelnen Programm enthalten ist. Durch die kleinen Teams fühlen sich (und sind) Microservice-Teams deutlich stärker für den Erfolg ihrer Microservices verantwortlich, was häufig zu besseren Ergebnissen und Entscheidungen führt.

Microservices erleichtern Omnichannel-Lösungen durch geteilte Backend-Funktionalität, die von verschiedenen Benutzerschnittstellen konsumiert werden können.

Erhöhte Komplexität

Auf der Ebene einzelner Microservices schaffen wir uns durch den begrenzten Aufgabenbereich und die Kapselung eine einfache und schöne Welt, doch TANSTAAFL!³ Die innere Einfachheit von Microservices wird erkauft durch die erhöhte Komplexität in Bezug auf die Kommunikation zwischen Microservices sowie eine gewisse Redundanz: Da die Microservice-Teams vollständig für ihre Services verantwortlich sind (Ownership) und sie auch selbstständig deployen können (Autonomy), müssen sie technisch dazu in der Lage sein, dieses Deployment tatsächlich durchzuführen. Das schließt sowohl Kompetenzen in Bezug auf Cloud-Infrastruktur ein als auch die Ressourcen, die für den Betrieb der Infrastruktur notwendig sind.

Konkreter können wir uns einen Mailing-Service vorstellen, der dafür zuständig ist, Informationsmails über ein Produkt an Kunden zu versenden. Der Service muss im Laufe der Entwicklung gebaut und dann auch ausgeführt werden. Die dafür verwendeten Computer müssen die notwendige Konnektivität haben, um diese Aufgaben durchzuführen. Sobald der Service läuft, müssen andere Services dazu in der Lage sein, den E-Mail-Prozess in Gang zu setzen. Mögliche Wege hierfür sind beispielsweise ein Event-System, aus dem der Mailing-Service selbstständig (im Sinne der Eigenschaft Choreography) die für ihn relevanten Events herausfiltert und zu E-Mails weiterverarbeitet.

So ein Event-System oder Messaging-System muss aber zum einen bereitgestellt werden und zum anderen von verschiedenen Teams mit ihren jeweiligen Microservices genutzt werden können. Ein anderes denkbares Szenario wäre die Ansprache des Mailing-Services via REST-Schnittstelle. In diesem Fall muss der Client dazu in der Lage sein, über ein Netzwerk mit unserem Mailing-Service zu kommunizieren, und diese Verbindung muss so abgesichert sein, dass nur autorisierte Services Zugriff auf die Schnittstelle bekommen.

Zusammenfassung

Die beschriebenen Herausforderungen zeigen, dass es einige Punkte gibt, an denen wir serviceübergreifend für Einheitlichkeit sorgen sollten. Manche dieser Punkte werden wir in diesem Artikel genauer unter die Lupe nehmen. Elemente der Softwarearchitektur, die (potenziell) für mehrere Bausteine der Architektur (in unserem konkreten Fall also Microservices) relevant sind, nennt man Querschnittskonzepte.

Um Redundanz zu vermeiden, sollten solche Querschnittskonzepte in der übergreifenden Architekturdokumentation behandelt werden, unabhängig von den einzelnen Komponenten. Es ist wichtig, Querschnittskonzepte frühzeitig festzulegen, da eine Migration zu einem späteren Zeit viel Kapazität über alle Teams hinweg in Anspruch nimmt.