Zustandsbehaftete oder zustandslose Anwendungen

Der Zustand einer Anwendung (oder eines anderen Objekts) ist ihr Status oder ihre Qualität zu einem bestimmten Zeitpunkt. Ob etwas zustandsbehaftet oder zustandslos ist, hängt davon ab, wie lange der Zustand der Interaktion erfasst wird und wie diese Informationen gespeichert werden müssen. Eine zustandsbehaftete Anwendung speichert den Zustand oder Kontext ihrer Interaktionen mit Nutzenden, Systemen oder Komponenten. Dieser Zustand wird auf einer dauerhaften Storage-Lösung gespeichert, sodass die Anwendung selbst nach einem Neustart bestehen bleibt. Der Hauptunterschied zwischen zustandsbehafteten und zustandslosen Anwendungen besteht darin, dass zustandsbehaftete Anwendungen Informationen aus der Vergangenheit und der Gegenwart speichern, während diese Informationen für zustandslose Anwendungen nicht gespeichert werden.

Anwendungen mit Red Hat OpenShift transformieren

Eine zustandsbehaftete Anwendung ist ein Programm, das seinen Zustand beibehält, indem es bereits vorhandene Informationen und Prozesse über das Internet speichert, erfasst und darauf zurückgreift. In diesen Anwendungen verfolgt der Server den Zustand der einzelnen Sessions oder Interaktionen und speichert diese Informationen basierend auf früheren Anfragen der Nutzenden. Diese Sessions können so immer wieder genutzt werden, wie Online-Banking oder E-Mails. Sie werden im Kontext früherer Transaktionen durchgeführt, und die aktuelle Transaktion kann durch das, was bei früheren Transaktionen passiert ist, beeinflusst werden. Aus diesen Gründen verwenden zustandsbehaftete Apps stets dieselben Server, wenn sie eine Anfrage von einer Nutzerin oder einem Nutzer verarbeiten. 

Wenn eine zustandsbehaftete Transaktion unterbrochen wird, werden Kontext und Verlauf gespeichert, sodass Sie dort weitermachen können, wo Sie aufgehört haben. Zustandsbehaftete Apps erfassen Daten wie die Position von Fenstern, bevorzugte Einstellungen sowie die letzten Aktivitäten. Sie können sich zustandsbehaftete Transaktionen wie eine fortlaufende, regelmäßige Konversation mit derselben Person vorstellen.

Welche Use Cases für zustandsbehaftete Anwendungen gibt es?

Zustandsbehaftete Anwendungen sind erforderlich, wenn Systeme einen persistenten Kontext, kontinuierliche Feedbackschleifen oder ein fortlaufendes Tracking des Verhaltens von Nutzenden erfordern.

• Nutzerzentrierte Anwendungen: Nutzerzentrierte Anwendungen wie Social Media-Apps und E-Commerce-Sites speichern die Session ihrer angemeldeten Nutzenden, einschließlich ihrer Präferenzen und der Artikel im Warenkorb.
• IoT-Systeme: Ein IoT-System (Internet of Things) sendet, empfängt und analysiert Daten in einer kontinuierlichen Feedbackschleife. Ein Gerät reagiert auf der Basis historischer oder Echtzeitdaten auf einen sich im Zeitverlauf ändernden Zustand, beispielsweise Ihr Thermostat zu Hause.
• KI/ML-Modelltraining: KI/ML-Trainingsmodelle (Künstliche Intelligenz/Machine Learning) lernen von Daten und erinnern sich an diese. Dieser konstante Zustand des Lernens und Erinnerns hilft den Modellen dabei, auf voller Kapazität zu funktionieren.

Zustandslose Anwendungen oder Prozesse speichern keine Informationen über die vorherigen Interaktionen der Nutzenden. Das heißt, dass kein gespeichertes Wissen über oder keine Verweise auf frühere Transaktionen vorhanden sind. Daher werden sämtliche Transaktionen so durchgeführt, als würden sie zum ersten Mal erfolgen. Zustandslose Anwendungen bieten einen Service oder eine Funktion und verwenden ein Content Delivery Network (CDN), Web- oder Druckserver, um diese kurzfristigen Anfragen zu verarbeiten.

Ein Beispiel für eine zustandslose Transaktion wäre eine Online-Suche, um eine Frage zu beantworten, die Sie sich gestellt haben. Sie geben Ihre Frage in eine Suchmaschine ein und drücken die Eingabetaste. Wenn Ihre Transaktion unterbrochen oder versehentlich geschlossen wird, starten Sie einfach eine neue. Sie können sich zustandslose Transaktionen wie einen Verkaufsautomaten vorstellen: auf eine Anfrage folgt eine Reaktion.

Welche Use Cases für zustandslose Anwendungen gibt es?

Zustandslose Architekturen eignen sich besonders für isolierte, kurzfristige Umgebungen, in denen einzelne Anfragen nicht den historischen Kontext vorheriger Aktionen beibehalten müssen.

