Der lange und steinige Weg zur Resilienz – Teil 3

Im vorigen Beitrag haben wir das Tal der Feature-Vollständigkeit besprochen, den Ausgangspunkt unserer prototypischen Reise in Richtung Resilienz, und wir haben festgestellt, dass ein solches Setup in der Regel nicht mehr ratsam ist.

In diesem Beitrag werden wir erörtern, warum wir ein solches Setup immer noch häufig in Unternehmen sehen, auch wenn es im Hinblick auf die Anforderungen der heutigen IT-Systemlandschaften nicht mehr geeignet ist. Danach werden wir diskutieren, welche Erkenntnis notwendig ist, um mit der Reise zu beginnen und was wir auf dem ersten Plateau vorfinden werden.

Auf geht's!

Eine Begegnung mit der Vergangenheit

Warum sehen wir in Unternehmen immer noch so oft die Einstellung „Ops ist für Verfügbarkeit zuständig, während sich der Rest der Organisation nur um Geschäftsfunktionen kümmert“? Wenn man sich die zugrundeliegenden IT-Systemlandschaften anschaut, sollte es offensichtlich sein, dass dies nicht mehr angemessen ist.

Um dieses Phänomen zu verstehen, müssen wir zurück in die Vergangenheit reisen. Bis Anfang der 2000er Jahre bestanden die meisten IT-Systemlandschaften hauptsächlich aus monolithischen Anwendungen, die weitgehend isoliert arbeiteten. Wenn diese Anwendungen Informationen mit einer anderen Anwendung austauschen oder eine Aktivität in einer anderen Anwendung auslösen mussten, verwendeten sie Offline-Batch-Updates. So erstellte beispielsweise Anwendung A in regelmäßigen Abständen eine Übertragungsdatei, die dann von Anwendung B abgeholt und verarbeitet wurde.

Lange Zeit liefen diese Batch-Updates nachts, täglich oder seltener. Später, als der Druck stieg, Informationen häufiger als einmal pro Tag auszutauschen, wurden die Batch-Updates häufiger, z.B. stündlich durchgeführt.

Eine der schönen Eigenschaften von Batch-Updates ist, dass sie sehr robust sind. Für das sendende System ist es unerheblich, ob das empfangende System läuft und umgekehrt. Alles ist sehr gut gegen Ausfälle in anderen Systemen isoliert. Der Ausfall eines umgebenden Systems hat keine Auswirkungen auf die Verfügbarkeit deines eigenen Systems. Das Einzige, worauf du achten musst, ist, dass dein System spezifikationskonform funktioniert. Dafür ist es unerheblich, wie sich die umgebenden Systeme verhalten.

Damit verbleiben zwei Hauptfehlerquellen:

• Etwas, auf dem deine Anwendung läuft, fällt aus.
• Die Anwendung selbst fällt aus.

Die erste Fehlerquelle sind Hardware-, Infrastruktur- oder Middleware-Komponenten, die ausfallen. Diese Teile der IT-Systemlandschaft fallen in den Zuständigkeitsbereich von Ops. Daher rührt die Einstellung „Ops ist für die Verfügbarkeit verantwortlich“. Ops ist dafür verantwortlich, dass die zugrunde liegende Betriebsplattform funktioniert.

Was ist mit der zweiten Fehlerquelle? Nun, das sind die so genannten "Bugs", die Softwarefehler. Es liegt in der Verantwortung der Entwicklungsabteilung (oder früher – und manchmal immer noch – der Qualitätssicherung), sicherzustellen, dass die Anwendung keine kritischen Fehler enthält, die sich zur Laufzeit als Ausfall manifestieren. [1]

Wenn deine IT-Systemlandschaft also hauptsächlich aus monolithischen Anwendungen besteht, die isoliert arbeiten und nur über Batch-Updates mit anderen Anwendungen kommunizieren, ist das Tal der Feature-Vollständigkeit ein angemessener Ort.

Andere Zeiten, andere Sitten

