W-Jax 2018 – ein Erfahrungsbericht

Über Konferenzen

Im Allgemeinen fahre ich nicht gerne auf Konferenzen. Einen oder gar mehrere Tage von früh bis spät ohne Rückzugsmöglichkeit von Hunderten Menschen umgeben zu sein verursacht Stress. Nach zehn Stunden auf einer Tagung fühle ich mich kaputter als nach 40 Stunden Debugging. Außerdem habe ich Konferenzen in der Physik als hochgradig ineffiziente Veranstaltungen erlebt; als Zusammenkünfte altersgrauer Herren, die sich bei Krabbenhäppchen und Sekt ihre jeweils aktuellen Modelle und Theorien über den grünen Klee loben. Der zu erwartende und empirisch gemessene Erkenntnisgewinn war meistens ein Rundungsfehler. Doch nach Jahren der Abstinenz packte mich die Neugier und da ich mittlerweile der Physik den Rücken gekehrt und in der IT heimisch geworden bin, sollte es auf die W-Jax gehen.

Über die W-Jax

Die W-Jax bezeichnet sich auf ihrer Webseite als „Die Konferenz für Java,
Architektur- und Software-Innovation“ und findet dieses Jahr in der zweiten Novemberwoche statt. Ich selbst besuche die Konferenz Dienstag und Mittwoch. Zunächst erscheint auch alles vertraut: Veranstaltungsort ist ein bekanntes Münchner Hotel, für das leibliche Wohl wird rund um die Uhr gesorgt und am Empfang holt man sich seine Hundemarke. Anstatt eines Programmheftes oder einer Webseite gibt es jetzt eine Äpp und statt Postersessions haben die Firmen ganze Stände aufgebaut: das hat schon fast Messecharakter. Vertreten sind vor allem Beraterfirmen auf der Suche nach Rekruten und Technologieanbieter auf der Suche nach Kunden. Die ganz großen Spieler lassen sich nicht blicken, aber Microsoft und IBM schicken mit GitHub und RedHat immerhin Tochterunternehmen; völlig wollte man da wohl den Locals das Feld nicht überlassen.

Die Gespräche an den Ständen sind größtenteils interessant und ertragreich: in nur zwei Tagen ergattere ich sechs T-Shirts und ein Paar Ohrringe, sowie einen Sack kleiner Gimmicks und Flyer. Als Obolus wünschen sich die Aussteller lediglich, die eigene Marke mit einem pfiffigen kleinen Gerät scannen zu dürfen: es gäbe da einen Wettbewerb unter den Ausstellern, wer am meisten scannt bekäme einen Preis. Erst hinterher stelle ich fest, dass die jeweiligen Firmen so in den Besitz meiner Emailadresse geraten. Noch Tage später melde ich mich genervt von diversen „Informationsmailinglisten“ ab – DSGVO sei Dank zum Glück relativ schmerzfrei.

Auch gibt es nicht die Keynote, sondern gleich mehrere. Diese sind jedoch fast alle unsägliche Werbeveranstaltungen der jeweiligen Sponsoren: meine Bingokarte, hätte ich eine mitgebracht, hätte ich in den ersten fünf Minuten voll bekommen.

Egal, das Wichtigste auf einer Konferenz sind schließlich die Sessions. Davon sind die meisten allerdings nicht sonderlich weltbewegend. Hier ein Microservice, dort ein Eventstream, an anderer Stelle ein Entwurfsmuster um ein spezifisches Problem das man ohne Microservices und Eventstreams nicht hätte, zu lösen. All das kennt
man schon irgendwie aus dem Alltag, die W-Jax setzt also nicht die Trends, sondern scheint sie eher nachträglich zu dokumentieren. Das gleiche Gefühl bekomme ich, wenn ich das Publikum betrachte: vorwiegend altersgraue Herren, die so aussehen, als hätten sie damals im Krieg schon Java eingesetzt und hätten vor, das auch im nächsten Krieg noch zu tun. Klar, auf einer Javakonferenz erwarte ich keinen Hauptfokus abseits von Java; doch ein etwas mutigerer Blick über den Tellerrand hätte ich mir schon gewünscht: Spezies die sich überspezialisieren evolvieren in eine Nische und sterben, wenn diese Nische verschwindet, irgendwann aus.

Über Chaos-Engineering

Also Vorurteil bestätigt und ich kann die nächsten fünf Jahre wieder auf Kongresse, Tagungen und Symposien verzichten? Nicht ganz, ein kleiner Herr der gerne Motorrad fährt und für seine Keynote mit Rockgitarre auf die Bühne steigt und ein Stück zum Besten gibt, dass einem die Füße wippen, leistet der einhelligen Lethargie tapfer Widerstand: Russ Miles Vorträge zum Thema Chaos Engineering sind mitreißend, hervorragend erzählt, mit wundervollen Anekdoten untermalt und behandeln das immens wichtige Thema der Widerstandsfähigkeit von Software gegen die unvermeidbaren Katastrophen der realen Welt.

Die Grundidee ist schnell erklärt: ganz im Geiste der Wissenschaft versucht das Team über kontrollierte Experimente das eigene System in Schwierigkeiten zu bringen und daraus zu lernen. Dabei sind einige Dinge zu beachten.

• Das Team ist dasjenige welches die Software entwickelt und betreut. Die Akzeptanz der Methode ist nur gegeben, wenn sie nicht von außen oktroyiert wird sondern von Innen heraus angewendet wird. Einfach durch den Laden Laufen und anderer Leute Projekte kaputt hauen lässt einen mehr wie einen Vandalen als einen Samariter erscheinen.
• Experiment bedeutet, dass der Ausgang vorher unbekannt sein muss. Wenn ich sicher weiß, dass der Ausfall zweier Knoten meine Cloud einfrieren und abstürzen lässt, muss ich es nicht ausprobieren. Das Ziel ist es, etwas Neues zu lernen und aus dieser Erkenntnis nutzen zu ziehen.
• Kontrolliert bedeutet, dass ich einen definierten, reproduzierbaren Ausgangszustand benötige. Der erste Schritt eines derartigen Experimentes ist es also, „Normalität“ zu definieren und zu verifizieren, dass diese vorliegt, bevor die Störung eingebracht wird. Was normal ist, hängt dabei vom Kontext ab: Verfügbarkeit von Services, Ressourcenverbrauch innerhalb festgelegter Grenzwerte, durchschnittliche Antwortzeit, usw.

Die Definition von normal spielt außerdem eine zweite Rolle am Ende des Experiments: wenn die eingebrachte Störung zu keiner Abweichung geführt hat, dann hat das System das Chaos überstanden. Ansonsten kennt man nun ein mögliches Desasterszenario und das ganz ohne Post-Mortem! Hierbei geht es auch gar nicht darum, die Störung möglichst schnell zu beseitigen (daran arbeiten EntwicklerInnen reflexhaft eh als erstes), sondern den Rest des Systems gegen die Auswirkungen desselben zu immunisieren. Russ fasst das in einem wunderschönen Bonmot zusammen:

One backend service ran amok and started a distributed denial of service attack against its own database. Everyone was trying to fix it but I just thought about how I could make it do that more often.

Am Ende versucht natürlich auch Russ etwas zu verkaufen: sein Framework ermöglicht es, diese Chaosexperimente in Chaostests umzuwandeln, die in eine CI/CD-Pipeline eingebracht und somit vor Regressionen schützen können.

Ich jedenfalls bin begeistert und werde mich dafür einsetzen, zur Stärkung unserer Produkte und auch um etwas Spaß im Team zu haben, im Projekt mal einen derartigen Game Day durchführen zu können! Ich bin mir sicher, wir werden vieles Lernen!

Fazit

Am Ende bleiben gemischte Gefühle. Die industrietypischen Werbeveranstaltungen sind wahrscheinlich der Preis, den man entrichten muss um so ein großes Ereignis überhaupt finanziert zu bekommen. Die Vorträge waren von gemischter Qualität, hatten aber ihre Sternstunden: neben dem Rockgitarre spielenden Russ Miles gab es z.B. auch eine Poetry Slam Einlage. Fürs nächste Mal wünsche ich mir einen Ruheraum mit gedimmtem Licht und Bibliothekslautstärke, in dem introvertierte Seelen ihr Sozialmana auftanken können – andere Konferenzen haben es bereits vorgemacht. Außerdem sollte die Praxis der Mailadressenweitergabe deutlicher kommuniziert oder besser noch ganz eingestellt werden. Sowas geht wirklich überhaupt nicht.