• REST APIs: REST APIs übertragen eine Darstellung des Ressourcenzustands an eine anfragende Person oder ein Endgerät. Die einzelnen API-Anfragen sind dabei eigenständig, und der Server speichert keine Informationen über die vorherigen Anfragen.
• Microservices: Microservices ermöglichen es einzelnen Kernfunktionen, innerhalb einer Anwendung unabhängig voneinander zu existieren. Deshalb eignen sich Microservices sowohl für zustandslose als auch für zustandsbehaftete Anwendungen.
• Serverless-Architekturen: Serverless-Architekturen sind darauf ausgelegt, isoliert auf ein Event zu reagieren. Sie speichern daher keinen Kontext aus vorherigen Aktionen und müssen keinen Zustand beibehalten. Serverless-Architekturen eignen sich am besten für asynchrone zustandslose Apps, die unmittelbar gestartet werden können.
• Large Language Models (LLMs): In technischer Hinsicht arbeiten LLMs während der Inferenz zustandslos. Die Modellgewichte sind festgelegt und ändern sich nicht zwischen den einzelnen Anfragen. 

Mehr dazu erfahren, wie APIs den Einsatz von Apps erleichtern

Der Hauptunterschied zwischen zustandsbehaftet und zustandslos besteht darin, ob eine Anwendung Informationen über den aktuellen Interaktionszustand einer Nutzerin oder eines Nutzers speichert oder ob sie die einzelnen Anfragen als unabhängige, isolierte Transaktionen behandelt. Es gibt jedoch auch spezifische Unterschiede, darunter:

Zustandserhaltung

Zustandsbehaftete Anwendungen speichern Informationen über die Interaktion, meist in einer Datenbank oder einem verteilten Speicher. Zustandslose Anwendungen speichern keine Informationen über eine Interaktion, weshalb eine Transaktion neu begonnen werden muss.

Session-Abhängigkeit

Bei zustandsbehafteten Anwendungen basieren die einzelnen Anfragen auf Daten oder Kontext vorheriger Interaktionen und Transaktionen. Die Sessions zustandsloser Anwendungen sind unabhängiger, da die einzelnen Anfragen als neu behandelt werden. Dies bedeutet aber auch, dass die Anwendung die benötigten Informationen haben muss, um die Anfragen zu verarbeiten.

Storage-Abhängigkeit

Zustandsbehaftete Anwendungen erfordern persistenten Storage (wie beispielsweise Datenbanken und verteilte Dateisysteme). Zustandsbehaftete Apps benötigen eine zugrundeliegende Storage-Lösung sowie ein Schema für das Synchronisieren von Daten zwischen einzelnen Instanzen.

Ressourcennutzung

Zustandslose Anwendungen haben oft eine geringere Ressourcennutzung, da keine Session-Daten gespeichert und verwaltet werden müssen. Da zustandsbehaftete Anwendungen mehr auf Storage angewiesen sind, benötigen sie möglicherweise mehr Speicher und Rechenleistung, um Session-Informationen zu verarbeiten und zu verwalten.

Skalierbarkeit

Zustandslose Anwendungen sind im Allgemeinen besser skalierbar, da die einzelnen Anfragen unabhängig voneinander sind und mithilfe von Load Balancing von beliebigen verfügbaren Servern verarbeitet werden können. Die Instanzen von zustandsbehafteten Anwendungen sind eng miteinander verbunden, was eine Skalierung erschwert. Sie benötigen möglicherweise spezifischere Instanzen oder Pods in Kubernetes, um Load Balancing durchzuführen und Zustand sowie Sessions zu verwalten.

Fehlertoleranz

Zustandslose Anwendungen können fehlertoleranter sein, da der Ausfall eines Servers keine Auswirkungen auf die Sessions von Nutzenden hat. Bei zustandsbehafteten Anwendungen kann der Ausfall eines Servers zum Verlust von Session-Daten führen, sofern keine zusätzlichen Maßnahmen wie Session-Replikation oder Clustering ergriffen werden.

Komplexität bei der Entwicklung

Zustandslose Anwendungen lassen sich unter Umständen einfacher entwickeln und warten, da der Zustand nicht über mehrere Anfragen hinweg verwaltet werden muss. Zustandsbehaftete Anwendungen erfordern dagegen einen sorgfältigen Umgang mit Session-Daten und Zustandsverwaltung.

Während die meisten KI-Systeme zustandslos sind, sind viele KI-Anwendungen so konzipiert, dass sie zustandsbehaftetes Verhalten nachahmen. Sehen wir uns das etwas genauer an.

Während der Trainingsphase ist ein KI-Modell zustandsbehaftet – das Modell verändert sich ständig und „lernt“ dazu, wenn Parameter (oder Gewichte) angepasst werden. 

Sobald das Training abgeschlossen ist, wird der Zustand des Modells „eingefroren“ – es wird zustandslos. Die Parameter des Modells sind festgelegt und der Lernprozess wird beendet. In diesem Modell finden nun keine internen Änderungen mehr statt. Auch während der Inferenz bleibt das Modell zustandslos. 

Wenn das Modell also zustandslos ist, wie lässt sich dann eine kontinuierliche Konversation mit einem LLM führen? Hier findet die Emulation von zustandsbehaftetem Verhalten statt, das auch als Kontextfenster bezeichnet wird. Ein Kontextfenster fungiert als „Arbeitsspeicher“ eines Modells. Dadurch kann das Modell Prompts verstehen und auf diese reagieren, ohne den Überblick über die vorherigen Teile des Gesprächs zu verlieren.    

Container handhaben den Anwendungszustand, indem sie den Anwendungscode von seinen Daten entkoppeln und persistente Storage-Lösungen und Orchestrierungen verwenden, um zustandsbehaftete Workloads zu managen. Die meisten unserer täglich verwendeten Anwendungen sind zustandsbehaftet. Mit dem technologischen Fortschritt wird es jedoch durch Microservices und Container einfacher, Anwendungen in der Cloud zu entwickeln und bereitzustellen.

Mit der zunehmenden Nutzung von Cloud Computing und Microservices steigt auch die Containerisierung von Anwendungen, sowohl von zustandsbehafteten als auch von zustandslosen. Container sind Code-Einheiten für eine Anwendung, die zusammen mit ihren Libraries und Abhängigkeiten paketiert werden. Dadurch können containerisierte Anwendungen leicht verschoben und in verschiedenen Umgebungen ausgeführt werden, sei es auf einem Desktop, einer traditionellen IT-Infrastruktur oder in einer Cloud.

Ursprünglich waren Container zustandslos konzipiert, da dies ihrer portierbaren, flexiblen Natur entsprach. Mit der zunehmenden Verbreitung von Containern wurden jedoch bestehende zustandsbehaftete Apps containerisiert (d. h. neu gestaltet und neu paketiert, um sie in Containern ausführen zu können). Das gab ihnen die Flexibilität und Schnelligkeit, Container zu verwenden, aber mit dem Storage und dem Kontext der Zustandsbehaftung.

Aus diesem Grund können zustandsbehaftete Anwendungen zustandslosen sehr ähnlich sehen und umgekehrt. Beispielsweise könnten Sie eine App verwenden, die zustandslos ist und keinen langfristigen Storage erfordert, die es dem Server jedoch ermöglicht, Anfragen, die von demselben Client stammen, mithilfe von Cookies nachzuverfolgen.

Mit der zunehmenden Bedeutung von Containern begannen Unternehmen, Möglichkeiten zur Verwaltung sowohl zustandsloser als auch zustandsbehafteter Container mithilfe von Data Storage, Kubernetes und StatefulSets anzubieten. Zustandsbehaftung ist heute ein wichtiger Bestandteil von Container Storage, und die Frage ist nicht mehr, ob zustandsbehaftete Container verwendet werden sollen, sondern wann.

Wenn es um zustandsbehaftete oder zustandslose Anwendungen geht, sind Sie bei Red Hat an der richtigen Adresse. Unabhängig davon, ob Sie zustandsbehaftete Container auf unserer Hybrid Cloud-Anwendungsplattform Red Hat® OpenShift® orchestrieren oder mit Red Hat Application Foundations eine einheitliche Umgebung für die App-Entwicklung bereitstellen möchten – Sie können sich auf unseren vielfach ausgezeichneten Support und unser Partnernetzwerk verlassen.

Red Hat OpenShift bietet eine einheitliche, sicherheitsorientierte Hybrid Cloud-Anwendungsplattform, mit der Unternehmen durch die Modernisierung von Anwendungsentwicklung, -bereitstellung und Betriebsabläufen Innovationen beschleunigen können. Red Hat OpenShift bietet Funktionen für die Unterstützung zustandsbehafteter Anwendungen, darunter Kubernetes StatefulSets. Mit Red Hat OpenShift Data Foundation können Sie zustandsbehaftete Daten mit einer Storage-Lösung verwalten, die Software-Defined Storage bietet und die Provisionierung persistenter Volumes ermöglicht. Red Hat OpenShift integriert zusätzlich zustandsbehaftete Anwendungen in DevOps-Workflows.  Red Hat OpenShift Pipelines wurde dazu entwickelt, die einzelnen Schritte der CI/CD-Pipeline auszuführen und unterstützt das gemeinsame Testen und Bereitstellen zustandsbehafteter und zustandsloser Workloads.

Red Hat Application Foundations enthält folgende Funktionen: Service-Komposition und -Orchestrierung, Anwendungskonnektivität und Datentransformation, Echtzeit-Messaging und -Streaming, Erfassung von Änderungsdaten sowie API-Management – und das kombiniert mit einer cloudnativen Plattform und Toolchain, die das gesamte Spektrum der modernen Anwendungsentwicklung unterstützt.

Bei gemeinsamer Verwendung bieten Red Hat OpenShift und Red Hat Application Foundations eine ideale Plattform für das Entwickeln und Bereitstellen cloudnativer Anwendungen. Mit unseren Produkten entwickeln Sie auf Ihre Anforderungen angepasste Lösungen, welche die Entwicklungsproduktivität steigern und Innovationen fördern – ganz im Sinne von Open Source.

Mehr dazu erfahren, wie Red Hat OpenShift Anwendungen unterstützen kann