Uwe Friedrichsen codecentric AG

Man sieht zwar viele Unternehmen, die DevOps machen wollen, aber häufig endet das schnell in Karikaturen der eigentlichen DevOps-Ideen.

Vor gut einem Jahr gab es einen Schwerpunkt Resilience im Java Magazin. Dazu gehörte unter anderem ein Artikel von mir, der in das Themengebiet eingeführt hat. Ein gutes Jahr später stellt sich die Frage, was sich seitdem getan hat. Wie hat sich das Thema im Markt entwickelt? Gibt es neue Erkenntnisse? Was fehlt immer noch? Zeit für eine kleine Bestandsaufnahme und ein paar Ergänzungen.

Für alle, die meine Einführung in Ausgabe 5.2015 nicht gelesen haben, zum Einstieg eine ganz kurze Erläuterung, worum es bei Resilient Software Design überhaupt geht: Resilient Software Design lässt sich semi-formal als die Gestaltung und Umsetzung einer softwarebasierten Lösung definieren auf eine Weise, dass der Nutzer bei einer unerwarteten Fehlersituation davon im besten Fall überhaupt nichts bemerkt, und anderenfalls die Lösung in einem definierten, reduzierten Servicelevel weiterarbeitet.

Wichtig ist bei dieser Definition, dass die Lösung mit unerwarteten Fehlersituationen umgehen können muss. In den heutigen verteilten, hochgradig vernetzten Softwarelandschaften ist es nicht mehr möglich, a priori alle möglichen Fehlersituationen vorherzusehen und durch entsprechende Maßnahmen zu vermeiden. Insbesondere kann man sich nicht auf das korrekte Funktionieren von Bausteinen außerhalb des eigenen Prozesskontexts verlassen, sondern muss zu jeder Zeit davon ausgehen, dass sie nicht, nur sporadisch, zu langsam oder falsch reagieren. Tatsächlich kann man sich auch nicht auf das ordnungsgemäße Funktionieren des eigenen Prozesskontexts verlassen. Denn innerhalb eines Prozesses hängt man in der Regel an dem gleichen Lebensfaden wie der aufgerufene Baustein. Stirbt der aufgerufene Baustein oder wird langsamer, geht es einem als Aufrufer genauso. Aufgrund dieser Sondersituation kann man sich im Code deshalb entsprechende Fehlerbehandlungen sparen. Arbeitet man innerhalb eines Prozesses allerdings mit mehreren Threads – was heutzutage häufig der Fall ist –, hat man mit gewissen Einschränkungen die gleichen Probleme wie bei der Nutzung von Bausteinen über Prozessgrenzen hinweg.

Der zweite wichtige Punkt bei dieser Definition ist das Zurückfallen auf einen definierten Servicelevel, falls man nicht in der Lage ist, einen Fehler so zu kompensieren, dass der Nutzer gar nichts davon merkt. Das Schlüsselwort ist „definiert“. Häufig erlebt man Anwendungen, bei denen im Fehlerfall ein eher zufälliges Verhalten zu beobachten ist, das auf Systemdefaults gepaart mit der vom Entwickler für die Fehlerbehandlung eher zufällig gewählten Implementierung basiert. Ein solches Verhalten ist nicht zulässig. Der Nutzer muss stets ein klar definiertes, a priori festgelegtes Verhalten gezeigt bekommen.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 12.16 - "Serverless: Der Code im Nichts?"

Alle Infos zum Heft
298931Resilient Software Design – ein Jahr danach
X
- Gib Deinen Standort ein -
- or -