Java Magazin 3.19

Umfang: 100 Seiten

Erhältlich ab: 06.02.2019

Autoren: Sebastian Daschner, Konstantin Diener, Lars Gohr, Pierre Gronau, Steffen Grunwald, Markus Günther, Tam Hanna, Gerd Herbertz, Dr. Peter Hruschka, Sascha Möllering, Marc Philipp, Frank Roth, Lars Röwekamp, Dr. Gernot Starke, Manfred Steyer, Benjamin Wilms

Sie werden zu unserer Partnerseite kiosk.entwickler.de weitergeleitet

Magazin

Bücher: Eclipse: Kennenlernen. Verstehen. Effizient nutzen.

Java Core

Möglichkeiten des JPMS
Der Weg zu einer modularisierten Java-Anwendung
Markus Günther

Ein OpenJDK von Amazon
Unter der Haube von Amazon Corretto
Steffen Grunwald und Sascha Möllering

Enterprise

Alle drei zusammen?
Java EE, Jakarta EE und MicroProfile – welche Kombination ist für Unternehmen geeignet?
Sebastian Daschner

Kolumne: EnterpriseTales
Lost in Transaction: Businesstransaktionen mit Microservices umsetzen
Lars Röwekamp

DevOps

DevOps@Work
Vorgehensmodell und Projektszenarien zur Einführung eines DevOps-Technologiestacks
Gerd Herbertz und Frank Roth

Kolumne: DevOps Stories
Bist du sicher? Security als First Class Citizen in DevOps-Teams
Konstantin Diener

Mit Klartext zu effizienteren Tests
Wie Behavior-driven Development Product Owner glücklich macht
Lars Gohr

Titelthema

Auf der Reise zu unverwüstlicher Software
Chaos Engineering Teil I
Benjamin Wilms

Willkommen in der Welt der Chaos Tools
Chaos Engineering Teil II
Benjamin Wilms

Security

Klares Jein, aber bitte mit Datenschutz
Teil 3: Die DSGVO und die Blockchain – ein leichtes Unterfangen?
Pierre Gronau

Web

Kolumne: Die Angular-Abenteuer
Querschnittsfunktionen mit Angular implementieren
Manfred Steyer

Architektur

Kolumne: Req4Arcs
Clean Start
Dr. Peter Hruschka und Dr. Gernot Starke

Tools

Neues von JUnit
Drei neue Featurereleases
Marc Philipp

Wer will schon Chaos?

„Chaos“ klingt ja nach etwas, das wirklich keiner will oder brauchen kann. Und da kommen schon die Software-Hipster und predigen das neue „Chaos Engineering“ …

Chaos zu stiften ist jedoch weder Zweck noch Ziel, sondern ein Mittel, komplexe Systeme in kontrollierter Art und Weise auf Herz und Nieren zu testen. Einen solchen Ansatz benötigen wir noch nicht unbedingt, wenn wir es mit Systemen zu tun haben, die im klassischen Sinn „kompliziert“ sind. Solche Systeme zeichnen sich dadurch aus, dass es bei Ereignissen klare Ursache-Wirkung-Relationen zu erkennen gibt, die man analysieren, dokumentieren und vorhersagen kann. Bei „komplexer“ Software ist davon auszugehen, dass Fachleute deren innere Mechanismen hinreichend kennen und im Idealfall Fehler komplett vermeiden.

Geht in einem solchen Umfeld doch mal etwas schief, ist dies auf menschliche Fehler, mangelhafte Dokumentation oder etwa die Unübersichtlichkeit des Systems zurückzuführen. Die klassische Optimierungsstrategie lautet meistens: Kontrolle erhöhen, damit bekommt man schon alles in den Griff.

Komplexe Systeme hingegen sind solche, bei denen die Beziehung zwischen Ursache und Wirkung von Ereignissen nur im Nachhinein und auch nicht mit absoluter Sicherheit wahrgenommen werden kann.

In solchen Umgebungen ist nicht Fehlerfreiheit die Königstugend der Softwareentwickler, sondern die sog. Mean Time to Recover (MTTR). In anderen Worten: Das Auftreten eines Fehlers bedeutet keinen Skandal, den es zu vermeiden gilt; Fehler gehören vielmehr zum normalen Gang der Dinge, und es kommt darauf an, ob wir in der Lage sind, schnell zu analysieren und ebenso schnell pragmatische Lösungen für deren Behebung umzusetzen.

Warum man also an komplexe Systeme herangehen und mit einer klaren Hypothese ausgestattet Durcheinander stiften sollte, erfahren Sie im ersten Teil des von Sebastian Wilms verfassten Titelthemas dieser Ausgabe (Seite 58). Im zweiten Teil geht der Autor dann auf konkrete Werkzeuge und Vorgehensweisen für erste konstruktive Chaos-Experimente ein (Seite 66).

Bemerkenswert an dem Thema ist, dass es nicht nur darum geht, komplexe technische Abhängigkeitsstrukturen ausfindig zu machen und für den Fehlerfall frühzeitig Reparaturstrategien zu entwickeln, sondern auch um den menschlichen Faktor.

In diesem Sinne ließe sich Chaos Engineering mit einer Feuerwehrübung oder anderen Notfallszenarien in der analogen Welt vergleichen: Selbst wenn alle Prozesse bis ins Kleinste definiert, selbst wenn alle Rollen umfassend erprobt und klar zugewiesen sind – erst im Zusammenspiel aller Faktoren und unter simulierten Realbedingungen beginnt man zu verstehen, was sich wirklich in einem komplexen System ereignet.

Sebastian Meyen, Chefredaktur