Containernative App-Dienste

Eine wachsende Zahl von App-Diensten ist ein integraler Bestandteil einer Cloud-native-Architektur. Dies ist einer der Gründe, warum wir eine Verschiebung der Verantwortung für App-Dienste vom IT-Betrieb hin zu DevOps beobachten.

Wir verfolgen in unserer State of App Services -Studie über 30 verschiedene Anwendungsdienste. Es gibt noch mehr, und wir überprüfen die Liste jedes Jahr, um zu entscheiden, was weggelassen und was hinzugefügt werden muss.

Für das Jahr 2020 haben wir mehrere App-Dienste in breitere Kategorien zusammengefasst. Beispielsweise wurden Netzwerk-Firewall, Anti-Spam, IPS/IDS und Spam-Abwehr zu „gemeinsamen Sicherheitsdiensten“ zusammengefasst.  Wir haben uns aus zwei Gründen für diesen Ansatz entschieden. Erstens, weil die Daten aus sechs Jahren Gruppierungen von App-Diensten mit sehr ähnlichen Bereitstellungsraten anzeigten. Zweitens, weil wir Platz für neue App-Dienste schaffen und unsere bereits sehr geduldige Teilnehmerbasis nicht überfordern wollten.

Bei diesen neuen App-Diensten handelt es sich fast ausschließlich um containernative App-Dienste. Diese werden im Allgemeinen – wenn auch nicht immer – als Teil der Betriebsumgebung bereitgestellt, die zum Bereitstellen einer Cloud-nativen Anwendung erforderlich ist. Denken Sie an Ingress-Kontrolle, Service-Erkennung und Service-Mesh. Auch API-Gateways sind häufig eng mit Cloud-nativen Anwendungen gekoppelt, obwohl ihre Verwendung im Großen und Ganzen auf jede API-basierte Anwendung abgestimmt ist.

Angesichts ihrer zunehmenden Bedeutung für die Bereitstellung moderner, Cloud-nativer Apps und der unglaublichen Bereitstellungsraten, die wir beobachten, scheint es ein guter Zeitpunkt zu sein, diese Verfechter Cloud-nativer Ansätze etwas näher zu beleuchten.

Schutz vor eindringendem Material

Stand der Bereitstellung von Anwendungsdiensten 2020: Schutz vor eindringendem Material

Ingress Control ist ein in der Kubernetes-Welt eingeführtes Konzept zum Aufteilen und Zerlegen von HTTP-Anfragen. Es ermöglicht Betreibern, eine URI einfach einem bestimmten Kubernetes-Dienst zuzuordnen. Dadurch wird die Weiterleitung eingehender (Ingress-)Anfragen an die richtige Microservice-Instanz ermöglicht.

Dies war kein neues Konzept. Begeisterte Leser werden sich erinnern, dass ich oft die Vorzüge des HTTP-Routings (Layer 7) preise, insbesondere als Architekturkomponente, die zur Unterstützung effizienterer Skalierungsstrategien entwickelt wurde. Falls Sie sich nicht erinnern oder gerade erst zu uns gestoßen sind, ist diese Keynote eine gute Auffrischung: Sie glauben also, dass Sie skalieren können?

Neu ist die Art und Weise der Verwaltung der „Karten“. 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 Status eines Clusters haben muss. Das bedeutet die Integration mit den entsprechenden Kubernetes-Komponenten über die Betriebs-API.

Durch diese Integration wird die Eingangskontrolle an die Umgebung gebunden und somit in die App-Architektur integriert. Ein voll funktionsfähiger Ingress-Controller ist von Natur aus „containernativ“, da er Teil der Infrastruktur ist, die zum Skalieren und Betreiben einer Cloud-nativen Anwendung erforderlich ist. 

Diensterkennung

Stand der Bereitstellung von Anwendungsdiensten 2020: Diensterkennung

Eine interessante Tatsache bei Cloud-native-Anwendungen ist die Lebensdauer ihrer zusammengesetzten Teile. Die dynamische Natur der Skalierbarkeit innerhalb eines Containerclusters bedeutet zwangsläufig, dass sich „Container“ im ständigen Wandel befinden. Die neuesten Daten von Sysdig zeigen einen zunehmenden Fluss: 39 % der Container haben eine Lebensdauer von weniger als einer Minute und 54 % von weniger als fünf Minuten.

Das Problem dabei ist, dass andere Komponenten diese Container finden können müssen.

Dies ist die Daseinsberechtigung der Service Discovery- Komponente. Diese Komponenten werden innerhalb des Containerclusters ausgeführt und dienen als „autoritative Quelle“ für Dienste. Interessierte Parteien können diese Komponente abfragen, um herauszufinden, wie eine Verbindung zu einem bestimmten Dienst hergestellt und mit ihm kommuniziert werden kann. Durch die Echtzeitverfolgung der Dienste behebt die Diensterkennungskomponente die Volatilität eines Clusters und ermöglicht die ordnungsgemäße Funktion anderer Komponenten, beispielsweise der Eingangskontrolle. 

Servicenetz

Stand der Bereitstellung von Anwendungsdiensten 2020: Servicenetz

Service Mesh ist wahrscheinlich der umstrittenste aller containernativen App-Dienste. Nicht aufgrund seines konzeptionellen Werts, sondern aufgrund von Implementierungspräferenzen. Service-Meshes sind dazu konzipiert, Probleme mit Sichtbarkeit, Skalierung und Sicherheit innerhalb von Container-Clustern zu lösen. Sie werden als hypervernetzte Proxys (entweder Sidecar oder pro App) implementiert und bieten sowohl Entwicklern als auch Betreibern zahlreiche Funktionen.

Ein Service Mesh ist kein Anwendungsdienst, den Sie außerhalb eines Containerclusters finden. Wie die Erkennung und die Eingangskontrolle ist ein Service Mesh eng in die Containerumgebung integriert. Dadurch wird es auch zu einem containernativen App-Dienst. 

Containernative App-Dienste

Wir (die Branche und das Unternehmens-Wir) haben Anwendungsdienste noch nie zuvor auf diese Weise kategorisiert. Natürlich kategorisieren wir auf Grundlage ihres primären Verwendungszwecks: Sicherheit, Verfügbarkeit, Leistung, Mobilität und Identität. Dabei handelt es sich jedoch um weit gefasste Nutzungskategorien und keine davon ist einer App-Architektur eigen.

Aufgrund der Integration in eine Cloud-native Architektur und der Abhängigkeiten davon kann dies für diese App-Dienste (und alle anderen, die in Zukunft auftauchen könnten) jedoch erforderlich sein. Das liegt daran, dass das Wachstum des einen (des App-Dienstes) eindeutig ein Wachstum des anderen (der App-Architektur) anzeigt – und umgekehrt. Dies ist eine einzigartige Situation, in der App-Dienste und Apps so eng miteinander verknüpft sind, dass beide sehr ähnliche Bereitstellungsraten aufweisen. 

Ähnlich wie wir zwischen mobilen iOS- und Android-Apps unterscheiden, kann es für uns sinnvoll sein, jene App-Dienste, die nur für den Betrieb in einer Containerumgebung konzipiert sind, als „containernativ“ zu kennzeichnen, im Gegensatz zu jenen, die überall sonst funktionieren.

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