Doch inzwischen schreiben wir das Jahr 2025 und die Realität der IT-Systemlandschaften hat sich grundlegend verändert. Die Erwartungen an die Aktualität von Daten und Informationen sind gestiegen. Es reicht nicht mehr aus, Updates zwischen Systemen einmal pro Tag oder sogar einmal pro Stunde zu verbreiten. Mit den immer besser werdenden Möglichkeiten der Netzwerkkommunikation wandelte sich die Erwartungshaltung im Grunde zu: „Alles. Überall. Sofort.“.

Die Fortschritte in der Kommunikationstechnologie in Verbindung mit den steigenden Erwartungen führten zu einem Wandel der Kommunikation zwischen den Systemen von Offline-Batch-Schnittstellen zur Online-Kommunikation. Ein System, das über neue Informationen verfügt (auch „Produzent“ genannt), sendet nicht mehr periodisch alle angefallenen Aktualisierungen auf einmal an ein System, das an diesen Informationen interessiert ist (auch „Konsument“ genannt). Stattdessen fordert der Konsument die Informationen in der Regel online, d. h. über einen Remote-Aufruf, vom Produzenten an, wenn er sie benötigt.

Der Verbraucher fordert auch nicht alle Aktualisierungen an. Stattdessen fordert er nur genau die Informationen an, die er zu einem bestimmten Zeitpunkt benötigt, um seine jeweilige Aufgabe zu erfüllen (in der Regel eine Anfrage von einem Benutzer oder einem anderen System zu bearbeiten). Da der Konsument in der Lage ist, die benötigten Informationen zu jedem beliebigen Zeitpunkt anzufordern, speichert er auch nicht die gesamten (Batch-)Aktualisierungsinformationen des Produzenten in seiner eigenen Datenbank. Stattdessen fordert der Konsument nur die benötigten Informationen in dem Moment beim Produzenten an, in dem er sie benötigt.

Oft speichert der Konsument nicht einmal die angeforderten Informationen in seiner eigenen Datenbank, sondern verwendet sie lediglich, um die laufende Verarbeitung abzuschließen, und „vergisst“ die Informationen dann. Sollte der Konsument dieselben Informationen erneut benötigen, fordert er sie erneut beim Produzenten an. Dies ist oft absichtlich so implementiert, da sich die Informationen auf der Produzentenseite zwischen den beiden Anfragen geändert haben könnten. [2]

Alternativ zu diesem Pull-basierten Online-Anforderungsmechanismus hat sich auch ein Push-basierter Online-Datentransfer, z. B. über eine ereignisbasierte Kommunikation, entwickelt. In diesem Fall senden die Produzenten alle Aktualisierungen sofort an die interessierten Parteien (z. B. über Publish-Subscribe), und es obliegt den Konsumenten, diese Informationen zu speichern, um sie bei Bedarf zur Verfügung zu haben.

Diese beiden Varianten sind die am weitesten verbreiteten Wege, um Informationen online zu teilen. Natürlich gibt es noch viele weitere Varianten und Nuancen der Online-Kommunikation. Insgesamt können wir jedoch das folgende allgemeine Entwicklungsmuster beobachten:

• Die Informationsübertragung veränderte sich von Offline-Batch- zu Online-On-Demand-Kommunikation.
• Die Informationsübertragung veränderte sich von Multi-Record- zur Single-Record-Kommunikation.

Die zweite Entwicklung bedeutet, dass in der Regel nicht ein ganzer Batch, d.h. eine Menge an Informationen vom Produzenten zum Konsumenten gesendet wird (der in der Regel alle Aktualisierungen seit dem Versenden des vorherigen Batches enthält), sondern nur ein einziger Datensatz.

Diese Entwicklung hin zu einer On-Demand-, Online- und typischerweise auf einem einzelnen Datensatz basierenden Kommunikation zwischen IT-Systemen hat zur Folge, dass sich die IT-Systemlandschaft allmählich von meist isolierten Systemen zu einer stark vernetzten IT-Systemlandschaft wandelt, die kontinuierlich via komplexer Interaktionsmuster kommuniziert. Kurz gesagt:

Die heutigen Systemlandschaften bilden ein riesiges, komplexes, stark vernetztes, verteiltes System.

Jüngste Entwicklungen wie servicebasierte Architekturen oder echtzeitnahe (near-realtime) Analysen verstärken die Auswirkungen der Verteilung noch weiter.

In einer Blogserie über robustes Softwaredesign habe ich (auf Englisch) die Effekte verteilter Systeme erörtert und dargelegt, dass sie nicht von Ops alleine abgehandelt werden können, sondern auch die Entwicklungs- und sogar die Geschäftsabteilungen betreffen. Da ich die Argumentation in diesen Blogbeiträgen dargelegt habe, werde ich sie hier nicht wiederholen. Wenn dir nicht klar ist, warum Ops allein die Verfügbarkeit einer verteilten Systemlandschaft nicht sicherstellen kann, kannst du das in der referenzierten Blogserie nachlesen.

Die erste Erkenntnis

Viele Unternehmen haben sich jedoch noch nicht auf die veränderte Realität der IT-Systemlandschaften eingestellt. Wir sehen immer wieder, dass soziale Systeme dem technologischen Fortschritt hinterherhinken. Wir sehen es im großen Maßstab, z. B. dass sich zumindest die westlichen Gesellschaften noch nicht an die Auswirkungen sozialer Netzwerke angepasst haben, insbesondere an die Auswirkungen der extremen Echokammerbildung. Wir sehen es aber auch im kleineren Maßstab, in unserem Kontext die mangelnde Anpassung von Unternehmen an die veränderte Realität ihrer IT-Systemlandschaften: Große verteilte Systemlandschaften werden immer noch wie einen Haufen isolierter Systeme behandelt, die nur über Offline-Batch-Updates kommunizieren.

Wenn wir uns bewusst machen, dass unsere IT-Systemlandschaften ein komplexes, hochgradig verteiltes System bilden, und auch berücksichtigen, dass die Auswirkungen verteilter Systeme nicht allein von Ops eingedämmt werden können, führt dies unmittelbar zu der ersten Einsicht, die erforderlich ist, um die Reise in Richtung Resilienz zu beginnen:

Ops alleine kann Verfügbarkeit nicht sicherstellen.

Wie ich in der zuvor erwähnten Blog-Serie geschrieben habe, wirken sich die Effekte verteilter Systeme bis auf die Anwendungsebene aus, was wiederum bedeutet, dass Ops allein die Verfügbarkeit nicht mehr sicherstellen kann. Es gibt neue, zusätzliche Fehlerarten, die es in einer Welt aus isolierten, monolithischen Systemen, die über Offline-Batch-Updates kommunizieren, nicht gab und die nur auf Anwendungsebene behandelt werden können. [3]

Dies führt uns zu unserer ersten Zwischenstation, dem Plateau der Stabilität.

Das Plateau der Stabilität

Das Plateau der Stabilität [4] ist die erste Zwischenstation, die Unternehmen auf ihrem Weg zur Resilienz erreichen.

Viele Unternehmen, die ich gesehen habe, haben ihre Reise auf diesem Plateau beendet. Der Kerngedanke dieses Plateaus ist, Misserfolge mit allen Mitteln zu vermeiden. Die Grundeinstellung ist:

Wenn man sich auf technischer Ebene nur genug anstrengt, kann man Ausfälle vollständig vermeiden und so eine perfekte Verfügbarkeit erreichen.

Interessanterweise konzentrieren sich die meisten Leute, die ich beobachtet habe, ausschließlich auf Crash-Fehler und Überlastsituationen, während sie darüber nachdenken, wie man Fehler vermeiden kann. Andere mögliche Fehlerarten werden häufig ignoriert (wir werden auf die anderen Fehlerarten zurückkommen, wenn wir beim nächsten Plateau ankommen).

Dennoch: Die gesamte IT-Organisation kümmert sich um die Sicherstellung der Verfügbarkeit, selbst wenn sie ausschließlich über Fehlervermeidung nachdenkt. Das Thema wird nicht mehr allein Ops überlassen. Auch die Entwicklungsabteilung trägt ihren Teil zur Vermeidung von Ausfällen bei. Wenn man etwas genauer hinsieht, kann man zwei verschiedene Arten der Zusammenarbeit beobachten:

• Die erste Evolutionsstufe des Stabilitätsplateaus ist in der Regel durch eine sehr geringe Zusammenarbeit zwischen Entwicklung und Betrieb gekennzeichnet. Der Betrieb erledigt seine Arbeit und stellt in dem Rahmen Infrastruktur- und Middleware-Tooling bereit. Die Entwicklung verwendet die bereitgestellten Tools, um ihren Teil der Arbeit zu erledigen, aber im Prinzip ohne Interaktion mit dem Betrieb. Die Prozesse und die Art der Zusammenarbeit sind größtenteils so, wie sie im Tal der Feature-Vollständigkeit waren.
• Die zweite Evolutionsstufe ist durch eine engere Zusammenarbeit zwischen Entwicklung und Betrieb gekennzeichnet. Ohne jegliches Feedback aus der Produktion, d. h. vom Betrieb, wie gut ihre Stabilitätsmaßnahmen funktioniert haben, tappt die Entwicklung meist im Dunkeln. Das ist tendenziell ineffektiv. Mit der Zeit frustriert es außerdem die Software-Ingenieure in der Entwicklungsabteilung, weil sie nie eine Rückmeldung darüber erhalten, ob ihre Arbeit etwas gebracht hat oder nicht. Deshalb wird eine engere Feedbackschleife zwischen Betrieb und Entwicklung etabliert: Die Entwicklung setzt Stabilitätsmaßnahmen um und gibt sie für die Produktion frei. Der Betrieb gibt Feedback, wie gut die Maßnahmen funktioniert haben. Die Entwicklung nutzt das Feedback dann wieder, um die Maßnahmen zu verfeinern.
• Der Vollständigkeit halber: Im Tal der Feature-Vollständigkeit war Ops allein, wenn es um die Verfügbarkeit ging.

Das Plateau der Stabilität besteht also eigentlich aus zwei Teilplateaus. Allerdings brauchen die Unternehmen in der Regel eine Weile, um zu erkennen, dass das untere Teilplateau nur begrenzt wirksam ist. Da es jedoch weniger Veränderungen in Bezug auf die Art der Zusammenarbeit erfordert, neigen die Unternehmen dazu, eine ganze Weile auf diesem Plateau zu verweilen, bevor sie auf das höhere Plateau wechseln.

Evaluierung des Plateaus der Stabilität

Nach diesen Vorbemerkungen wollen wir das Plateau der Stabilität genauer erkunden, indem wir dasselbe Evaluationsschema verwenden, das wir für das Tal der Feature-Vollständigkeit benutzt haben.

Haupttreiber

Der Haupttreiber ist die Vermeidung von Ausfällen.

Der Kerngedanke ist: Indem wir Fehler mit allen Mitteln vermeiden, erreichen wir perfekte Verfügbarkeit.

Leitfragen

Typische Leitfragen sind:

• Wie kann ich den Ausfall meiner Anwendung/meines Services vermeiden?
• Wie kann ich einen Ausfall erkennen und automatisch auf eine replizierte Instanz umschalten?
• Wie kann ich eine Überlastsituation vermeiden?
• Wie kann ich eine Überlastsituation erkennen und sie durch automatische Skalierung der Ressourcen oder Drosselung der Anzahl der Anfragen beheben?

Es dreht sich alles um das Verhindern von Ausfällen durch Abstürze oder Überlastsituationen.

Typische Maßnahmen

Die typischen Maßnahmen in Bezug auf Resilienz - oder (noch einmal) genauer: die Maximierung der Verfügbarkeit - sind jetzt zwischen Ops und Dev aufgeteilt: Ops stellt üblicherweise die Mittel bereit, die Dev nutzt, um die Ausfallwahrscheinlichkeit zu minimieren. Typische Maßnahmen sind:

• Ein redundantes Service-Deployment, aber diesmal von Dev und nicht von Ops konfiguriert, um sicherzustellen, dass die eigene Anwendung weiterhin verfügbar ist, wenn eine Instanz ausfallen sollte.
• Anwendung von Fehlertoleranzmustern wie Timeout-Erkennung, Fehlerüberprüfung, Retry, Circuit Breaker und Failover zur Erkennung und Behandlung von Abstürzen aufgerufener Anwendungen.
• Anwendung von Fehlertoleranzmustern wie Rate Limiting oder Back Pressure zur Vermeidung von Überlastsituationen oder alternativ die Verwendung von Autoscaling in einer (Public) Cloud-Umgebung.
• …

All diese Maßnahmen sind häufig statisch vorkonfiguriert, wobei nach Möglichkeit die bereitgestellte Middleware verwendet wird. So wird z. B. Redundanz mit Hilfe von Kubernetes konfiguriert, die Erkennung und Behandlung von Abstürzen mit Hilfe eines Service Meshes implementiert, das Rate Limiting im API-Gateway konfiguriert und die automatische Skalierung nutzt vorhandene Möglichkeiten der Public Cloud. Das heißt, der Anwendungscode wird in der Regel nicht angefasst, sondern die Middleware und die Infrastruktur, die für die Ausführung der Anwendungen verwendet werden, werden entsprechend konfiguriert, um die erforderlichen Verfügbarkeitsmaßnahmen umzusetzen.

Wichtig ist in dem Kontext, dass der Fokus nur auf technischen Maßnahmen liegt. Auf dem Plateau der Stabilität liegt die Gewährleistung der Verfügbarkeit in der alleinigen Verantwortung der IT-Abteilung. Es findet keine Diskussion mit einem Produkt-Manager oder Ähnlichem statt. Dies wird noch relevant werden, wenn wir das nächste Plateau erreichen werden. Im Augenblick solltest du es einfach im Hinterkopf behalten.

Trade-offs

Der Ansatz „Plateau der Stabilität“ hat mehrere Vor- und Nachteile:

• Aus dem Tal der Feature-Vollständigkeit kommend ist dieses Plateau relativ leicht zu erreichen – insbesondere das untere Teilplateau, das noch keine Rückkopplungsschleifen zwischen Entwicklung und Betrieb beinhaltet.
• Die besten Ergebnisse in Bezug auf Verfügbarkeit werden jedoch auf dem höheren Teilplateau erzielt, d. h. mit einer Rückkopplungsschleife zwischen Betrieb und Entwicklung.
• Für die Entwicklung sind die Maßnahmen relativ einfach zu implementieren, da die Umsetzung oft nur eine wenig Konfiguration der vom Betrieb bereitgestellten Middleware und Infrastruktur erfordert.
• Der Ansatz funktioniert gut in Verbindung mit einem Geschäftsmodell, das auf Skaleneffekte setzt („Economies of Scale“), d. h. in Unternehmen, die sich auf Kosteneffizienz und nicht auf Markt-Feedback-Zykluszeiten konzentrieren (was immer noch das Geschäftsmodell vieler Unternehmen ist), da er ohne allzu großen Aufwand umgesetzt werden kann (gut im Sinne der Kosteneffizienz), aber nicht sonderlich schnell auf externe Kräfte (hier: potenzielle Fehlerquellen) reagiert (passend zum geringen Fokus auf Reaktionszeiten).
• Es ist möglich, eine recht gute Verfügbarkeit zu erreichen. Als Faustregel gilt, dass mit diesem Ansatz eine Verfügbarkeit von bis zu drei Neunen (99,9 %) für eine einzelne Laufzeitkomponente möglich ist.
• Wenn jedoch eine Laufzeitkomponente ausfällt, dauert die Erkennung und Wiederherstellung oft recht lange, weil man davon ausgeht, dass Ausfälle komplett vermieden werden können und die Behandlung von Ausfällen daher nachrangig ist.
• Resilienz ist immer noch kein Thema. Die zugrundeliegende Annahme ist, dass mit genügend Aufwand alles unter Kontrolle, sprich verfügbar gehalten werden kann.

