Herausforderung Software-Architektur

Microservices unter Beobachtung

21.12.2017
Von 


Karsten Flott ist seit 15 Jahren als Sales Engineer in der B2B-IT-Branche tätig. In seiner Laufbahn bei den Software-Unternehmen Compuware und AppDynamics, hat er sich intensiv mit Soft- und Hardware-Lösungen beschäftigt, die DevOps-, Analytics- und Application-Performance-Management-Prozesse verbessern. Sein Expertenwissen fand bereits in zahlreichen deutschen IT-Fachmedien Gehör.
Eine effiziente Software-Entwicklung wird immer mehr zum zentralen Erfolgsfaktor. Um sie zu gewährleisten, setzen viele Firmen auf Microservice-Architekturen. In der Theorie erleichtert das der IT die Arbeit, aber in der Praxis birgt die Einführung von Microservices auch enorme Herausforderungen. Was müssen Unternehmen also tun, um nicht im Chaos zu versinken?

Die digitale Transformation stellt Unternehmen vor immer neue Herausforderungen, denn der technische Fortschritt erfordert eine fortwährende Anpassung der Geschäftsprozesse. Zugleich sind auch die Erwartungen von Kunden und Fachabteilungen in die Höhe geschnellt. Sie erwarten, dass neue Anwendungen oder Funktionen binnen kürzester Zeit bereitstehen.

Unser Körper ist darauf ausgerichtet, auch bei Mikroorganismen immer den Überblick über das große Ganze zu haben. Eine ähnliche Strategie sollten IT-Verantwortliche haben, wenn sie mit Microservices arbeiten.
Unser Körper ist darauf ausgerichtet, auch bei Mikroorganismen immer den Überblick über das große Ganze zu haben. Eine ähnliche Strategie sollten IT-Verantwortliche haben, wenn sie mit Microservices arbeiten.
Foto: Alexey Godzenko - shutterstock.com

Vorreiter wie Amazon oder Netflix führen mehrere tausend Deployments pro Tag durch. Dazu arbeiten die Anbieter nicht mehr mit traditionellen Monolithen sondern setzen auf Microservices. Es handelt sich dabei um eigenständige Software-Module, die nur eine einzige Funktion umfassen. Erst wenn sie über APIs mit anderen Microservices verbunden werden, ergibt sich die Gesamtfunktionalität einer Anwendung. Bei einem Onlineshop könnte das etwa bedeuten, dass Katalog, Produktsuche, Bestellung, Warenkorb oder Bezahlung unabhängig voneinander entwickelt werden.

Da Microservices klar voneinander abgegrenzt sind, lassen sie sich einzeln bereitstellen und problemlos austauschen. Wird ein einzelner Service verändert, bleiben die Verfügbarkeit und die Funktionalität anderer Services davon unberührt. So sind regelmäßige Updates einzelner Funktionalitäten möglich, ohne dass die gesamte Anwendung aktualisiert werden muss. Im Ergebnis entstehen Anwendungen, die sich im stetigen Fluss befinden. Über fortwährende Verbesserungen einzelner Komponenten bleibt sichergestellt, dass sie neuen Anforderungen stets gewachsen sind.

Container bilden die Basis

Als technische Basis der Microservices dienen Linux-Container wie Docker. Docker-Container enthalten den Microservice und die für sein Funktionieren erforderliche Laufzeitumgebung. So wird eine Ausführung in einem isolierten Prozessraum möglich. Konflikte mit anderen Microservices und Anwendungen können auf diese Weise effektiv ausgeschlossen werden.

Die Verpackung in einen Container sorgt außerdem dafür, dass die Anwendungen portabler und mobiler werden. Um sie auf Entwicklungs-, Test-, Produktions- oder Cloud-Umgebungen zu übertragen und auszuführen, ist keine Anpassung oder Installation mehr nötig.
udem schonen Container die System-Ressourcen, zum Beispiel den Speicher. Denn sie bringen im Gegensatz zu Hypervisor-basierten Virtualisierungslösungen kein Gast-Betriebssystem mit, sondern lassen sich direkt auf dem Host-Betriebssystem ausführen.

Umwälzung der IT-Organisation

Microservices sind zunächst einmal ein rein technisches Thema. Die Einführung im Unternehmen hat aber sehr schnell auch Auswirkungen auf Menschen und Prozesse – die gesamte IT-Organisation erfährt eine Umwälzung. Die neue Architektur beendet die oftmals seit Jahrzehnten praktizierte Bereitstellung von Anwendungen in festen Release-Zyklen.

