Container-native App-Services

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Immer mehr Anwendungsdienste sind ein integraler Bestandteil einer Cloud-nativen Architektur. Dies ist mit ein Grund dafür, dass die Verantwortung für Anwendungsdienste zunehmend vom IT-Betrieb auf DevOps übergeht.

In unserer Studie „State of App Services“ untersuchen wir mehr als 30 verschiedene Anwendungsdienste. Es gibt noch weitere, und jedes Jahr überprüfen wir die Liste, um zu entscheiden, welche Dienste wir streichen und welche wir hinzufügen.

Für 2020 haben wir mehrere Anwendungsdienste in übergeordneten Kategorien zusammengefasst. So wurden beispielsweise Netzwerk-Firewall, Anti-Spam, IPS/IDS und Maßnahmen zur Spam-Abwehr unter „allgemeine Sicherheitsdienste“ gebündelt. Für diesen Ansatz haben wir uns aus zwei Gründen entschieden. Erstens zeigten die Daten aus sechs Jahren, dass sich Anwendungsdienste mit sehr ähnlichen Bereitstellungsraten gruppieren lassen. Zweitens wollten wir Platz für neue Anwendungsdienste schaffen und unsere ohnehin schon sehr geduldigen Befragten nicht überfordern.

Bei diesen neuen Anwendungsdiensten handelt es sich fast ausschließlich um container-native Anwendungsdienste. Sie werden in der Regel – wenn auch nicht immer – als Teil der Betriebsumgebung bereitgestellt, die für die Bereitstellung einer Cloud-nativen Anwendung erforderlich ist. Dazu zählen Ingress-Steuerung, Service Discovery und Service Mesh. Auch API-Gateways sind häufig eng mit Cloud-nativen Anwendungen gekoppelt, obwohl sie grundsätzlich für jede API-basierte Anwendung eingesetzt werden können.

Angesichts ihrer wachsenden Bedeutung für die Bereitstellung moderner, cloudnativer Anwendungen und der beeindruckenden Bereitstellungsraten, die wir beobachten, scheint jetzt ein guter Zeitpunkt zu sein, diese Vorreiter cloudnativer Ansätze etwas näher zu beleuchten.

Ingress-Steuerung

Bereitstellung laut „State of Application Services 2020“: Ingress-Steuerung

Ingress-Steuerung ist ein in Kubernetes eingeführtes Konzept zur gezielten Aufteilung und Verarbeitung von HTTP-Anfragen. Damit können Betreiber einen URI ganz einfach einem bestimmten Kubernetes-Service zuordnen. So lassen sich eingehende (Ingress-)Anfragen an die richtige Microservice-Instanz weiterleiten.

Das war kein neues Konzept. Aufmerksame Leser werden sich daran erinnern, dass ich häufig die Vorzüge des HTTP-Routings (Layer 7) hervorhebe, insbesondere als Architekturkomponente, die effizientere Skalierungsstrategien unterstützen soll. Falls Sie sich nicht daran erinnern oder gerade erst dazugestoßen sind, bietet diese Keynote eine gute Auffrischung: Sie glauben also, skalieren zu können?

Neu ist die Art und Weise, wie die „Zuordnungen“ verwaltet werden. Ingress-Controller müssen basierend auf den aktuellen Bedingungen innerhalb eines Container-Clusters dynamisch aktualisiert werden. Das bedeutet, dass ein Ingress-Controller Einblick in den aktuellen Zustand eines Clusters haben muss. Dafür ist eine Integration mit den entsprechenden Kubernetes-Komponenten über deren Betriebs-API erforderlich.

Diese Integration bindet die Ingress-Steuerung an die Umgebung und macht sie so zu einem festen Bestandteil der Anwendungsarchitektur. Ein voll funktionsfähiger Ingress-Controller ist von Natur aus „container-nativ“, da er Teil der Infrastruktur ist, die für die Skalierung und den Betrieb einer Cloud-nativen Anwendung erforderlich ist.

