Microservices (und ihr häufig erwähnter bester Freund, Container) erobern zunehmend die Herzen und Köpfe von Entwicklern in allen Bereichen. Nicht nur Start-ups setzen auf die lose gekoppelten, ausschließlich API-basierten und granularen Designprinzipien von Microservices; auch große Unternehmen steigen ein.
Mit der zunehmenden Verbreitung (Datadog, ein Anbieter für die Überwachung von Cloud-Infrastrukturen, verzeichnete in den zwölf Monaten seit September 2014 ein fast fünffaches Wachstum) werden auch die Stimmen immer lauter, die monolithische Anwendungen für tot und deren völlig ungeeignete Architektur nicht nur für veraltet, sondern schlichtweg für schlecht erklären.
Doch wie ein kürzlich erschienener Artikel auf Gigaom feststellte, müssen die damit verbundenen Kompromisse bedacht werden, bevor man den Presslufthammer herausholt und jede monolithische Anwendung in hundert verschiedene Microservices zerlegt. Dieses Konzept ist übrigens nicht neu. Der Vater der Microservices, Martin Fowler, schrieb bereits vor langer Zeit über diese Kompromisse und warnte vor dem, was man nur als „blinde Einführung“ von Microservices bezeichnen kann. Tatsächlich führt der Gigaom-Artikel im Großen und Ganzen dieselben Punkte wie Fowler an, wenn auch in knapperer Form.
Wenn Sie die Kurzfassung zu beiden Artikeln suchen, läuft es im Grunde darauf hinaus: Microservices erhöhen die betriebliche Komplexität und können sich hinsichtlich der Performance negativ auf die Anwendungserfahrung auswirken. Beides sind unerwünschte – und oft unbeabsichtigte – Folgen, die von Anfang an verstanden werden müssen, bevor der Typ da drüben in Ihrem Rechenzentrum den sprichwörtlichen Presslufthammer ansetzt.
Aber warum zum Teufel interessiert Lori das alles? Schließlich entwickeln oder konzipieren weder sie noch F5 Anwendungen. F5 wird diese Anwendungen bereitstellen – ganz gleich, ob es sich um Monolithen, Microservices oder <hier die nächste Anwendungsarchitektur einsetzen> handelt.
Das stimmt alles. Doch unser Geschäft besteht darin, die Anwendungsdienste zu entwickeln und bereitzustellen, über die diese Anwendungen ausgeliefert werden. Aktuelle Entwicklungen wie DevOps und Microservices (sowie der Container-Hype) werfen in unserem Bereich dieselben Fragen auf. Konkret: Sollten die üblicherweise auf einer ADC-Plattform bereitgestellten Anwendungsdienste in granularere, anwendungsspezifische Dienste aufgeteilt werden – nach einem Modell, das sich stärker an der Microservices-Architektur orientiert?
Nach wie vor geht es um Abwägungen
Unabhängig davon, ob es um die Architektur einer App oder die Architektur von App-Diensten geht, kommt es weiterhin darauf an, die damit verbundenen Zielkonflikte zu verstehen, bevor eine solche Entscheidung getroffen wird.
Der Plattformansatz (monolithisch)
Dies ist der traditionelle Ansatz zur Bereitstellung der Anwendungsdienste, die erforderlich sind, um Anwendungen aller Art abzusichern, zu skalieren und zu optimieren. Die Dienste werden auf einer einzigen, gemeinsam genutzten Plattform bereitgestellt. Aufgrund der Architektur des zugrunde liegenden Proxys bietet dieser Ansatz den Vorteil einer höheren Leistung. Denn alle Anfragen (und Antworten) können die erforderlichen Dienste durchlaufen, ohne dieselbe Umgebung zu verlassen. Dadurch sind weder zusätzliche Netzwerksprünge (und die damit verbundene Latenz) noch zusätzliche Verbindungen (Ressourcen, Latenz) erforderlich. Jeder Dienst kann weiterhin einzeln skaliert und verwaltet werden, doch alle sind von einer einzigen, gemeinsam genutzten Hardwarekomponente abhängig (handelsüblich oder kundenspezifisch). Damit stellt die gemeinsam genutzte Hardware einen Single Point of Failure dar, dessen Ausfall nicht nur einen, sondern viele Dienste beeinträchtigt.
Der Ansatz mit anwendungsspezifischen Proxys (Microservices)
Dieses Modell entspricht eher DevOps und neuen Praktiken der Anwendungsarchitektur. Jeder Dienst wird einzeln bereitgestellt, verwaltet und skaliert. Dies verursacht zwar zusätzlichen Verwaltungsaufwand (schließlich müssen mehr Instanzen verwaltet werden), doch ein Teil dieses Aufwands lässt sich reduzieren, wenn alle Dienste auf derselben Plattform bereitgestellt werden. Gleichzeitig bietet das Modell die Möglichkeit, Dienste verschiedener Anbieter flexibel miteinander zu kombinieren. Der Vorteil dieses Ansatzes besteht darin, dass die Dienste enger mit der Anwendungsarchitektur verknüpft und somit als deren Bestandteil integriert werden können – einschließlich der Einbindung in gängige Automatisierungs-Frameworks.
Die Zerlegung der Anwendungsbereitstellung in ihre einzelnen Anwendungsdienste bringt dieselben Nachteile mit sich – insbesondere Leistungseinbußen und eine zunehmende Komplexität. Umgekehrt gelten dieselben Gründe, aus denen Entwickler auf Microservices setzen und Monolithen vermeiden – nämlich der Wunsch nach Agilität, Vielfalt und Modularität –, auch für die Anwendungsbereitstellung.
Ich zitiere dazu einfach Martin Fowler: „Viele Entwicklungsteams sind zu dem Schluss gekommen, dass der Microservices-Architekturstil einer monolithischen Architektur überlegen ist. Andere Teams hingegen empfinden ihn als eine Belastung, die ihre Produktivität beeinträchtigt. Wie jeder Architekturstil bringen auch Microservices Kosten und Vorteile mit sich. Um eine sinnvolle Entscheidung zu treffen, muss man diese verstehen und auf den jeweiligen konkreten Kontext anwenden.“
Diese Aussage gilt gleichermaßen für Anwendungsdienste. Sowohl ein traditioneller (monolithischer) als auch ein moderner (auf Microservices basierender) Ansatz bringt Vor- und Nachteile mit sich, die im Kontext der Anwendung betrachtet werden müssen, deren Bereitstellung, Absicherung und Optimierung sie übernehmen sollen.
Ü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
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...