Die Anwendung des Theseus-Paradoxons

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Das Studium der Philosophie bestand zumindest früher darin, Fragen zu stellen, die auf den ersten Blick, nun ja, irrelevant erscheinen. Ist es schließlich wirklich so wichtig zu wissen, ob „ein Schiff, das durch den Austausch jedes einzelnen Holzteils restauriert wurde“, noch dasselbe Schiff ist? Diese Frage stellte Plutarch in Das Leben des Theseus und sie wurde später als Theseus-Paradoxon bekannt. Allgemeiner formuliert lautet sie: „Bleibt ein Objekt, dessen sämtliche Bestandteile ersetzt wurden, im Grunde dasselbe Objekt?“ (Schiff des Theseus, Wikipedia)

Dasselbe könnten wir uns bei Microservices fragen: Werden sie auf bestehende monolithische Anwendungen angewendet, soll die Anwendung im Wesentlichen wiederhergestellt werden, indem Funktionen durch entsprechende Services ersetzt werden. Funktionen sind konzeptbedingt klein (oder sollten es sein), weshalb die daraus entstehenden entkoppelten Services als „Microservices“ bezeichnet werden. Der Unterschied zwischen beiden lässt sich anhand der Kommunikation verdeutlichen. In einer monolithischen Anwendung werden Funktionen durch den Verweis auf eine bestimmte Speicheradresse aufgerufen. In einer auf Microservices basierenden Anwendung werden Funktionen (Services) durch den Verweis auf eine bestimmte IP-Adresse im Netzwerk aufgerufen.

Konzeptionell sind beide gleich; lediglich der Mechanismus zum Aufrufen der einzelnen funktionalen Komponenten unterscheidet sich. Ein entsprechendes Diagramm würde im Wesentlichen kaum Unterschiede zeigen, abgesehen davon, dass der „Kasten“ des Monolithen ein einzelner Server ist, während der „Kasten“ der Microservices das gesamte Rechenzentrum umfasst. Der eine Ansatz verwendet lokale Adressierung, der andere Netzwerkadressierung. Der Code für jede dieser Funktionen könnte exakt derselbe sein – genau wie das Holz von Theseus’ Schiff.

Doch ihre Geschäftsfunktionen bleiben unverändert, und wenn wir die Anwendung richtig zerlegt haben, sollte der Benutzer tatsächlich keinen erkennbaren Unterschied zwischen den beiden feststellen. Man könnte argumentieren, dass es aus der Sicht eines Passagiers auf dem Schiff des Theseus keinen Unterschied zwischen den beiden gibt. Und den sollte es auch nicht geben.

Doch Philosophen neigen dazu, tiefer zu schürfen, und das müssen wir ebenso tun, denn der Unterschied zwischen einer monolithischen Anwendung und einer auf Microservices basierenden Anwendung ist für den Betrieb tatsächlich von großer Bedeutung.

Die zunehmende Komplexität des Netzwerkbetriebs

Microservices vereinfachen viele Aspekte des Anwendungsentwicklungsprozesses, verursachen dabei jedoch eine erhebliche betriebliche Komplexität. Die zahlreichen Netzwerkverbindungen zwischen den einzelnen Komponenten einer auf Microservices basierenden Anwendung bringen zwangsläufig zusätzlichen Aufwand für die Verwaltung der erforderlichen Netzwerkeigenschaften mit sich: 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 Microservices und des Lastausgleichsdienstes je nach Anzahl der zu durchlaufenden Netzwerksegmente ganz erhebliche Auswirkungen auf die Leistung hat.

Plötzlich sind zusätzliche Richtlinien erforderlich, denn die Sicherheitsrichtlinien für einen Dienst, der direkt auf eine sensible Datenquelle zugreift, unterscheiden sich von denen, die zur Absicherung eines anderen Dienstes benötigt werden, der Einstellungen oder den Sitzungsstatus verwaltet. Das daraus entstehende Geflecht aus Mikro-Sicherheitsrichtlinien bietet zweifellos viele der gleichen Vorteile wie Microservices selbst, nämlich eine feingranulare Kontrolle und eine gewisse elegante Einfachheit. Gleichzeitig wird es jedoch zu einem betrieblichen Albtraum, da die Richtlinien plötzlich mit den Diensten verschoben werden müssen, wo auch immer diese in der Architektur auftauchen.

Auch die Bereitstellung wird plötzlich exponentiell schwieriger – so, als würde man von einer einfachen Tanzschrittfolge zum anspruchsvolleren Flamenco wechseln, mit deutlich mehr Schritten und viel mehr Bewegung auf der Tanzfläche (im Rechenzentrum). Orchestrierung und Automatisierung werden unverzichtbar, um die nötige Konsistenz und Vorhersehbarkeit zu gewährleisten und alle Komponenten zum richtigen Zeitpunkt an ihren Platz zu bringen.

Die Verantwortlichen für die Bereitstellung dieser Netzwerk- und Sicherheitsdienste für Anwendungen müssen erkennen, dass es sich nicht mehr um dasselbe Schiff handelt – ganz gleich, wie es aus der Vogelperspektive erscheinen mag. Es klingt einfach: Eine Anwendung wird lediglich durch zehn Dienste ersetzt. Voilà! Die Anwendung wurde neu erschaffen, genau wie das Schiff des Theseus. Aus betrieblicher Sicht ist dieses Schiff jedoch keineswegs dasselbe. Die Verbindungen (Integration) im neuen Schiff sind völlig anders, was den Widerstand im Wasser (Netzwerk) verändern und dazu führen kann, dass das Schiff langsamer fährt.

Microservices sind noch immer eine relativ neue Entwicklung. Sie erobern (noch) nicht die Welt, doch es ist wichtig zu erkennen, dass es nicht damit getan ist, das Schiff des Theseus auseinanderzunehmen und wieder aufzubauen. Die für den Betrieb von Netzwerk- und Sicherheitsdiensten zuständigen Teams müssen die Perspektive des Philosophen statt die des Passagiers (Benutzers) einnehmen, denn die Auswirkungen auf Netzwerk und Sicherheit sind grundlegend anders.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie