Liveness beschreibt, ob sich die Anwendung aus Sicht von Prozess und Runtime in einem lauffähigen Zustand befindet. Eine Anwendung wird als "live" (lebendig) angesehen, wenn diese in einem korrekten inneren Zustand ist. Ist eine Anwendung nicht "live", liegt ein irreparabler interner Fehlerzustand, der einen Neustart durch die Infrastruktur erforderlich macht (vgl. Spring Boot LivenessState, Kubernetes Liveness und Readiness Probes). Externe Abhängigkeiten wie Datenbanken, Messaging-Systeme oder entfernte Services beeinflussen die Liveness grundsätzlich nicht, sofern kein irreparabler interner Defekt der Anwendung selbst vorliegt.

Eine Anwendung wird als "ready" (bereit) angesehen, wenn sie live ist und Anfragen korrekt verarbeiten kann, daher also Traffic erhalten darf. Eine Anwendung ist nicht "ready", wenn essenzielle Ressourcen oder essenzielle Nachbarsysteme nicht verfügbar sind oder andere Zustände vorliegen, die keinen Neustart erfordern, aber die Bearbeitung von Anfragen verhindern oder unzulässig machen. Ist eine Anwendung nicht "ready", darf die Infrastruktur keine Anfragen an sie senden (vgl. Spring Boot ReadinessState, Kubernetes Liveness und Readiness Probes).

Ein Service (d.h. eine Bündelung von Instanzen/Anwendungen, die denselben Service anbieten) wird als "ready" angesehen, wenn mindestens eine Instanz "ready" ist. Readiness ist der maßgebliche Zustand für das Herausnehmen einzelner Instanzen aus dem Traffic, ohne das die Prozesslebendigkeit infrage zu stellen ist. Prüfungen der Readiness von Services müssen über die Infrastruktur erfolgen.

Zur Verdeutlichung und Trennung der beiden Begriffe werden diese an dieser Stelle zusammen behandelt. Der Fall, dass eine Anwendung, die nicht "live", aber "ready" ist, ist rein akademisch. In dem Moment, in dem eine Anwendung nicht "live" ist, muss sie durch die Infrastruktur neu gestartet werden, da sie aufgrund des inkorrekten inneren Zustands keine Anfragen korrekt bearbeiten kann. Aus praktischer Sicht wird die Liveness-Abfrage zur Evaluierung, ob eine Anwendung neu zu starten ist, genutzt. Eine Anwendung, die "live", aber nicht "ready" ist, ist in einem korrekten Zustand, hat aber nicht alle notwendigen Abhängigkeiten oder Ressourcen zur Verfügung, um Anfragen anzunehmen. Aus praktischer Sicht ist diese nicht neu zu starten.

Ist für eine Anwendung die Abfrage beider Zustande vorgesehen, ergeben sich folgende Zustände:

Die Nachbarsystemchecks werden über Health- oder Readiness-Checks der Nachbarsysteme durchgeführt.

Schlägt ein Check eines Nachbarsystems fehl, führt dies zu einem Eintrag im technischen Log. Bei einem nicht essenziellen Nachbarsystem wird darauf eine Warnung geloggt. Bei einem essenziellen Nachbarsystem wird ein Fehler geloggt und die health sowie die Readiness des prüfenden Systems muss ebenso einen Fehler aufweisen. Die Zuordnung zu Readiness erfolgt zusätzlich und ohne Umdeutung des bestehenden health Endpunkts. Ein essenzielles Nachbarsystem beeinflusst also die Readiness der Anwendung.

Im Rahmen von Nachbarsystemchecks muss (alternativ zum health-Endpoint) die Readiness überprüft werden. Auch hier muss unterschieden und geloggt werden, ob ein essenzielles Nachbarsystem ausgefallen ist oder ein nicht essenzielles. Ist ein essenzielles Nachbarsystem ausgefallen, dann hat dies Auswirkungen auf die Readiness des Systems jedoch nicht auf die Liveness. Nachbarsystemchecks von essenziellen Systemen sind damit essenziell für die Readiness eines Systems.

Das Loadbalancer-Servlet prüft beim Aufrufen seiner URL, ob eine IsAlive-Datei im Konfigurationsverzeichnis vorhanden ist. Ist eine solche Datei vorhanden, liefert das Servlet den HTTP-Statuscode HTTP OK (200) zurück. Falls keine IsAlive-Datei gefunden wird, liefert das Servlet den Code HTTP FORBIDDEN (403) zurück. Der Loadbalancer prüft in regelmäßigen Abständen die URL des Servlets und nimmt für die Anwendung den entsprechenden Server aus dem Loadbalancing heraus, falls kein HTTP OK gelesen wird. Zu beachten ist, dass auf einem Server prinzipiell mehrere verschiedene Anwendungen laufen können. Der Loadbalancer muss daher so konfiguriert werden, dass auf dem Server nur die betreffende Anwendung deaktiviert wird, zu der das Loadbalancer-Servlet gehört. Alle anderen Anwendungen auf dem entsprechenden Server müssen weiterhin bedient werden.

Sind Liveness und Readiness definiert, soll der Loadbalancer die Readiness eines Knotens prüfen. Ist die Readiness nicht gegeben, ist der Knoten aus dem Loadbalancing heraus zu nehmen. Je nach betrieblichen Bedingungen und den technischen Möglichkeiten des eingesetzten Loadbalancers ist die Abfrage der Readiness über den Readiness Endpoint oder alternativ über eine isAlive-Datei festzustellen. Die betrieblich begründete, temporäre Nichtverfügbarkeit einer Anwendung, kann über die Löschung einer isAlive-Datei gesteuert werden (vgl. Nutzungsvorgaben). Ist das Vorhandensein einer isAlive-Datei aus betrieblichen Anforderungen nicht notwendig ist die direkte Prüfung über den Readiness Endpoint vorzunehmen.