Wann und für wen eignen sich Microservices?
Die vorangegangenen Betrachtungen der wesentlichen fachlichen Aspekte Komplexität, Reaktionsfähigkeit, fachliche Ausrichtung und Konsistenz haben ein ambivalentes Bild gezeichnet, wenn wir Microservices und deren Einsatz bewerten. Vor allem fehlt noch eine Antwort auf die Eingangsfrage – mit den Worten von Martin Fowler: "Is a microservice architecture a good choice for the system you're working on?"
Nichts ist umsonst
Fowlers Beitrag stellt die Komplexität in den Vordergrund: "The microservices approach is all about handling a complex system..."[1]. Gleichzeitig passt Komplexität sehr gut zur Zielsetzung von Microservices, Änderungsanforderungen besonders reaktionsfähig zu bedienen.
Microservices sind ein Mittel, um ein komplexes System zu bauen und weiterzuentwickeln. Doch das gibt es nicht umsonst, weshalb das Zitat von Fowler weitergeht: "... but in order to do so the approach introduces its own set of complexities. When you use microservices you have to work on automated deployment, monitoring, dealing with failure, eventual consistency, and other factors that a distributed system introduces. There are well-known ways to cope with all this, but it's extra effort, and nobody I know in software development seems to have acres of free time." Die beschriebenen Herausforderungen der verteilten Systeme haben einen Eindruck davon vermittelt (s. Teil 4 unserer Artikelserie). Microservices haben Vorteile. Doch den Vorteilen stehen Kosten gegenüber, wie Tabelle 1 zusammenfasst.
Tabelle 1: Vorteile und Nachteile von Microservices
| Microservices bieten Vorteile, | … haben aber ihre Kosten |
|---|---|
| Strikte ModulgrenzenMicroservices erzwingen eine modulare Struktur, von der große Teams besonders profitieren. | VerteilungProgrammieren ist in verteilten Systemen schwieriger, da man mit höheren Latenzen und Ausfällen umgehen muss. |
| Unabhängiges DeploymentDas Deployment eines einfachen Microservice ist leichter, und da er autonom ist, werden Deploymentprobleme nicht das Gesamtsystem kompromittieren. | Eventual ConsistencyIn einem verteilten System ist es sehr schwierig, transaktionale Ende-zu-Ende-Konsistenz zu realisieren. Jeder Microservice muss deshalb mit "Zwischenzuständen" anderer Microservices umgehen können. Und auch die Nutzungsendpunkte müssen die Zwischenzustände berücksichtigen. |
| Technologische VielfaltJeder Microservice kann sich für die Sprache, die Frameworks und Persistenztechnologie entscheiden, die zu seiner Aufgabe passen. | Betriebliche KomplexitätEs bedarf einer sehr ausgereiften Betriebsumgebung und eines sehr erfahrenen Betriebsteams, um Vielzahl und Heterogenität von Microservices und deren regelmäßige Deployments zu betreuen. |
Quelle: Fowler: Microservice Trade-Offs [2]
Fowler setzt Produktivität und Komplexität in Zusammenhang und formuliert den bereits in Teil 1 unserer Artikelserie zitierten Ratschlag: "Don't even consider microservices unless you have a system that's too complex to manage as a monolith."
Die Dimensionen Komplexität, Autonomie und Konsistenz geben Orientierung
Der mit Microservices einhergehende hohe Aufwand muss gerechtfertigt sein. Die Dimensionen Komplexität, Autonomie und Konsistenz kommen auf verschiedenen, voneinander abhängigen Ebenen zum Tragen: Die Fachlichkeit bestimmt den Domänenschnitt, die Organisation den Teamschnitt und die Architektur den Komponentenschnitt. Bei Komplexität und Autonomie handelt es sich um organisatorische Dimensionen, also um keine im technischen oder betrieblichen Sinn. Die Konsistenz ist dagegen eine inhaltlich-fachliche Dimension.
Diese Auseinandersetzung mit den Begriffen Komplexität und Autonomie zeigt graphisch aufbereitet unser Zonendiagramm in Abb. 1: Je größer die organisatorische Komplexität des Geschäftsfeldes bzw. der Organisation ist, desto autonomer sollten die Teams agieren können; als Folge davon werden Teams kleiner und somit gibt es mehr von ihnen. Christoph Iserlohn und Till Schulte-Coerne beschreiben diesen Zusammenhang sehr treffend: "Die Organisationsstruktur zu ändern, ist in der Regel deutlich schwerer, als die Software- und Systemarchitektur. Deshalb ist die Versuchung groß, organisatorische Probleme mit technischen Mitteln zu lösen. Dies wiederum betrachten wir als einen der Hauptgründe dafür, warum Microservice-Ansätze scheitern." [3]
Erst bei erhöhter Dynamik lohnt sich der Einsatz einer Microservice-Architektur. Bei weniger Dynamik sind enger koordinierte Teams erfolgversprechender. Ist die Eigenverantwortlichkeit einzelner Teams im Verhältnis zur Komplexität nicht ausreichend ausgeprägt, wird die Weiterentwicklung der Anwendung(-slandschaft) mit den Anforderungen nicht Schritt halten können (Zone der Stagnation). Umgekehrt erzeugen autonome Teams bei überschaubarer Dynamik eher Lösungen, die gegenüber der Anforderungslage übertrieben kompliziert sind (Zone der Ineffizienz). Somit könnten eine sehr umfangreiche Anzahl von Beteiligten oder ein hoher Innovationsdruck gute Indikatoren dafür sein, sich für eine Microservice-Architektur zu entscheiden.
Der fachliche Schnitt ist letztlich entscheidend.
In vergleichbarer Weise hängen Autonomie und gelockerte Konsistenz zusammen, was Abb. 2 veranschaulicht. Je autonomer Teams arbeiten sollen, desto unkoordinierter laufen Aktivitäten durch das System und desto stärker müssen die Systemnutzer mit Zwischenzuständen und mit Abweichungen zwischen Teilsystemen umgehen können. Anderenfalls entsteht entweder unangemessen hoher Aufwand (Zone der Ineffizienz) oder die entkoppelten Teams haben Schwierigkeiten, die Konsistenzanforderungen zu erfüllen (Zone der Inkonsistenz).
Die "große Kunst" liegt dann darin, die fachlichen Bereiche zu identifizieren, in denen keine Entkopplung stattfinden darf: Der fachliche Schnitt ist letztlich entscheidend.
Lohnt sich der Einsatz von Microservices?
Um den Microservice-Einsatz zu beurteilen, müssen wir uns also die folgenden Fragen stellen; sie entsprechen den in den Diagrammen angegebenen Dimensionen:
- Wie sehr rechtfertigt die Geschäftskomplexität den Einsatz?
- Wie dezentral ist das Unternehmen organisiert? Wie autonom agieren Teams und wie viel Verantwortung erhalten sie?
- Wie transaktional müssen fachliche Abläufe sein? Wie viel/ wie schnell muss Konsistenz erreicht sein?
Als Warnung mögen Sam Newmans Worte dienen, denn sie verdeutlichen, wie wichtig die Vorbereitung auf eine Microservice-Architektur ist: "Many of the challenges you’re going to face with microservices get worse with scale. (...) These stories just reinforce to me the importance of starting gradually so you understand your organization’s appetite and ability to change, which will help you properly adopt microservices."[4]
Es droht die Gefahr, den bestenfalls strukturierten Monolithen durch ein unstrukturiertes Microservice-Spaghetti-Chaos zu ersetzen.
Wir sollten daher eine sehr gute Vorstellung davon haben, was wir wollen und wie wir zusammenarbeiten, bevor wir zu Microservices in großem Stil wechseln. In [5] werden technische Ergebnisse nachhaltig in den Geschäftszielen verankert und ein strukturierter Weg durch die Ebenen, Aspekte und Dimensionen des Architekturmanagements aufgezeigt. In einer Microservice-Architektur werden wir diesen Weg bis inkl. der Domänenmodellierung gehen. Die weitere Ausgestaltung werden wir den autonomen Microservice-Teams überlassen.
Zusammenfassung
Die wesentliche Stärke einer Microservice-Architektur liegt in der hohen Reaktionsfähigkeit. Komplexe Geschäftssituationen erfordern reaktionsfähige Architekturen und autonome Teams. Die dafür notwendige Arbeits- und IT-Projektkultur unterscheidet sich substantiell von der traditionellen. Inwieweit es überhaupt noch "Projekte" im Wortsinne gibt, geht angesichts von "Products, not Projects" und DevOps über die Microservice-Diskussion hinaus. Richtungsweisende Unterstützung muss die kontrollorientierte Führung ersetzen.
Microservices wollen Autonomie mit Hilfe fachlicher Abgeschlossenheit erzielen. Das gelingt ihnen nur ansatzweise, besonders gut im Spezialfall der web-basierten Self-Contained Systems. Es droht die Gefahr, den bestenfalls strukturierten Monolithen durch ein unstrukturiertes Microservice-Spaghetti-Chaos zu ersetzen.
Microservices müssen sich mit den Herausforderungen verteilter Systemen auseinandersetzen. Teilfertigstellungen und Teil-Konsistenz sind aus fachlicher Sicht zu berücksichtigen, Benutzer sehen Zwischenzustände und müssen mit zwischen Teilsystemen abweichenden Zuständen umgehen können.
Die drei Dimensionen Komplexität, Autonomie und Konsistenz dienen als fachliche Entscheidungskriterien für oder gegen den Einsatz von Microservices. Zonendiagramme erlauben es, eine Anwendung anhand der drei Dimensionen zu verorten, und zeigen die Microservice-Eignung der Anwendung.
- M. Fowler; 2015: MicroservicePremium
- M. Fowler; 2015: Microservice Trade-Offs
- Informatik Aktuell – C. Iserlohn; T. Schulte-Coerne: Warum es nicht immer Microservices sein müssen. Oder: Ein Loblied auf den Monolithen
- S. Newman; 2015: Building Microservices: Designing Fine-Grained Systems
- G. Engels, A. Hess, B. Humm, O. Juwig, M. Lohmann, J.-P. Richter, M. Voß, J. Willkomm; 2008: Quasar Enterprise – Anwendungslandschaften serviceorientiert gestalten
