5 Mythen über Microservices

Es muss 2018 gewesen sein, auf einer Party mit einigen Leuten aus der IT-Branche (ja, sowas gibt es). Nach ein paar Bier erzählte mir der Vertriebler eines e-Commerce-Anbieters stolz, sie hätten ihr monolithisches Shop-System erfolgreich in über 200 Microservices zerlegt, das wäre super und die Kunden wollen das so.

Was für ein beeindruckender Marketing-Coup! Mit sexy Namen und intuitiv einleuchtenden Vorteilen – "kleiner, schneller, flexibler" – sind Microservice-Architekturen von einem technischen Trend zum wichtigen Entscheidungskriterium für Auftraggeber von IT-Lösungen geworden. Gründer, die noch nicht genau wissen, was sie eigentlich brauchen, sind sich oft schon mal sicher, dass es bloß kein Monolith werden soll, weil diese angeblich nicht skalieren.

Woher kommt diese Überzeugung? Und liegt man damit richtig? Ich frage mich in solchen Situationen oft: Wenn Microservices die Antwort sind – was war denn die Frage? Gibt es in dem Fall gute Gründe für den Einsatz von Microservices und sind die Konsequenzen klar?

Versteht mich nicht falsch. Ich finde, Microservices sind der Hammer. Aber damit meine ich insbesondere auch: Sie sind ein Werkzeug. Man muss wissen, wann man sie einsetzen sollte und wann lieber nicht.

Lasst uns also einige Mythen auf ihren Wahrheitsgehalt prüfen, damit ihr wisst, was auf euch zukommt und wann Microservices für euch das Richtige sind.

Mythos 1: Microservices sind weniger komplex

Mythos 2: Microservices skalieren besser

Mythos 3: Microservices sind flexibler

Mythos 4: Microservices sind nur etwas für große Teams

Mythos 5: Unternehmen sollten auf Microservices für ihre IT-Strategie setzen

Schlussworte

Mythos 1: Microservices sind weniger komplex

"Kleiner" klingt auch wie "weniger komplex". Stimmt das denn? Es gibt gewollte und ungewollte Komplexität in Softwareprojekten. Natürlich möchten wir Dinge möglichst simpel und verständlich halten. Um aber echten Wert zu schaffen, indem aufwändige, teure oder schwierige Prozesse automatisiert werden, ist eine gewisse fachliche Komplexität schlichtweg notwendig. Triviale Systeme können auch nur triviale Aufgaben lösen. Es gibt also eine Ebene von fachlicher Komplexität, die gebraucht wird, damit die Software auch einen tatsächlichen Nutzen bietet – das stimmt sowohl für Monolithen als auch für Microservices. Diese Ebene wird man nicht dadurch los, dass man ein System in kleinere Teile schneidet.

Daneben gibt es technische Komplexität, die durch die eingesetzte Technologie oder Architektur bedingt ist. Sie ist nicht immer gewollt, aber oft notwendig, um die Anforderungen mit den verfügbaren Mitteln umzusetzen. Einer der heimlichen Wünsche vieler Programmierer ist, diese technische Komplexität zu reduzieren.

Wir Entwickler denken uns gerne komplexe Abstraktionsschichten und wiederverwendbare Lösungen aus, weil wir das für das richtige Vorgehen halten. Manchmal kommt aber der Moment, in dem wir uns simpleren und übersichtlicheren Code wünschen. Microservices versprechen Abhilfe: kleine Dienste ohne unnötige Abstraktionen mit weniger und einfacherem Code. Wenn größere technologische Anpassungen nötig sind, wird einfach der ganze Microservice ausgetauscht. Das kann funktionieren, wenn man die Microservices sehr klein schneidet.

Fakt ist aber auch: Ein Teil der technischen Komplexität verschwindet durch das Zerlegen eines Systems nicht. Er wandert stattdessen in die Schnittstellen, die nun zur Kommunikation zwischen den Microservices geschaffen werden müssen und in deren Überwachung. 200 Einzelservices zu verwalten ist zunächst komplexer, als eine handvoll Monolithen zu betreuen. Zusätzlich wird das Testing erschwert.


Fazit:
Nein, Systeme bestehend aus vielen Microservices sind im Allgemeinen nicht weniger komplex als Monolithen. Sie benötigen daher auch nicht weniger Zeit in der Umsetzung und sind auch nicht günstiger zu haben. Die Ressourcen werden nur umverteilt.

Mythos 2: Microservices skalieren besser

Eines der häufigsten Argumente für den Einsatz von Microservices ist, dass sie besser skalierbar sind als Monolithen.

