Die serviceorientierte Architektur (SOA) wurde vor fast zehn Jahren für tot erklärt. Ein Faktor, der zu ihrem Niedergang beitrug, aber nur selten thematisiert wurde, war das Netzwerk. Die Latenz zwischen den Diensten hinderte Architekten daran, Anwendungen vollständig in Dienste mit der erforderlichen Granularität zu zerlegen, um die Wiederverwendung und letztlich die Entwicklung modular zusammensetzbarer Anwendungen zu fördern.
Hier kommt die Microservices-Architektur (MSA) ins Spiel. Ihre Prinzipien erfordern eine noch stärkere Zerlegung, wobei die Funktion (Verben) gegenüber dem Objekt (Substantive) als primäres Kriterium für die Aufteilung einer Anwendung im Vordergrund steht. Dieser scheinbar subtile Perspektivwechsel führt zu einer feineren Granularität der Services, denn in jedem System gibt es weitaus mehr Funktionen als Objekte.
Das Netzwerk ist bereit. Die Geschwindigkeiten und Übertragungsraten des physischen Netzwerks sind drastisch gestiegen. Auch die Rechenleistung hat sich gemäß dem mooreschen Gesetz weiterentwickelt, sodass die Netzwerklatenz kaum noch eine Rolle spielt.
Leider wird die Kommunikationslatenz an ihre Stelle treten.
Wir haben die Komplexität des Internets im Inneren der Container-Umgebungen nachgebildet, die zur Bereitstellung von Microservices verwendet werden. Ein Microservice benötigt zwar möglicherweise kein DNS, ist aber dennoch auf dieselbe Art der namensbasierten Auflösung angewiesen, auf der auch das Internet beruht. Anwendungs-Tags – also Metadaten – müssen in eine IP-Adresse übersetzt werden. Service-Registrys und komplexe IP-Tabelleneinträge fungieren als Miniatur-DNS, indem sie Tags in Adressen übersetzen und so die Kommunikation zwischen Diensten ermöglichen.
Die mit diesem Prozess verbundene Latenz wird durch die Kurzlebigkeit von Microservices und den zugehörigen Containern zusätzlich verschärft. Da ihre Lebensdauer nicht in Stunden oder Monaten, sondern in Sekunden oder Minuten gemessen wird, muss die Namensauflösung bei jedem Aufruf erfolgen. Die Gültigkeitsdauer (Time to Live, TTL) beträgt in der Containerwelt somit praktisch null.
Selbst wenn wir diese Nachbildung einer der größten Ursachen für Kommunikationslatenz außer Acht lassen, bleibt immer noch die mit TCP verbundene Latenz. Der Aufbau oder Abbau einer TCP-Verbindung ist nicht kostenlos – und war es auch noch nie. Diese Latenzquelle ist zwar gering, summiert sich jedoch unweigerlich. Jede Verbindung – jeder Microservice –, die beziehungsweise der zur Ausführung einer einzelnen Transaktion erforderlich ist, erhöht die Latenz, bis schließlich die tolerierbare Verzögerungsgrenze überschritten wird.
HTTP/2 löst dieses Problem trotz der grundlegenden Änderungen in seinem Verhalten nicht. HTTP/2 wurde entwickelt, um die Übertragung mehrerer Objekte über dieselbe Verbindung zu ermöglichen und dadurch die Latenz bei Inhalten mit mehreren Objekten wie Webseiten und webbasierten Anwendungen zu verringern. Microservices sind idealerweise so konzipiert, dass jeder Dienst eine einzige Antwort zurückgibt. Mehrere Anfragen über eine bestehende Verbindung reduzieren zwar den Kommunikationsaufwand, doch ist dies in einem System nicht möglich, in dem mehrere Anfragen auf mehrere eigenständige Dienste verteilt werden.
Das Problem ist also nicht die Netzwerklatenz, sondern die Kommunikationslatenz. Die Anzahl der Verbindungen spielt weiterhin eine Rolle, und Verbesserungen an Protokollen, die die Leistung webbasierter Kommunikation mit mehreren Transaktionen steigern sollen, helfen bei Transaktionen über mehrere Dienste hinweg nicht weiter.
Das Ergebnis ist SOMA: serviceorientierte Mikroarchitekturen. Ein seltsamer Hybrid aus serviceorientierten Architekturen und Microservice-Architekturen, bei dem man sich fragt, wo die eine endet und die andere beginnt. Die Zerlegung von Anwendungen in ihre einzelnen funktionsbasierten Dienste wird durch die Kommunikationslatenz und letztlich durch die Wartbarkeit der Codebasis begrenzt. Fortschritte bei Netzwerken haben zwar die Granularität erhöht, mit der eine Zerlegung sinnvoll umgesetzt werden kann, diese Einschränkung jedoch nicht beseitigt. Hinzu kommt, dass es in einer Anwendung um Größenordnungen mehr Funktionen als Objekte gibt. Dadurch wird die Verwaltung einer rein auf Microservices basierenden Anwendung für den Netzwerkbetrieb – ganz zu schweigen von den Anwendungsentwicklern – zu einem logistischen Albtraum. In Verbindung mit dem grundlegenden Problem der Kommunikationslatenz führt dies dazu, dass Unternehmen zunehmend objektorientierte Microservices statt wirklich funktionsorientierter Microservices entwickeln.
Letztlich ist dies der Grund, warum Anwendungen über die traditionelle Drei-Schichten-Architektur hinaus zerlegt werden, jedoch nicht so weit, dass sie eine getreue Umsetzung einer funktionsbasierten Zerlegung darstellen.
Solange wir die inhärente Latenz verbindungsbasierter Kommunikation (TCP) nicht in den Griff bekommen – sei es durch etwas Neues oder durch gezielte Optimierungen der Implementierungen auf Systemebene –, werden wir weiterhin auf Microservices-Architekturen beschränkt sein, die weniger „Micro“ und mehr „Services“ sind.
Über den Autor
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Ähnliche Blogbeiträge
Ein umfassender Leitfaden zur Bereitstellung und Sicherheit von KI-Anwendungen
Entdecken Sie optimale Strategien für die Absicherung und Bereitstellung von KI-Anwendungen.
KI zulassen und einführen? Lehren aus der Public Cloud
Die Einführung von KI steht unmittelbar bevor und könnte entscheidend sein, um wettbewerbsfähig zu bleiben. Daher muss die IT-Sicherheit proaktiv handeln und der KI-Einführung schon jetzt einen Schritt voraus sein, um sie auf einen risikogerechten Weg zu lenken.
Stand der Anwendungsstrategie 2022: Zeit für die Modernisierung des Betriebs
Es ist deutlich geworden, dass Unternehmen ihren Fokus erneut auf die Geschäftsfunktionen richten müssen, um die Dynamik ihrer digitalen Transformation aufrechtzuerhalten. Kundenerlebnisse haben zwar weiterhin Priorität, doch auch Geschäftsfunktionen wie Recht, Personalwesen und Finanzen müssen digitalisiert werden. Das bedeutet, dass CIOs das Steuer übernehmen, während sich die digitale Transformation von der Modernisierung von Anwendungen hin zur Modernisierung von Betriebsabläufen verlagert.
F5s Weg zu einer vielseitigen Plattform für Anwendungsanalysen
F5 bietet heute die umfassendsten Anwendungsdienste entlang des gesamten Weges vom Code bis zum Kunden. Künftig werden wir verstärkt auf Anwendungstelemetrie und -analysen setzen, damit unsere Kunden wertvolle Erkenntnisse über ihre Anwendungen, Geschäftsabläufe und Benutzererlebnisse gewinnen können. Beim Ausbau unserer Cloud-Analysefunktionen werden wir ML und KI noch stärker nutzen, um unsere Kunden bei der Verbesserung ihrer Geschäftsdienste zu unterstützen.
Telemetrie: Eine andere Art von Daten
Verwenden wir den Begriff „Telemetrie“ nur, weil er attraktiver klingt als „Daten“? Letztlich sind sowohl Daten als auch Telemetrie strukturierte Informationseinheiten. Es ist kein Verbrechen, die Begriffe synonym zu verwenden. Doch wenn man es genau nimmt, gibt es einen Unterschied. Und dieser Unterschied wird immer wichtiger werden, je weiter Unternehmen in die Datenökonomie vordringen.
MTTR bedeutet nicht „Mean Time to Reboot“
„Schnell scheitern“ lautet heute das Mantra für mehr Geschwindigkeit. Ob in DevOps oder im Geschäftsleben: Wer in einer digitalen Wirtschaft agiert, muss eine möglichst perfekte Verfügbarkeit gewährleisten.