Insbesondere Entwickler müssen ihre Arbeitsweise ändern: Sie organisieren sich jetzt in kleineren Teams und tragen über den gesamten Service-Lifecycle ihres Codes die volle Verantwortung. Somit müssen sie sich nicht mehr nur mit der Entwicklung auseinandersetzen, sondern auch mit Test und IT-Betrieb. Sie sorgen dafür, dass kleinere Funktionserweiterungen schnell in Produktion gehen, und sie erhalten noch während des Programmierens über automatische Tests schnelles Feedback über mögliche Fehler. Es handelt sich also um eine Umsetzung von DevOps-Methoden, die darauf abzielen, Entwicklung und IT-Betrieb enger zu verzahnen.

Microservices bringen damit ein Gesetz zur Durchsetzung, das der US-amerikanische Informatiker Melvyn Conway im Jahr 1967 aufgestellt hat: „Unternehmen, die Systeme entwerfen, sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Unternehmen abbilden.“ Im Falle von Microservices gilt: Wer seine Software in flexible, weitgehend unabhängig voneinander agierende Module einteilen will, der braucht auch flexible, weitgehend unabhängig voneinander agierende Entwickler-Teams.

Neue Komplexitäten

Dass eine solche Neuausrichtung der IT-Organisation mit Reibungsverlusten einhergehen kann, ist klar. Aber auch auf technischer Ebene sind mit der Einführung von Microservices einige Herausforderungen verbunden. Denn einerseits erleichtern Microservices die Skalierung von Anwendungen und machen ihre Weiterentwicklung flexibler.
Andererseits neigen sie dazu, sich unkontrolliert zu vermehren. Entwickler stellen schnell fest, dass neue Funktionalitäten sich am einfachsten über neue Microservices realisieren lassen. Und früher später müssen IT-Abteilungen dann eine Vielzahl an Services im Griff behalten und sicherstellen, dass diese die physische IT-Infrastruktur nicht in die Knie zwingen. Damit verlagert sich die Komplexität von den Services selbst auf die Orchestrierung und Koordination.

Die Aufgabe wird erschwert, weil Microservices wesentlich vielfältiger sind als traditionelle Software-Architekturen. Sie basieren auf unterschiedlichen Sprachen und Technologien, abweichenden Backends und einer Vielzahl von Web Service-basierten API-Aufrufen. Hinzu kommen Netzwerke und der Rest der physischen Infrastruktur als weitere mögliche Fehlerquellen. Die Microservices aber müssen funktionieren und die Kommunikation zwischen ihnen muss reibungslos ablaufen, damit es nicht zu Störungen und Ausfällen kommt. Das ist ein zentrales Problem, für das es einer technischen Lösung bedarf.

Ressourcen-Kontrolle

Um Transparenz über die Ressourcen-Auslastung zu erhalten und die End-to-End-Performance und Latenz von Business-Transaktionen zu messen, können Unternehmen entsprechende Monitoring-Tools zu Hilfe nehmen. Die Herausforderung liegt darin, nicht mehr einen großen Monolithen, sondern hunderte oder gar tausende von kleinen und heterogenen Systemen zu überwachen. Die Verantwortlichen müssen dabei nicht nur die einzelnen Microservices im Blick behalten, sondern benötigen auch Wissen über den gesamten Stack. Wer den Informationsfluss sowie die Abhängigkeiten zwischen den Systemen durchschaut, erhält ein zusammenhängendes Bild der Anwendung.

Monitoring-Tools für das Application Performance Management (APM) setzen hier an. Sie spüren die Endpunkte der Microservices automatisch auf, messen vordefinierte Kennzahlen wie die Menge der Service-Aufrufe pro Minute, behalten die Reaktionszeiten der einzelnen Anwendungskomponenten im Blick und schlagen bei Fehlern Alarm.

Weil jede Business-Transaktion nicht nur auf einem Microservice basiert, sondern auf das Ineinandergreifen vieler miteinander kommunizierender Komponenten angewiesen ist, müssen die Tools beides analysieren – die einzelnen Services und deren Zusammenspiel. So kann jedes Entwicklerteam an der Effizienz seiner eigenen Produkte arbeiten, während die IT-Verantwortlichen gleichzeitig das große Ganze im Blick behalten.