Wann ist es sinnvoll

Ein solches Setup ist in Ordnung, wenn deine Verfügbarkeitsanforderungen nicht allzu hoch sind - als Faustregel gilt eine Verfügbarkeit von weniger als 99,9 % für eine einzelne Laufzeiteinheit [5]. Damit eignet sich der Ansatz für vorwiegend monolithische Anwendungen, die nur wenig Online-Interaktion mit anderen Anwendungen haben und bei denen geplante Ausfallzeiten für Updates und Wartung zulässig sind.

Wann ist es zu vermeiden

Ein solcher Ansatz sollte grundsätzlich vermieden werden, wenn die erforderliche Systemverfügbarkeit in Richtung 99,9 % oder höher geht.

Er sollte auch vermieden werden, wenn das System intern verteilt ist, z. B. durch einen Microservice-Ansatz, oder wenn viele andere Systeme aufgerufen werden müssen, um eine externe Anfrage zu erfüllen. Der Grund dafür ist, dass die Gesamtverfügbarkeit das Produkt der Verfügbarkeiten aller Laufzeitkomponenten ist, die zur Erfüllung der externen Anfrage benötigt werden, was zu einer geringeren Verfügbarkeit des Gesamtsystems führt. [6]

Die einzige Ausnahme bei einem service-basierten Design ist, wenn sich die Services während der Bearbeitung einer externen Anfrage nicht gegenseitig aufrufen (der so genannte Microlith-Ansatz), da die Verfügbarkeiten der Services (Microlithen) in diesem Fall unabhängig voneinander sind, d. h. sich nicht aufmultiplizieren.

Ein solcher Ansatz ist für sicherheitskritische Kontexte (Stichwort: Safety) völlig ungeeignet.

Wirkungskreis

Der Wirkungskreis der resilienzbezogenen (oder besser: verfügbarkeitsbezogenen) Maßnahmen ist auf die IT-Systeme und die IT-Abteilung beschränkt.

Blinder Fleck

Der blinde Fleck dieses Ansatzes hängt mit dem Gedanken zusammen, Ausfälle vollständig vermeiden zu können. Ich bezeichne diesen blinden Fleck als „100 %-ige Verfügbarkeitsfalle“, die ich im nächsten Beitrag in Verbindung mit der Erkenntnis erklären werde, die erforderlich ist, um sich auf die Reise zum nächsthöheren Plateau zu machen.

Zusammenfassung

Das Plateau der Stabilität ist die erste Zwischenstation auf dem Weg zur Resilienz. Es akzeptiert, dass Ops bei den heutigen verteilten Systemlandschaften Verfügbarkeit nicht mehr allein sicherstellen kann. Daher wird die Verantwortung für die Vermeidung von Ausfällen auf die Entwicklungsabteilung erweitert.

Das Plateau ist relativ leicht zu erreichen, was ein Grund dafür ist, dass wir häufig Unternehmen sehen, die auf diesem Plateau verweilen. Es ermöglicht eine relativ gute Verfügbarkeit für einzelne Laufzeitkomponenten. Es ist jedoch nicht für höhere Verfügbarkeitsanforderungen geeignet, insbesondere nicht, wenn das System intern verteilt ist oder viele Systeme online interagieren müssen, um Anfragen zu beantworten. Für sicherheitskritische Systeme ist es überhaupt nicht geeignet.

Im nächsten Beitrag werden wir uns die 100 %-ige Verfügbarkeitsfalle genauer ansehen und uns noch einmal eingehender mit dem Thema Verfügbarkeit befassen. Wir werden auch auf die Erkenntnisse eingehen, die erforderlich sind, um die Reise zum nächsten Plateau fortzusetzen. Bleibt dran ... ;-)

