Microservices sind keine Architektur!

23. Juli 2015Mathias Kowalzik

Microservices liegen voll im Trend und werden als Architekturkonzept, Architekturansatz, Architekturparadigma oder schlicht als heiliger Gral der modernen Softwareentwicklung angepriesen.

Sie sind die Evolution der aktuellen Softwareentwicklung und des Betriebs von Softwaresystemen. Konzeptionell betrachtet sind Microservices allerdings keine neue Erfindung. Sie sind ein älteres und natürliches Erscheinungsbild, auf das alle Entwicklungsformen und Umgebungen offensichtlich stoßen müssen, sobald ihre Rahmenbedingungen dies zulassen.

Schaut man sich um, so entdeckt man in etablierten Software-Umgebungen viele Beispiele für Strukturen, die einen guten Microservice ausmachen. Sei es im Bereich von Betriebssystemen, der Batchverarbeitung, klassisch mit OSGi (prägte schon vor fast 20 Jahren den Begriff µService), im modernen Web-Umfeld oder auch in den zahlreichen Tools des Data Warehouse mit seinen ETL-Prozessen. Sie alle haben gemeinsam, dass sie aus viele kleinen, einzelnen Utility-Programmen, Jobs und Transformationen, kurz Microservices, ein deutlich größeres und komplexeres Gesamtsystem darstellen.

Und noch etwas haben sie gemeinsam: es ist nicht ihre Architektur, sondern ihre Modularisierung. Und genau die macht die Attraktivität der Microservices aus.

Vorteile von Microservices

Die kleinere Einheit Microservice kann viel leichter und besser verstanden werden; nicht nur in der Implementierung, sondern in allen Aspekten. So wird durch die kleinere Einheit auch der Entwicklungszyklus kürzer. Das Team kann die gemachten Lektionen schneller in neuen Services umsetzen. Auch die Gefahr fundamental falscher Entscheidungen wird entschärft oder besteht gar nicht mehr. Da ein Microservice im Idealfall nur wenige Tage oder sogar nur Stunden für die Entwicklung benötigt hat, tut es auch nicht so weh, ihn aufgrund einer falschen Entscheidung oder eines Designfehlers komplett neu zu entwickeln und als neuen Service zu veröffentlichen.

Im wahren Leben ist es allerdings selten sinnvoll, Microservices in dieser reinen Form zu leben. Denn ähnlich wie bei Wärmedämmsystemen, deren Stärke jeweils verdoppelt werden muss, um den Wärmeverlust zu halbieren, steigt der Aufwand mit der Verkleinerung der Services. Ohne steigende Automatisierung stellt man schnell fest, dass nicht nur das Arbeitsvolumen des Betriebes dessen Kapazitäten übersteigt, sondern auch andere Teilbereiche gefordert sind. Die Anforderungen an das Architekturmanagement steigen. Ein zentrales Logging und Monitoring wird wichtiger.

Diese Grenzen zu verschieben kostet Zeit und Geld und kann auch nicht von heute auf morgen  durchgeführt werden. Es gilt also, einen gesunden Kompromiss zwischen Größe, Entwicklungszeit, Komplexität und Handhabung zu finden und einen stetigen Verbesserungsprozess in Gang zu setzen, um die Rahmenbedingungen für den Einsatz von Microservices zu verbessern.

Aber es lohnt sich. Auch wenn die meisten von uns „nur“ durchschnittliche Probleme in durchschnittlichen Umgebungen bearbeiten, so zeigen sich die Vorteile umgehend und das ein oder andere Problem löst sich sogar von selbst. Verteile ich beispielsweise eine monolithische Anwendung auf mehrere unabhängige Teilsysteme, so erhöht dies nicht nur direkt die maximal mögliche Benutzeranzahl, sondern auch die Anzahl der Releases des Gesamtsystems. Im besten Fall steigen diese Zahlen sogar um einen größeren Faktor als die Anzahl der Teilsysteme.

Gefühlte Verfügbarkeit – was ist das?

Mein persönlich wichtigster Grund für Microservices ist allerdings die 100% gefühlte Verfügbarkeit. 100% gefühlte Verfügbarkeit? Genau. Gefühlte Verfügbarkeit bedeutet, dass man hinter den Kulissen praktisch ständig den Ausfall von Services beobachtet, der Benutzer allerdings das Gefühl hat, dass das System funktioniert. Microservices fördern diese Benutzererfahrung, da ein Ausfall eines Microservices jeweils nur den Ausfall einer einzelnen Funktionalität bedeutet. Je kleiner die Microservices und je größere deren Anzahl, desto schwieriger wird es für den Benutzer dies zu erkennen. Im Idealfall kann er es überhaupt nicht erkennen.

Das bekommt man durch die Modularisierung allerdings nicht geschenkt – und hier sind wir dann doch wieder bei der Architektur…

Wie ist Ihre Meinung zu Microservices? Sehen Sie auch diese Vorteile?

Mathias Kowalzik Mathias Kowalzik ist Software Architekt bei adesso. Sein Schwerpunkt liegt im Bereich Versicherungen und der Ablösung oder Modernisierung von bestehenden Systemen. Er interessiert sich für die Themen High Scalability und High Availability und den damit verbundenen technologischen Trends.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentar hinzufügen:

Ihr Kommentar: