Die Anwendung des Theseus-Paradoxons

Das Studium der Philosophie war, zumindest in der Vergangenheit, mit dem Stellen von Fragen verbunden, die, oberflächlich betrachtet, irrelevant schienen. Ist es denn wirklich so wichtig zu wissen, „ob ein Schiff, das durch Ersetzen jedes einzelnen Holzteils restauriert wurde“, immer noch dasselbe Schiff ist? Diese Frage stellte Plutarch in seinem Buch Das Leben des Theseus und wurde danach als Theseus-Paradoxon bekannt. Allgemeiner ausgedrückt geht es um die Frage, „ob ein Objekt, bei dem alle seine Komponenten ersetzt wurden, im Wesentlichen dasselbe Objekt bleibt.“ ( Schiff des Theseus, Wikipedia )

Dasselbe könnten wir von Microservices verlangen, die bei Anwendung auf bestehende monolithische Anwendungen versuchen, die Anwendung im Wesentlichen wiederherzustellen, indem sie Funktionen durch ergänzende Dienste ersetzen. Funktionen sind (oder sollten) konzeptgemäß klein sein, weshalb der Begriff „Mikro“ auf die daraus resultierenden, entkoppelten Dienste angewendet wird. Die Unterschiede zwischen beiden liegen in der Kommunikation. In einer monolithischen Anwendung werden Funktionen durch Referenzieren einer bestimmten Adresse im Speicher aufgerufen. In einer auf Microservices basierenden Anwendung werden Funktionen (Dienste) durch die Referenzierung einer bestimmten IP-Adresse im Netzwerk aufgerufen.

Konzeptionell sind beide gleich, lediglich der Mechanismus zum Aufruf einzelner Funktionskomponenten unterscheidet sich. Ein resultierendes Diagramm würde im Wesentlichen kaum einen Unterschied zeigen, außer dass die „Box“ des Monolithen ein einzelner Server und die „Box“ der Microservices das gesamte Rechenzentrum ist. Die eine verwendet eine lokalisierte Adressierung, die andere eine Netzwerkadressierung. Der Code für jede dieser Funktionen könnte genau derselbe sein, genau wie das Holz in Theseus’ Schiff. 

Die Geschäftsfunktionen bleiben jedoch konsistent und wenn wir die Anwendung richtig zerlegt haben, sollte der Benutzer tatsächlich keinen erkennbaren Unterschied zwischen den beiden sehen. Man könnte argumentieren, dass es aus der Sicht des Passagiers auf Theseus‘ Schiff keinen Unterschied zwischen den beiden gibt. Und das sollte es auch nicht geben.

Philosophen neigen jedoch dazu, tiefer zu graben, und genau wie sie müssen auch wir das tun, da der Unterschied zwischen einer monolithischen Anwendung und einer auf Microservices basierenden Anwendung für den Betrieb tatsächlich ziemlich wichtig ist.

Die Komplexität des Netzwerkbetriebs

Microservices vereinfachen viele Aspekte des Anwendungsentwicklungsprozesses, führen dabei jedoch zu einer erheblichen betrieblichen Komplexität. Die Anzahl der Netzwerkverbindungen zwischen den unterschiedlichen Teilen einer auf Microservices basierenden Anwendung erfordert zwangsläufig einen entsprechenden Mehraufwand bei der Verwaltung der verschiedenen erforderlichen Netzwerkeigenschaften: IP-Adressen, VLANs, NAT-Tabellen und mehr. Auch die Skalierbarkeit wird zu einer Herausforderung, die selbst Dijkstra frustrierend finden könnte, da die Platzierung der Mikrodienste und des Lastausgleichsdienstes sehr reale Auswirkungen auf die Leistung hat, je nachdem, wie viele Segmente im Netzwerk durchlaufen werden müssen.

Plötzlich sind zusätzliche Richtlinien erforderlich, denn die Sicherheitsrichtlinien, die für einen Dienst gelten, der direkt auf eine vertrauliche Datenquelle zugreift, sind nicht diejenigen, die zum Schutz eines anderen Dienstes erforderlich sind, der Einstellungen oder den Sitzungsstatus verwaltet. Das entstehende Netz aus Mikrosicherheitsrichtlinien bietet sicherlich viele der gleichen Vorteile wie die Mikroservices selbst, nämlich eine feinere Kontrolle und eine Art eleganter Einfachheit. Gleichzeitig wird es jedoch zu einem betrieblichen Albtraum, da die Richtlinien plötzlich mit den Services mitwandern müssen, wo auch immer sie in der Architektur auftauchen.

Auch die Bereitstellung wird plötzlich exponentiell schwieriger, etwa beim Übergang von einem einfachen Box-Step-Tanz zum komplizierteren Flamenco mit viel mehr Schritten und viel mehr Bewegung über die Tanzfläche (Rechenzentrum). Um die notwendige Konsistenz und Vorhersagbarkeit sicherzustellen, damit alle Teile zur richtigen Zeit an ihren Platz gelangen, sind Orchestrierung und Automatisierung erforderlich.

Diejenigen, die für die Bereitstellung dieser Netzwerk- und Sicherheitsdienste für Anwendungen verantwortlich sind, müssen erkennen, dass das Schiff nicht dasselbe ist, egal wie die Perspektive aus fünfzehntausend Metern Höhe aussieht. Es klingt einfach: Eine Anwendung wird lediglich durch zehn Dienste ersetzt. Voilà! Die App wurde genau wie das Schiff von Theseus nachgebaut. Aber aus operativer Sicht ist dieses Schiff überhaupt nicht dasselbe. Die Verbindungen (Integration) im neuen Schiff sind völlig anders, was die Reibung gegenüber der See (Netzwerk) verändern kann und tendenziell dazu führt, dass das Schiff langsamer fährt.

Microservices befinden sich noch im Entwicklungsstadium. Sie erobern (noch) nicht die Welt, aber es ist wichtig zu erkennen, dass es nicht so einfach ist, wie Theseus‘ Schiff abzureißen und neu aufzubauen. Die Betriebsteams von Netzwerk- und Sicherheitsdiensten müssen die Sicht des Philosophen und nicht die des Passagiers (Benutzers) einnehmen, da die Auswirkungen auf das Netzwerk und die Sicherheit sehr, sehr unterschiedlich sind.