Die traditionelle Art und Weise, monolithische Unternehmensanwendungen zu verwalten und zu erweitern wird mit deren zunehmender Größe und Komplexität problematisch. Der Umstieg auf Microservices bietet eine Lösung: Anwendungen werden dort als eine Sammlung von lose gekoppelten Services strukturiert. So können Dienste leichter erstellt, erweitert und skaliert werden. Doch wie genau unterscheidet sich eine Microservice- von einer monolithischen Architektur? Und welche Vorteile und Herausforderungen entstehen?

Mehr Flexibilität und Skalierbarkeit durch Microservices

Die Grundidee hinter einer Microservice-Architektur ist, dass Anwendungen einfacher zu erstellen und zu pflegen sind, wenn sie in kleine, nahtlos zusammenwirkende Teile zerlegt werden. Die Softwarefunktionalität wird in mehreren unabhängigen Modulen isoliert. Diese sind einzeln für die Ausführung genau definierter eigenständiger Aufgaben verantwortlich.

Die Module kommunizieren miteinander über einfache, universell zugängliche Application Programming Interfaces (APIs). Jeder Microservice kann eine andere Programmiersprache oder Datenbank nutzen, so dass neue Technologien jederzeit ausprobiert und eingebunden werden können. Außerdem lassen sich mit den Codebausteinen auch Legacy-Systeme erweitern, ohne dass allszu große Änderungen an deren Codebasis vorgenommen werden müsste.

Unternehmen gewinnen also durch Microservices ein Vielfaches an Flexibilität. Sie können schneller und zielgerichteter auf Veränderungen reagieren, Neues ausprobieren und Ressourcen einsparen. Da die einzelnen Bausteine voneinander isoliert sind, lässt sich jede Funktion so gestalten, dass sie sich an den unternehmensspezifischen Anforderungen und Kapazitäten orientiert.

So ist es möglich, viel genauer und effizienter zu skalieren. Möchte man zum Beispiel eine neue Funktionalität zu einer Applikation hinzufügen, muss man nicht die gesamte Applikation umbauen. Dieses Vorgehen ist nicht nur schneller, es sorgt auch für mehr Stabilität in der Anwendung.

Sollte ein neuer Softwarebaustein nicht richtig funktionieren oder ausfallen, ist davon nur dieser einzelne, relativ einfache Microservice betroffen - nicht die gesamte Anwendung. So kann es sich das Unternehmen leisten, mit neuen Prozessen oder Algorithmen zu experimentieren, ohne dabei viel verlieren zu können.

Microservices machen Fehlersuche einfacher

Bei monolithischen Architekturen stehen Entwickler oft vor dem Problem, dass sämtliche Funktionen und Erweiterungen auf demselben Basiscode aufbauen. Verschiedene Teams arbeiten unabhängig an bestimmten Funktionen und Aufgaben, doch es ist unvermeidbar, dass sie dabei immer wieder Teile des gemeinsamen Codes verändern. Jede Änderung betrifft auch immer mindestens ein Nachbar-Team.

In einer Microservice-Architektur besteht dieses Problem nicht. Jedes Entwickler-Team ist für eine bestimmte Anzahl an Microservices, manchmal auch nur für einen einzigen Microservice, zuständig. Die Codeblöcke sind durch APIs miteinander verbunden, teilen sich aber keinen gemeinsamen Basiscode. So können die einzelnen Teams freier agieren, tragen dabei aber größere Verantwortung für ihre Funktionen.

Zudem ist es möglich, kleinere Entwicklerteams zu bilden, die in ihrem Aufgabengebiet sehr flexibel agieren und sich vollständig auf die ihnen zugeteilten Microservices konzentrieren können. Das steigert die Produktivität.

Neu hinzustoßende Entwickler können schneller miteingebunden werden, denn es ist einfacher, kleine, isolierte Funktionalitäten zu verstehen als eine gesamte monolithisch aufgebaute Applikation. Die gesteigerte Produktivität wirkt sich auch auf die Fehlerbehebung aus: Es ist einfacher, kleinere Strukturen zu überwachen und Bugs schnell zu beheben.

Container vs. Serverless-Ansätze

Für viele Entwickler sind Container die prädestinierte Architektur für Microservices. Dabei haben sich vor allem Docker-Container durchgesetzt. Meist sind sie so aufgebaut, dass mehrere Container zusammen eine Anwendung bilden. Wer sich mit dem Thema befasst, kommt aber auch an Kubernetes nicht vorbei - das Open-Source-System gilt als neuer Standard für Container-Orchestrierung. Namhafte Public-Cloud-Anbieter wie Google, AWS und Azure setzen Kubernetes wirksam ein. Auch On-Premise-Lösungen wie OpenShift setzen auf die Orchestrierungslösung.

Microservices können aber auch ohne Container verwendet werden: Der serverlose Ansatz AWS Lambda von Amazon etwa erlaubt das Deployment einzelner geschriebener Funktionen in Java, JavaScript und Python (Function-as-a-Service). Welche Lösung die sinnvollere ist, hängt von den zur Verfügung stehenden Ressourcen, den Anforderungen an die Applikation und den benötigten Sicherheitsstandards ab.

