Über Monolithen versus Microservices
Microservices (und ihre oft erwähnten besten Freunde, die Container) erobern zunehmend die Herzen und Köpfe von Entwicklern aller Art. Es sind nicht nur Startups, die die lose gekoppelten, API-basierten, granularen Designprinzipien von Microservices übernehmen; auch große Unternehmen steigen in das Spiel ein.
Mit der zunehmenden Akzeptanz ( Datadog , ein Anbieter für die Überwachung von Cloud-Infrastrukturen, verzeichnete in den zwölf Monaten seit September 2014 fast ein fünffaches Wachstum) gehen auch die lautstarken Rufe einher, die den Tod monolithischer Anwendungen und ihrer völlig ungeeigneten Architektur verkünden, die nicht nur veraltet, sondern schlicht und ergreifend schlecht seien.
Doch wie in einem kürzlich erschienenen Artikel auf Gigaom angemerkt wurde , müssen Kompromisse bedacht werden, bevor man den Presslufthammer ausholt und jeden Monolithen in hundert verschiedene Mikroservices zerlegt. Dies ist übrigens kein neues Konzept. Der Vater der Microservices, Martin Fowler, schrieb bereits vor langer Zeit über diese Kompromisse und warnte vor einer Vorgehensweise, die man nur als „blinde Übernahme“ von Microservices bezeichnen kann. Tatsächlich bringt der Gigaom-Artikel im Wesentlichen die gleichen Argumente vor wie Fowler, wenn auch in einem prägnanteren Format.
Wenn Sie nach der Kurzfassung zu beiden suchen, läuft es im Grunde auf Folgendes hinaus: Microservices erhöhen die Betriebskomplexität und können sich hinsichtlich der Leistung negativ auf das Anwendungserlebnis auswirken. Beides sind unerwünschte – und oft unbeabsichtigte – Folgen, die im Vorfeld verstanden werden müssen, bevor der Typ dort drüben in Ihrem Rechenzentrum mit dem allegorischen Presslufthammer loslegt.
Abgesehen davon stellt sich die Frage, warum zum Teufel es Lori interessiert? Schließlich sind weder sie noch F5 im Geschäft der Entwicklung oder Gestaltung von Anwendungen tätig. F5 wird diese Apps bereitstellen, egal, ob es sich um Monolithen, Mikroservices oder die nächste App-Architektur hier handelt>.
Alles wahr. Aber unser Geschäft besteht darin, die Anwendungsdienste zu erstellen und einzusetzen, die diese Anwendungen bereitstellen, und aktuelle Entwicklungen wie DevOps und Microservices (sowie das Containerfieber) werfen in unserem Bereich dieselben Fragen auf. Sollten Sie nämlich die App-Dienste, die typischerweise auf einer ADC-Plattform bereitgestellt werden, in ihre feingranulareren, anwendungsaffinen Dienste zerlegen, und zwar in einem Modell, das stärker auf die Microservices-Architektur ausgerichtet ist?
Es geht immer noch um Kompromisse
Unabhängig davon, ob wir über App-Architektur oder App-Service-Architekturen sprechen, besteht die Antwort weiterhin darin, sich vor einer solchen Entscheidung über die damit verbundenen Kompromisse im Klaren zu sein.
Der Plattform-Ansatz (monolithischer Ansatz)
Dies ist der traditionelle Ansatz zur Bereitstellung der App-Dienste, die zum Sichern, Skalieren und Optimieren von Anwendungen aller Art erforderlich sind. Die Dienste werden auf einer einzigen, gemeinsam genutzten Plattform bereitgestellt. Aufgrund der Architektur des zugrunde liegenden Proxys bietet dieser Ansatz den Vorteil einer Leistungsverbesserung. Das liegt daran, dass alle Anfragen (und Antworten) die erforderlichen Dienste durchlaufen können, ohne dieselbe Umgebung zu verlassen. Dies bedeutet, dass keine zusätzlichen Netzwerksprünge (und die damit verbundene Latenz) oder Verbindungen (Ressourcen, Latenz) erforderlich sind. Jeder Dienst kann weiterhin einzeln skaliert und verwaltet werden, sie sind jedoch alle von einer einzigen, gemeinsam genutzten Hardware (COTS oder benutzerdefiniert) abhängig. Das bedeutet, dass die gemeinsam genutzte Hardware ein einzelner Ausfallpunkt ist, der sich nicht nur auf einen, sondern auf viele Dienste auswirkt.
Der Per-App-Proxy-Ansatz (Microservices)
Dieses Modell ist stärker auf DevOps und neue Praktiken der Anwendungsarchitektur ausgerichtet. Jeder Dienst wird einzeln bereitgestellt, verwaltet und skaliert. Dadurch entstehen zwar zusätzliche Verwaltungskosten (schließlich müssen mehr Instanzen verwaltet werden), einige dieser Kosten werden jedoch gemindert, wenn alle Dienste auf derselben Plattform bereitgestellt werden. Allerdings besteht die Möglichkeit, Dienste verschiedener Anbieter zu kombinieren. Die Vorteile dieses Ansatzes bestehen darin, dass die Dienste enger mit der Anwendungsarchitektur verknüpft und somit als Teil davon integriert werden können, einschließlich der Integration mit gängigen Automatisierungs-Frameworks.
Die gleichen Nachteile – nämlich Leistung und zunehmende Komplexität – sind mit der Zerlegung der Anwendungsbereitstellung in ihre zusammengesetzten Anwendungsdienste verbunden. Umgekehrt gelten die gleichen Gründe, warum Entwickler Microservices begrüßen und Monolithen meiden – nämlich der Wunsch nach Agilität, Vielfalt und Modularität – auch für die Anwendungsbereitstellung.
Ich zitiere einfach Martin Fowler: „ Viele Entwicklungsteams haben festgestellt, dass der Microservices-Architekturstil einen besseren Ansatz als eine monolithische Architektur darstellt. Andere Teams haben jedoch festgestellt, dass sie eine Belastung darstellen, die die Produktivität mindert. Wie jeder Architekturstil bringen Microservices Kosten und Vorteile mit sich. Um eine sinnvolle Entscheidung zu treffen, müssen Sie diese verstehen und auf Ihren spezifischen Kontext anwenden.“
Diese Aussage trifft in gleicher Weise auf Anwendungsdienste zu. Sowohl ein traditioneller (monolithischer) als auch ein moderner (Microservices-)Ansatz sind mit Kosten und Nutzen verbunden, die im Kontext der Anwendung, die sie bereitstellen, sichern und optimieren sollen, berücksichtigt werden müssen.