Diensterkennung

Bereitstellung laut „State of Application Services 2020“: Service Discovery

Eine interessante Tatsache bei Cloud-nativen Anwendungen ist die Lebensdauer ihrer einzelnen Komponenten. Aufgrund der dynamischen Skalierbarkeit innerhalb eines Container-Clusters sind „Container“ zwangsläufig einem ständigen Wandel unterworfen. Die neuesten Daten von Sysdig zeigen eine zunehmende Dynamik: 39 % der Container bestehen weniger als eine Minute und 54 % weniger als fünf Minuten.

Das Problem dabei ist, dass andere Komponenten in der Lage sein müssen, diese Container zu finden.

Dies ist die Daseinsberechtigung der Service-Discovery-Komponente. Diese Komponenten werden innerhalb des Container-Clusters ausgeführt und dienen als „maßgebliche Quelle“ für Dienste. Interessierte Parteien können diese Komponente abfragen, um herauszufinden, wie sie eine Verbindung zu einem bestimmten Dienst herstellen und mit ihm kommunizieren können. Indem die Service-Discovery-Komponente Dienste in Echtzeit erfasst, trägt sie der Dynamik eines Clusters Rechnung und ermöglicht es anderen Komponenten – etwa der Ingress-Steuerung –, ordnungsgemäß zu funktionieren.

Service Mesh

Bereitstellung laut „State of Application Services 2020“: Service Mesh

Service Mesh ist wahrscheinlich der umstrittenste der für Container konzipierten Anwendungsdienste. Das liegt nicht an seinem konzeptionellen Wert, sondern an unterschiedlichen Präferenzen bei der Implementierung. Service Meshes sollen Probleme hinsichtlich Transparenz, Skalierbarkeit und Sicherheit innerhalb von Container-Clustern lösen. Sie werden als hochgradig vernetzte Proxys implementiert – entweder als Sidecar oder pro Anwendung – und bieten eine Vielzahl von Funktionen für Entwickler und Betreiber.

Ein Service Mesh ist kein Anwendungsdienst, der außerhalb eines Container-Clusters zu finden ist. Wie die Service-Erkennung und die Ingress-Steuerung ist auch ein Service Mesh eng in die Container-Umgebung integriert. Damit ist es ebenfalls ein Container-nativer Anwendungsdienst.

Container-native Anwendungsdienste

Wir (die Branche und wir als Unternehmen) haben Anwendungsdienste noch nie auf diese Weise kategorisiert. Natürlich kategorisieren wir sie nach ihrem primären Verwendungszweck: Sicherheit, Verfügbarkeit, Leistung, Mobilität und Identität. Dies sind jedoch weit gefasste Nutzungskategorien, von denen keine spezifisch für eine Anwendungsarchitektur ist.

Doch die Integration in eine Cloud-native-Architektur und die Abhängigkeiten von ihr könnten eine solche Kategorisierung für diese Anwendungsdienste (und alle weiteren, die künftig hinzukommen könnten) erforderlich machen. Denn das Wachstum des einen Bereichs (der Anwendungsdienste) ist ein klares Indiz für das Wachstum des anderen (der Anwendungsarchitektur) – und umgekehrt. Dies ist eine besondere Situation, in der Anwendungsdienste und Anwendungen so eng miteinander verflochten sind, dass beide sehr ähnliche Bereitstellungsraten aufweisen werden.

Ähnlich wie wir zwischen mobilen iOS- und Android-Apps unterscheiden, könnte es sinnvoll sein, App-Dienste, die ausschließlich für den Betrieb in einer containerisierten Umgebung konzipiert sind, als „container-nativ“ zu kennzeichnen und sie so von Diensten abzugrenzen, die auch in anderen Umgebungen eingesetzt werden können.

Unabhängig davon, wie wir sie kategorisieren, sind sie definitiv auf dem Vormarsch – ebenso wie die Apps, die von ihnen abhängen.

Ü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