[1] Dazu gehört manchmal eine gewisse Härtung der Offline-Batch-Schnittstellen, damit sie nicht versagen, wenn unerwartete Daten eintreffen, d.h. Daten, die syntaktisch oder semantisch nicht den Erwartungen des empfangenden Systems entsprechen. Allerdings handelt es sich bei Batch-Importaufträgen oft um eigenständige Programme, die unabhängig von der Hauptanwendung laufen. Daher macht es nicht allzu viel aus, wenn diese Programme aufgrund unerwarteter Daten abstürzen. In einem solchen Fall wird der Batch-Input in der Regel manuell überprüft und die fehlerhaften Einträge werden korrigiert oder entfernt. Anschließend wird der Importauftrag neu gestartet. Wenn dies zu oft passiert, werden die Importe in der Regel gestoppt, bis das Team, das das sendende System betreut, das Problem behoben hat. Daher ist die Härtung der Schnittstellen, damit sie nicht abstürzen, wenn unerwartete Daten gesendet werden, bei batchorientierten Schnittstellen kein großes Problem. Ganz anders bei Online-Schnittstellen, wo es für die Robustheit des Systems entscheidend ist, dass die Schnittstellen in der Lage sind, unerwartete Daten zu erkennen und zu verarbeiten, ohne abzustürzen, da die Schnittstellen Teil der Hauptanwendung sind.

[2] Ich habe hier bewusst Optimierungen wie Caching weggelassen, die man häufig einsetzt, um einige der Probleme abzumildern, die das reine, nicht optimierte Konzept mit sich bringt, d. h. wenn man jedes einzelne Mal alle benötigten Informationen von den jeweiligen Anbietern anfordert.

[3] Tatsächlich gibt es auch Fehlerarten, die über die Anwendungsebene hinausgehen, aber dazu kommen wir später in dieser Blogserie.

[4] Ich verwende den Begriff „Stabilität“ in erster Linie, um diesen Ansatz vom Ansatz der Robustheit zu unterscheiden. Je nach Argumentation kannst du beide Begriffe austauschbar verwenden. Allerdings verbinde ich mit „Stabilität“ ein gewisses Maß an Starrheit, während ich „Robustheit“ mit einem gewissen Maß an Flexibilität verbinde. So ist z. B. ein Betonpfeiler in diesem Sinne stabil, während ein Baum robust ist. Der Betonpfeiler hält ein bestimmtes Maß an Belastung aus, ohne sich zu verformen, und bricht dann, während der Baum unter Belastung eher nachgibt und nach Beendigung der Belastung wieder in seine ursprüngliche Form zurückkehrt. Natürlich bricht auch ein Baum irgendwann, wenn die Belastung zu hoch wird, aber er kann Belastungen in der Regel viel besser absorbieren und sich von ihnen erholen als ein Betonpfeiler derselben Größe.

[5] Beachte, dass sich die Verfügbarkeiten vervielfachen, d. h. kleiner werden, wenn mehr als eine Laufzeiteinheit für die Bearbeitung einer externen Anfrage erforderlich ist (siehe auch die nächste Fußnote für eine genauere Erklärung).

[6] Die Verfügbarkeit ist definiert als der Anteil der Gesamtzeit, in der ein System gemäß seiner Spezifikation reagiert. Dies ist eine Zahl zwischen 0 und 1 (beide eingeschlossen) - oder 0 % und 100 %, wenn du diese Schreibweise bevorzugst. Multipliziert man zwei Zahlen, die kleiner als 1 sind, erhält man eine Zahl, die kleiner als beide Zahlen ist. Wenn du mehrere Laufzeitkomponenten, z. B. Services, zur Bearbeitung einer externen Anfrage benötigst, weil der empfangende Service andere Services aufrufen muss, um die Bearbeitung seiner Anfrage abzuschließen, müssen alle Services gemeinsam verfügbar sein, damit die Anfrage erfolgreich abgeschlossen werden kann, sprich die einzelnen Service-Verfügbarkeiten multiplizieren sich auf. Wenn z. B. zehn Services, jeder mit einer Verfügbarkeit von jeweils 99,9 %, erforderlich sind, um eine externe Anfrage zu bearbeiten, beträgt die Gesamtverfügbarkeit 0,999 ^ 10, also ca. 0,99, d. h. 99 %.

Dieser Blogpost ist ursprünglich auf Englisch in Uwe Friedrichsens Blog erschienen.