Microservices in der Cloud

Vor dem Einsatz von Microservices sind grundlegende architekturelle Entscheidungen zu treffen. Für Micro­services spricht eine unabhängige Deploybarkeit der einzelnen Systemkomponenten, damit einhergehend eine eigenständige Entwicklung sowie verbesserte Wartbarkeit und Skalierbarkeit des resultierenden Gesamtsystems. Im Gegensatz zum Deployment-Monolithen ermöglicht der Ansatz der Microservices die explizite Umsetzung des Entwicklungsprinzips „Separation of Concerns“, also die Trennung der Zuständigkeiten in einzelne Deployment-Einheiten. Auch architekturelle Nachteile sind mit dem Microservice-Ansatz verbunden: Schlechtere Nachvollziehbarkeit, Komplexität der Tests im Zusammenspiel der einzelnen Services (etwa Umgang mit verteilten Transaktionen) und gegebenenfalls höhere Aufwände im Betrieb sind zu akzeptieren.

Der Begriff (Micro-)Service ist im Folgenden als eine Deployment-Einheit definiert, die ihren Dienst über eine API verrichtet (am weitesten verbreitet sind vermutlich RESTful APIs auf Basis von JSON via HTTP). Der Service arbeitet möglichst unter der Maßgabe einer 12-Faktor-Applikation, also wenn möglich ohne eigenen Zustand und konfigurierbar über Umgebungsvariablen. Je kleiner die Deployment-Einheit ist, desto leichter lässt sie sich in ihrem Lebenszyklus entwickeln, anpassen, testen, weiterentwickeln oder austauschen – solange die API stabil bleibt.

Solche Microservices lassen sich, wenn gewünscht, in Con­tainern standardisiert verpacken. Mit der Veröffentlichung von Docker im Jahr 2013 wurden die Vorteile von Isolation, Ausführbarkeit und konsistenter Umgebungen ohne den Einsatz einer schwergewichtigen Virtualisierungslösung weithin bekannt. Applikationsteile kann man in Containern mit nur geringem Aufwand in eigene, kleinteilige Services kapseln und in einer privaten oder öffentlichen Registry zur weiteren Nutzung zur Verfügung stellen. Docker hat dabei die Containerisierung nicht neu erfunden, sondern bereits vorhandene Techniken wie LXC neu verpackt und als Produkt erfolgreicher vermarktet.

Entwicklung von Microservices

Die Entwicklung von Microservices findet meist auf Basis von Frameworks wie Go kit, Spring Boot oder anderen statt. Da sich jede Deployment-Einheit losgelöst von den anderen entwickeln lässt, ist die Wahl des Frame­works nicht primär wichtig. Allerdings ist zu validieren, ob eine Gesamtarchitektur auf Basis mehrerer unterschiedlicher Frameworks zu errichten ist. Insbesondere ist zu prüfen, ob eine Heterogenität der verwendeten Frameworks mit vertretbarem Aufwand wart- und beherrschbar bleibt.

Microservices bieten den Vorteil, unabhängig und einfach lokal testbar zu sein. Weil CPU und Speicheransprüche pro Service häufig gering sind, kann bereits auf der Entwicklungsmaschine ein Großteil der Serviceverifikation erfolgen. Standard sind dabei Unit-Tests, API-Tests, statische Codeanalyse und weitere Testarten, die sich frühzeitig und lokal ausführen lassen. Jede Erkenntnis in der lokalen Testausführung, bestenfalls umfassend automatisiert und vom Entwickler selbst durchgeführt, beschleunigt und verbessert die Feedbackschleife für die Entwicklung.

Ist die Änderung der Funktionalität lokal getestet, muss man das korrekte Zusammenspiel zwischen den interagierenden Services prüfen. Zur Auslieferung werden im Optimalfall die Liefermethoden und -wege angewendet, die auch später in Richtung Produktion Anwendung finden. Schritt für Schritt oder Umgebung für Umgebung ist der Service auszurollen und Prüfungen zu unterziehen. Serviceübergreifende Tests, Antwortzeitmessung des Systemverbunds und technische Tests zur Stabilität garantieren die Qualität im größeren Kontext. Bestenfalls erfolgen diese Prüfungen automatisiert sowie mess- und reproduzierbar. Nur so ist quantifizierbar, ob eine vorgenommene Änderung positive oder negative Auswirkungen hat.

Umfangreiches Testen zur Qualitätssicherung erforderlich

Eine systemische Herausforderung in der Qualitätssicherung von Microservices ist die bewusste Entscheidung zwischen kontinuierlichen Tests einerseits sowie einem statischen Set von einmal laufenden Tests andererseits. Für eine übergreifende fachliche Qualitätssicherung ist ein definiertes Set von Testfällen (maßgeblich die zentralen Anwendungsfälle der Nutzer des Systems) sinnvoll. In einer Last- und Performanceumgebung sind einmalige Ausführungen natürlich nicht das Ziel. Hier sind ein generelles Grundrauschen und eine kontinuierliche Last aus Gründen der Verifikation von ausfallfreien Lieferungen und der Messung der Antwortzeiten unter Last wünschenswert.