Fakt ist, dass Microservices einzeln und damit gezielter skaliert werden können. Ein typischer Online-Shop verbringt zum Beispiel locker 95 Prozent seiner Rechenzeit für den Abruf von Artikeldetails, für die Suche nach Artikeln und die Bereitstellung von Bildern. Hier bietet es sich an, die Skalierung erstmal auf Dienste für Artikeldaten und Bilder zu fokussieren und verfügbare Rechenleistung hier zu investieren, anstatt alle Teile des Systems gleichmäßig zu vergrößern.

Allerdings – und das hören die Gründer nicht gerne – müssen die meisten Anwendungen gar nicht so stark skalieren, dass dieser Faktor gravierend ins Gewicht fällt.

Ausnahmesysteme wie Netflix, Facebook und Amazon dienen oft als Inspiration für Systemarchitekturen. Die meisten Anwendungen müssen aber niemals so große Mengen von Benutzeranfragen handhaben. Klar – ein Online-Shop oder Marktplatz sollte eine umfassende Marketing-Kampagne oder Rabatt-Aktion mit erhöhten Nutzerzahlen schon aushalten, aber das verursacht noch lange nicht die Herausforderungen und Kosten der ganz großen Plattformen.

Aus Sicht der Entwickler hat Skalierbarkeit in erster Linie mit der Vermeidung von Abhängigkeiten zwischen Systemkomponenten zu tun. Auch Monolithen können so umgesetzt werden. Sie werden skaliert, indem die ganze Anwendung mehrfach gestartet wird und mit Load-Balancern Anfragen zwischen den Servern verteilt werden. Manche Leute nennen diesen Ansatz „Cookie Cut“-Skalierung, weil neue, identische Server bei Bedarf wie Kekse von einer Rolle Teig abgeschnitten werden können. Bei Microservices muss das letztlich je Service passieren. Inzwischen gibt es zum Glück jede Menge Tools, die das Skalieren von Diensten vereinfachen und teilweise automatisieren. Hier sollte man aber nicht Ursache und Wirkung verwechseln. Kubernetes, Docker-Swarm und Co. gibt es unter anderem, weil die Verwaltung großer Mengen von Microservices ohne solche Tools kaum handhabbar wäre.

Außerdem sind Skalierung und Performance unterschiedliche Dinge. Durch zusätzliche Schnittstellen entstehen bei Microservices teilweise Latenzen, die es bei Monolithen so nicht gibt. Möglicherweise sind die schnellen Microservices im Zusammenspiel also plötzlich langsamer als es ein Monolith gewesen wäre.


Fazit:
Bei sehr großen Anwendungen ergeben sich Vorteile durch die gezielte, separate Skalierung von Microservices. Die Rechnung kann aber durch zusätzliche Kommunikation im Netzwerk und eine aufwendige Verwaltung nach hinten losgehen, wenn die Nutzerzahlen geringer sind. Skalierbarkeit sollte eher im Ausnahmefall eure Hauptmotivation für den Einsatz von Microservices sein.

Mythos 3: Microservices sind flexibler

Hat sich eines eurer Softwareprojekte schon mal in eine Sackgasse entwickelt? Dann wisst ihr, was für ein Dilemma das sein kann. Eigentlich müsste mal alles neu entwickelt werden, aber dafür ist weder Budget noch Zeit da, also wird – solange es irgendwie geht – mit kleinen Anpassungen und Erweiterungen hier und dort versucht, ein System am Leben zu halten. Irgendwann kann das niemand mehr benutzen und weiterentwickeln.

Hätten Microservices geholfen? Möglicherweise, ja. Man könnte sie zumindest individuell modernisieren und austauschen. Das erfordert allerdings auch, dass die Microservices gut strukturiert und zerlegt worden sind. Wer durch zu starke Kommunikation zwischen den Microservices ein undurchsichtiges und untrennbares Netz von Abhängigkeiten geschaffen hat, wird dann auch nicht um eine größere Systemablösung herum kommen. Das ist in der Praxis schwieriger zu vermeiden, als es in der Theorie klingt.

Microservices einzeln austauschen zu können, hat aber noch weitere Vorteile. So können sie für unterschiedliche Anwendungsfälle neu kombiniert oder einzelne Dienste durch andere Funktionalitäten ersetzt werden. Sie erlauben auch, Technologien zu mixen. Einzelne Teile in Node.js, ein Teil in Python und andere in Java? Mit Microservices geht das, und manchmal erlaubt das, besonders gut passende Technologien für bestimmte Anwendungsfälle auszuwählen. (Dass man dann kaum noch EntwicklerInnen finden wird, die sich in allen Teilbereichen auskennen werden, ist ein anderes Problem, aber organisatorisch gegebenenfalls lösbar.)


