Microservices lassen Komplexität verschwinden

Ein System in Microservices aufzuteilen erzeugt zwar einfache und kleine Module – aber die Komplexität muss irgendwo bleiben. Also müssten die Integrationsschicht und die Beziehungen komplizierter sein, und man hat – wie so oft – nichts gewonnen. Aber Microservices lassen tatsächlich Komplexität verschwinden.

Architekturen sind das Große und Ganze von Softwaresystemen. Offensichtlich muss man einen Überblick über jedes System haben. Denn wie soll man sonst Änderungen durchführen oder die Folgen von Änderungen abschätzen können?

In einem Microservices-Projekt gab es genau einen solchen Überblick zu meinem Erstaunen nicht. So habe ich einen solchen erstellt, der zeigt, welche Microservices mit welchen anderen Microservices kommunizieren. Das Diagramm war auch ästhetisch ansprechend, einige Kollegen wollten nun ebenfalls eine solche Übersicht haben. Aber für die Arbeit war es letztlich irrelevant. Denn offensichtlich hatte das Projekt nicht nur kein Big Picture; es benötigte auch keines, um Software zu entwickeln – selbst wenn eines existiert.

An einem Punkt brauchten wir aber dennoch eine Übersicht über das Projekt. Denn ein neuer Techniker sollte aufgegleist werden. Normalerweise würde man ihm die Architekturübersicht geben – die es in diesem Projekt aber nicht gab. Stattdessen haben einige Experten verschiedene Use Cases aus ihrem Bereich vorgestellt und die für den Use Case notwendige Interaktion der Microservices aufgezeigt. Das Wissen über einzelne Teile und Use Cases war vorhanden – jedoch in den Köpfen verschiedener Mitarbeiter. Niemand verstand das gesamte System.

Das ist eigentlich erschreckend: Niemand versteht das System mehr. Wie kann man dann überhaupt entwickeln? Aber wenn man sich Diagramme von Microservice-Systemen, zum Beispiel von Netflix, ansieht, stellt sich jeder die Frage: Versteht das denn noch jemand? Ich hatte die Chance, jemanden zu fragen, der an dem Aufbau dieses Systems beteiligt war – und seine Aussage war: Nein, das versteht im aktuellen Netflix-Team niemand. Das oben zitierte Projekt steht also nicht alleine – auch Netflix versteht niemand mehr vollständig.

Muss das gesamte System verstanden werden?

Die Frage ist nun: Ist es ein Problem, wenn niemand das gesamte System versteht? Immerhin können die Organisationen Software erfolgreich entwickeln. Anscheinend nicht. Es ist nur eine logische Fortführung von Kapselung, Modularisierung und Information Hiding – also wesentliche Konzepte des Software Engineering. Sie zielen darauf ab, das notwendige Wissen über ein System möglichst gering zu halten. Wenn jeder nur den Teil des Systems verstehen muss, der für seine Use Cases relevant ist, dann ist das eine offensichtlich erfolgreiche Umsetzung dieser Konzepte.

Wenn die Konzepte aber so alt sind – was hat das mit modernen Ansätzen wie Microservices zu tun? Letztere ermöglichen eine noch bessere Isolation der Module gegeneinander. Sie lassen sich einzeln deployen, sie können unterschiedliche Plattformen und Programmiersprachen nutzen. Ein Speicherleck in einem Microservices führt nur zum Ausfall dieses Microservices, aber nicht zum Ausfall irgendwelcher anderer Microservices. Ein Microservice, mit dem ein anderer nicht interagiert, muss einen überhaupt nicht interessieren. In einem Deployment-Monolithen sind die Module nicht so gut isoliert.

Also verschiebt die Aufteilung in Microservices nicht einfach die Komplexität in die Integration zwischen die Microservices: Weil die Trennung so konsequent ist, muss jeder nur noch einen kleinen Teil des Systems verstehen. Und so verschwindet gewissermaßen ein Stück Komplexität, und wir können noch komplizierte Systeme entwickeln. ()