Überblick
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.
Was sind zustandsbehaftete Anwendungen?
Zustandsbehaftete Anwendungen und Prozesse behalten ihren Zustand bei, indem sie bereits vorhandene Informationen und Prozesse über das Internet speichern, erfassen und darauf zurückgreifen. In zustandsbehafteten Anwendungen verfolgt der Server den Zustand der einzelnen Session oder Interaktion und speichert diese Informationen basierend auf früheren Anfragen der einzelnen 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 als eine fortlaufende, regelmäßige Konversation mit derselben Person vorstellen.
Use Cases für zustandsbehaftete Anwendungen
- Nutzerzentrierte Anwendungen: Nutzerzentrierte Anwendungen wie beispielsweise Social Media Apps und E-Commerce-Sites speichern die Session ihrer eingeloggten Nutzenden, inklusive Präferenzen und Artikel im Warenkorb.
- IoT-Systeme: Ein Internet of Things (IoT)-System sendet, empfängt und analysiert Daten in einer kontinuierlichen Feedback-Schleife. Ein Gerät reagiert so auf Basis historischer oder Echtzeit-Daten im Laufe der Zeit auf einen veränderten Zustand, ähnlich wie ein Thermostat in unserem Zuhause funktioniert.
- KI/ML-Modelltraining: Trainingsmodelle mit Künstlicher Intelligenz (KI) and Machine Learning (KI/ML) 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.
Red Hat Ressourcen
Was sind zustandslose Anwendungen?
Zustandslose Anwendungen oder Prozesse speichern keine Informationen über die vorherigen Interaktionen der einzelnen Nutzenden. Das bedeutet also, dass es kein gespeichertes Wissen über oder Verweise auf frühere Transaktionen gibt. Es werden daher 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.
Use Cases für zustandslose Anwendungen
- REST APIs: REST APIs (Application Programming Interfaces) übertragen eine Darstellung des Ressourcenzustands an eine anfragende Person oder einen Endpunkt. 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, unabhängig innerhalb einer Anwendung zu existieren. Deshalb eignen sich Microservices gut sowohl für zustandslose als auch 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.
Zustandsbehaftet oder zustandslos: ein Vergleich
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:
Zustandsspeicherung
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.
Container und Zustand
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.
Warum Red Hat?
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.
Der offizielle Red Hat Blog
Lernen Sie mehr über unser Ökosystem von Kunden, Partnern und Communities und erfahren Sie das Neueste zu Themen wie Automatisierung, Hybrid Cloud, KI und mehr.