Fazit:
Die Austauschbarkeit von Microservices und der Mix von Technologien erlauben eine höhere Flexibilität im Systemdesign als bei Monolithen.

Mythos 4: Microservices sind nur etwas für große Teams

Was sicherlich stimmt: Mehr zu verwaltende Einzelteile senken nicht gerade den Personalbedarf zur Betreuung und Entwicklung eines IT-Systems.

Kleinere Teams sollten nicht wie wild Technologien mixen und jeden Microservice architektonisch komplett unterschiedlich umsetzen. Sonst kennt sich mit jedem Service nur noch die Person aus, die ihn implementiert hat. Dann wird der "Bus-Faktor" zu klein, also die Anzahl von Personen, die sprichwörtlich vom Bus angefahren werden können, ohne dass ein Projekt ins Stocken gerät.

Man kann die Frage aber auch umdrehen: Mit welcher Architektur kann ich in größeren oder verteilten Teams gemeinsam an einem System arbeiten? Hier spielen Microservices plötzlich gewaltige Vorteile aus. Teams können nach den betreuten Microservices strukturiert werden und, solange es keine größeren Schnittstellenänderungen gibt, weitgehend unabhängig voneinander entwickeln, testen und deployen (hat hier jemand Conway's Law gesagt?). Dabei können sie unterschiedliche Programmiersprachen und Tools verwenden, in verschiedenen Firmen arbeiten, andere Sprachen sprechen und in getrennten Zeitzonen sitzen. Klar wird man sich trotzdem abstimmen müssen, aber eben weniger als beim gemeinsam entwickelten Monolithen.


Fazit:
Microservices lösen oftmals weniger technische als organisatorische Probleme. Für verteilte Teams mit klar geregelten Verantwortlichkeiten und separaten Deployment-Prozessen empfehlen sich Microservice-Architekturen.

Mythos 5: Unternehmen sollten auf Microservices für ihre IT-Strategie setzen

Sollen nun also alle komplett auf Microservices setzen? Ergibt es Sinn, aufgrund technologischer Trends oder wegen des organisatorischen Aufbaus konsequent auf Microservice-Architekturen zu bestehen?

Sicherlich nicht. Aber: Microservices sind oft besonders dann sinnvoll, wenn zentrale Vorgänge abgebildet oder Daten bereitgestellt werden, mit denen zahlreiche andere Systeme arbeiten sollen. Für einen Paket-Dienstleister ist es von hohem Wert, einen zentralen Service für die Erstellung von Versandlabels zu haben. Anbieter von Vertriebstools brauchen eine zentrale Kundendatenbank.

Diese Services können unternehmensweit bereitgestellt werden und dann in andere Tools eingebunden werden. Das spart dort Implementierungszeit und sorgt für konsistente Daten und Abläufe. Die restlichen Tools sind in ihrem Aufbau dann relativ frei. Wenn es sinnvoll ist, können auch hier Microservice-Architekturen genutzt werden, oder modulare Lösungen, die sich Teile der Funktionalität teilen. Müssen sie aber nicht. Das ist eine gute Strategie, um die IT-Landschaft von Unternehmen mit starken zentralen Diensten und geteilten Stammdaten aufzubauen.


Fazit:
Unternehmen sollten insbesondere für häufig genutzte zentrale Dienste auf rekombinierbare Microservices setzen. Für andere Tools lässt sich das pauschal nicht sagen und ist letztlich Geschmackssache.

Schlussworte

Seien wir ehrlich. "Einen Monolithen bauen" klingt ähnlich attraktiv wie "Einen Ring nach Mordor tragen".

Aber lasst euch bitte nicht vom Klang abschrecken. Gut gemachte Monolithen haben immer noch ihre Daseinsberechtigung und sind in der Regel simpler zu erstellen als Netze aus Microservices. Auch modulare Lösungen sind manchmal ein guter Zwischenweg.

Microservice-Architekturen sind - wie Monolithen auch - letztlich nur ein Werkzeug. Man sollte wissen, welche Probleme man lösen möchte und welche Trade-Offs man dabei eingeht. Löst man damit aber die richtigen Themen, wie Flexibilität durch Austauschbarkeit, organisatorische Trennung und Bereitstellung zentraler Dienste, sind Microservice-Architekturen eine sehr gute Wahl für eure IT-Strategie.