Komplexität in Microservice-Architekturen

Doch eine Microservice-Architektur bringt auch Herausforderungen mit sich. Zwar sind kleinere Codeblöcke für Entwickler leichter zu verstehen und zu managen, doch die Applikationen an sich sind aus viel mehr Komponenten aufgebaut - und diese Komponenten haben mehr Verbindungen. Diese Abhängigkeiten erhöhen die Gesamtkomplexität der Anwendung, was zu Problemen führen kann.

Einen besonderen Fokus sollte man hier auf das Application Performance Monitoring (APM) legen. Da bei einer einzigen Transaktion so viele bewegliche Teile eine Rolle spielen und jede Millisekunde Verzögerung die Benutzerfreundlichkeit beeinträchtigen kann, wird die Fehlerbehebung bei Performance-Problemen komplexer denn je.

Engmaschiges Monitoring hilft

Um Probleme und Fehler schnell zu identifizieren und zu beheben, ist es nötig, die Microservice-Architektur engmaschig zu überwachen. Ein umfassender Überblick über die gesamte Struktur sowie tiefe Einblicke in alle Befehle und Transaktionen stützt sich auf drei Säulen:

• Monitoring der Beziehungen zwischen den Applikationen und der Infrastruktur, in der sie laufen;

• Monitoring der Applikations-Architektur: wie die verschiedenen Komponenten zusammenhängen und

• Verfolgen der einzelnen Transaktionen, um Fehler aufzuspüren.

Überblick über Hosts, Applikationen und deren Verbindungen

Infrastruktur und Anwendungen hängen untrennbar zusammen und beeinflussen sich gegenseitig. Im Idealfall zeigt das verwendete Monitoring-Tool die Leistungsdaten in Echtzeit in einer Ansicht an. So können Zusammenhänge schnell erkannt und größere Ausfälle vermieden werden.

Zusätzlich ist es notwendig, die Verbindungen der einzelnen Instanzen untereinander und deren allgemeinen Zustand zu überwachen. Auch hier gilt wieder: Im Idealfall überwacht man diese Metriken im direkten Zusammenhang. So ist es im Ernstfall leichter, den Auslöser eines Problems zu identifizieren. Zudem sollte man immer ein Auge auf vor- und nachgelagerte Anwendungen haben: Hat das Problem eventuell seinen Ursprung in einer vorgelagerten Anwendung genommen? Oder hat es Auswirkungen auf nachgelagerte Dienste?

Distributed Tracing für ein Monitoring über alle Services hinweg

Auf der Code-Ebene helfen Traces zu sehen, wo Performance Probleme bei einer Transaktion entstehen. Bei dieser Ablaufverfolgung kommt es besonders auf Genauigkeit an - und auf die Möglichkeit, tiefe Einblicke in die Trace-Details zu erlangen.

Traces nutzen eine automatische Instrumentierung auf Code-Ebene, um die Zusammenhänge zwischen dem Code, der Performance und auftretenden Fehlern zu beleuchten. Distributed Tracing führt diese Technik angepasst auf Microservice-Architekturen fort. In einer Architektur, die auf Microservices basiert, bei der ein Request durch viele verschiedene Services geht, bis dem User eine vollständige Seite angezeigt wird, ist dieses Vorgehen essenziell.

Ein Distributed Trace liefert die Information über sämtliche Dienste, Datenspeicher und andere Komponenten, die an einem Request beteiligt waren. So erlangt man ein umfassendes Verständnis für die Zusammenhänge aller involvierter Prozesse, wie lange diese dauern und wie sie in Abhängigkeit zueinanderstehen.

Die wahre Stärke des Distributed Tracings liegt darin, dass Traces über Services, Container oder Applikationen hinweg verfolgt werden können. Besonders bei Microservices, die extern gehostet werden, ist das ein großer Vorteil. Speziell bei AWS Lambda besteht beispielsweise die Schwierigkeit, dass Entwicklerteams zu wenig Einblicke darin haben, was in der Lambda-Funktion wirklich passiert und welche Abhängigkeit eine solche Funktion zu anderen nativen Diensten beinhaltet. Mithilfe von Distributed Tracing können Entwickler-Teams auch in diese "Black Box" Licht bringen.

Jeder Serviceausfall kostet Zeit und Geld

Microservices liefern Entwickler-Teams genau das, was sie in der von Digitalisierung und Disruption geprägten Businesswelt brauchen: Schnelligkeit, Skalierbarkeit, Flexibilität, Produktivität und Zuverlässigkeit von Anwendungen. Doch Microservice-basierte Strukturen bringen ein hohes Maß an Komplexität mit sich.

Die Herausforderung für Entwickler ist es, diese Komplexität durch ein durchgängiges Monitoring mit aussagekräftigen Analysen zu bewältigen. Sie zeigen den Entwickler-Teams, wo Probleme vorliegen oder Prozesse verbessert werden können. Jeder Ausfall eines Service kostet Zeit, Geld und manchmal auch Kundenvertrauen. Deshalb ist es sinnvoll in die Schnelligkeit, Flexibilität und Zuverlässigkeit von Microservice-Architekturen und deren stringente Wartung zu investieren.