Mikrodienste: Weniger Mikro und mehr Dienstleistungen
Die serviceorientierte Architektur (SOA) wurde vor fast zehn Jahren für tot erklärt. Ein Faktor, der zu seinem Niedergang beigetragen hat – aber selten diskutiert wird – war das Netzwerk. Aufgrund der Latenz zwischen den Diensten konnten Architekten die Anwendungen nicht mit der nötigen Granularität in Dienste zerlegen, um die Wiederverwendung und letztlich die Erstellung zusammensetzbarer Anwendungen zu fördern.
Geben Sie die Microservices-Architektur (MSA) ein. Seine Prinzipien erfordern eine noch stärkere Zerlegung, wobei der Schwerpunkt auf der Funktion (Verben) statt auf dem Objekt (Substantive) als primärem Kriterium für die Aufteilung einer Anwendung liegt. Diese scheinbar subtile Schwerpunktverlagerung führt zu einer größeren Granularität der Dienste; in einem bestimmten System gibt es viel mehr Funktionen als Objekte.
Das Netzwerk ist bereit. Geschwindigkeiten und Durchsätze des physischen Netzwerks haben dramatisch zugenommen. Auch die Computertechnik hat sich im Einklang mit dem Mooreschen Gesetz weiterentwickelt und dafür gesorgt, dass Netzwerklatenzen praktisch kein Thema mehr sind.
Leider tritt an ihre Stelle eine Kommunikationslatenz ein.
Wir haben die Komplexität des Internets im Inneren der Containerumgebungen nachgebildet, die zum Bereitstellen von Microservices verwendet werden. Auch wenn ein Microservice kein DNS benötigt, basiert er dennoch auf der gleichen Art der namensbasierten Auflösung, auf der auch das Internet basiert. Anwendungstags – Metadaten – müssen in eine IP-Adresse übersetzt werden. Dienstregister und komplexe IP-Tabelleneinträge fungieren als Miniatur-DNS, übersetzen Tags in Adressen und ermöglichen die Kommunikation zwischen Diensten.
Die mit diesem Prozess verbundene Latenz wird durch die kurzlebige Natur der Microservices und der zugehörigen Container noch verschärft. Da die Lebensdauer nicht in Stunden oder Monaten, sondern in Sekunden oder Minuten gemessen wird, muss die Namensauflösung bei jedem Aufruf erfolgen. Die Lebenszeit (TTL) innerhalb der Containerwelt beträgt praktisch Null.
Selbst wenn wir diese Reproduktion einer der größten Ursachen für Kommunikationslatenz ignorieren, bleibt uns die mit TCP verbundene Latenz. Das Herstellen oder Trennen einer TCP-Verbindung ist nicht kostenlos und war es auch nie. Diese Latenzquelle ist zwar gering, wirkt sich jedoch absolut positiv aus. Jede Verbindung – jeder Mikrodienst – die zur Ausführung einer einzelnen Transaktion erforderlich ist, führt zu einer Latenz, die letztendlich die Verzögerungstoleranz überschreitet.
Trotz seiner dramatischen Verhaltensänderungen behebt HTTP/2 dieses Problem nicht. HTTP/2 soll die Übertragung mehrerer Objekte über dieselbe Verbindung erleichtern und dadurch die Latenz für Inhalte mit mehreren Objekten wie Webseiten und webbasierte Anwendungen reduzieren. Microservices sind idealerweise so konzipiert, dass jeder Dienst eine einzelne Antwort zurückgibt. Während mehrere Anfragen über eine bestehende Verbindung den Kommunikationsaufwand sicherlich reduzieren, ist dies in einem System, in dem mehrere Anfragen auf mehrere einzelne Dienste verteilt sind, nicht möglich.
Das Problem ist also nicht die Netzwerklatenz, sondern die Kommunikationslatenz. Verbindungen zählen noch immer, und Verbesserungen bei Protokollen, die die Leistung webbasierter, multitransaktionaler Kommunikation verbessern sollen, helfen bei Multiservice-Transaktionen nicht.
Das Ergebnis ist SOMA. Serviceorientierte Mikroarchitekturen. Ein seltsamer Hybrid aus serviceorientierten und Microservice-Architekturen, bei dem man sich fragt, wo das eine endet und das andere beginnt. Die Zerlegung von Anwendungen in ihre zusammengesetzten, funktionsbasierten Dienste wird durch die Kommunikationslatenz und letztendlich durch die Nachhaltigkeit der Codebasis eingeschränkt. Zwar ist durch die Fortschritte in der Netzwerktechnik die Granularität gestiegen, mit der eine Zerlegung sinnvoll durchgeführt werden kann, aber die Einschränkung ist dadurch nicht beseitigt worden. Ein weiterer Faktor ist, dass eine Anwendung um ein Vielfaches mehr Funktionen als Objekte enthält. Das macht die Aufgabe der Verwaltung einer Anwendung mit reiner Microservices-Architektur zu einem logistischen Albtraum für den Netzwerkbetrieb, ganz zu schweigen von App-Entwicklern. Aufgrund der inhärenten Probleme der Kommunikationslatenz entwickeln Unternehmen zunehmend objektorientierte Microservices anstelle wirklich funktionsorientierter Microservices.
Dies ist letztendlich der Grund, warum wir eine Anwendungszerlegung sehen, die über die traditionelle Drei-Schichten-Architektur hinausgeht, jedoch nicht in dem Maße, dass sie eine getreue Darstellung einer funktionsbasierten Zerlegung darstellt.
Solange wir uns nicht mit der inhärenten Latenz bei verbindungsbasierter (TCP-)Kommunikation befassen – sei es mit etwas Neuem oder indem wir uns auf Implementierungen auf Systemebene konzentrieren –, sind wir weiterhin auf Microservices-Architekturen beschränkt, die weniger Mikro und mehr Dienste bieten.