W-JAX 2022 in München

Die Zukunft der Frontend Entwicklung 

Rainer Hahnekamp von AngularArchitects.io wagt einen Blick in die Glaskugel für Web-Frontends. Nachdem die Rich Javascript Applikationen anscheinend ein wenig zu fett geworden sind, versucht man die Teile der Applikation, die nicht unbedingt am Client laufen müssen, wie z.B. REST Aufrufe oder Rendering von fixen Teilen der Seite auf die Serverseite zu verlagern. Die Frontend-Frameworks bekommen also ein Backend. Da aber Frontend Entwickler anscheinend nicht im Backend entwickeln wollen, nennen sie es Meta-Frameworks.

Keeping CALM – Konsistenz in verteilten Systemen

Das CAP-Theorem besagt im Groben, dass wir in verteilten Systemen Performanceprobleme bekommen, wenn wir Konsistenz und Ausfallsicherheit haben wollen. Das zeigt sich z.B. daran, dass globale Koordinationsprotokolle wie das XA bzw. 2 Phase Commit Protokoll langsam ist. Siehe auch Architektur in der Cloud. Globale Koordinatoren sorgen dafür, dass z.B. die Reihenfolge von Nachrichten erhalten bleibt und es so nicht zu Inkonsistenzen kommt. Allerdings gibt es für etliche Probleme auch Algorithmen, denen die Reihenfolge egal ist. Z.B. Ob zuerst ein Bleistift und dann der Schreibblock im Warenkorb landet oder umgekehrt, ist egal. Wenn wir also von der reinen Datenebene zur Programmebene gehen, gibt es Fälle, in denen wir Konsistenz ohne globale Koordinatoren erreichen können. Welche das genau sind, besagt das CALM Theorem.

Theorem 1. Consistency As Logical Monotonicity (CALM). A program has a consistent, coordination-free distributed implementation if and only if it is monotonic.

Eine nichtmathematische Erklärung des Theorems findet man hier.

Interessant beim Vortrag war auch der Ansatz, dass man das Objektmodell so aufteilt, dass man die bezüglich Konsistenz unproblematischen Teile von den kritischen trennt und so nur in isolierten Bereichen,  die vielleicht selten auftreten, Probleme mit Konsistenz hat.

What the CRaC – Lightning fast JVM startup

Neben modernen Ansätzen, die u.a. bei Quarkus zum Einsatz kommen, um schnelle Start- und Ausführungszeiten zu erreichen, stellt Gerrit Grunwald von Azul Systems das OpenJDK Projekt CRaC (Coordinated Restore at Checkpoint) vor. Ziel von CRaC ist es, die Aufwärmzeit der JVM zu reduzieren, indem es einen Checkpoint von der JVM erstellt. Mit diesem Checkpoint kann die Applikation wieder gestartet und wiederhergestellt werden.

Um den Einsatz von CRaC mal in Zahlen zu visualisieren, werden Spring-Boot, Micronaut, Quarkus und xml-transform verglichen und aus JVM-Startzeiten ohne CRaC von 980 Millisekunden bis 4,3 Sekunden ergeben sich JVM-Startzeiten mit CRaC von 33 bis 53 Millisekunden. Diese Reduktion entsteht, weil CRaC lediglich den Checkpoint laden muss, wo der Code schon kompiliert und optimiert ist. Die relativ hohe Start- und Aufwärmzeit und hohe CPU Auslastung beim JVM Start ist somit eliminiert.

Links
CRaC
DEMO

Moderne Web-Apps mit Angular und Spring Boot
{WORKSHOP}

In diesem Workshop wurde eine kleine Web-Applikation gebaut, bei der Spring Boot und Angular zum Einsatz kommen. Neben Spring Boot und Angular wurden auch Themen wie REST, HATEOAS, npm, Jasmine und Karma näher erläutert.

Das Ganze ist sehr gut zum Kennenlernen der Thematik geeignet. Die einzelnen Übungsaufgaben sind zwar aufeinander aufgebaut, können aber in beliebiger Reihenfolge erledigt werden. Die Lösung zu jeder Aufgabe ist auch dabei. Das Projekt und die Folien vom Vortrag sind auf GitHub verfügbar.

Die All Stars der Software-bugs und was wir von ihnen lernen können

Christian Seifert stellt hier berühmte Bugs vor, die es bis auf die Schlagzeilen geschafft haben. Im Folgenden eine Zusammenfassung der Bugs und deren Ursache.

Mars Climate Orbiter (1999): Raumsonde vorscholl kurz vor Ankunft am Mars
Ursache: Zwei Teams entwickelten unterschiedliche Teilsysteme und benutzten einerseits imperiale Einheiten und andererseits SI-Einheiten. Die Sonde schickte Daten in der Einheit Pounds of Force und die NASA interpretierte diese in der Einheit Newton

Therac-25 (1980s): Bestrahlungsgerät führte zur Überdosis, bei der drei Menschen starben
Ursache: Race Condition bei der Dateneingabe (erst nach 2 Jahren aufgetreten)

Nebenursache: Eingesetzt wurde für die Software ein einziger Entwickler, der die Qualitätssicherung für sich selbst durchgeführt hat

Ariane 5 (1996): Beim Start der Rakete kam es zur Explosion
Ursache: Umwandlung eines 64 Bit Floating Point Wertes in einen 16 Bit Signed Integer

Nebenursache: kein Exception Handling, Backup Software verwendete denselben Code, Code wurde aus dem Vorgängermodell Ariane 4 übernommen

Microsoft Zune (31.12.2008): Das Gerät ging nicht mehr an
Ursache: Edge Case bei der Datumsberechnung (Schaltjahr)

iOS (01.01.2012): Der Wecker hat nicht funktioniert
Ursache: Edge Case bei der Datumsberechnung (Week based year). Der 01.01.2012 war kalendarisch noch in der letzten Woche von 2011, wodurch der Wecker gedacht hat, es wäre der 01.01.2011.

Lockheed F-22 Raptor (11.02.2007): Ausfall des Onboard-Computers mitten über dem Pazifik (musste vom Tanker nach Hause navigiert werden)
Ursache: Überschreiten der internationalen Datumsgrenze

Microsoft Windows Genuine Advantage (August 2007): Lizenzvalidierung von Windows schlugen auch bei validen Lizenzen fehl
Ursache: Validierungscode zu früh auf der Prod deployed
Nach 30 Minuten wurde das Problem erkannt, erst nach 12 Stunden erfolge das Rollback

Log4j (2021): Geloggte Nachricht kann fremden Code ausführen
Ursache: Bei der Ausgabe vom User-Agent als Logeintrag kann Code eingeschleust werden, der ausgeführt wird.

Dieses Verhalten war aber klar dokumentiert. War es ein Bug? Wo fängt ein Bug an? Wo hört ein Feature auf? 

Boeing 787 Dreamliner (2020): muss alle 51 Tage neu gebootet werden (auch heute noch)
Ursache: Daten sammeln sich im Speicher an und können dazu führen, dass irreführenden Daten anzeigen werden

Gespräche mit Ausstellern

Sonatype supported Nexus Repository Manager. Neu für mich war, dass sie auch einen Security-Scan anbieten. Nachdem Nexus ein Proxy für alle Binären Artefakte sein kann (auch Container Images), würde man vulnerable Binaries gleich beim Eingang ins System abfangen und nicht erst in einem späteren Build-Schritt. Klingt für mich besser, als z.B. auf Sonarqube aufzusetzen. Ist nicht kostenlos.

Gradle Enterprise behauptet, Maven oder Gradle Builds durch Einsatzes eines Caches um 30% schneller zu machen. Wenn das auch bei Container-Builds gut klappt, könnte man sich einiges an Schwierigkeiten sparen, um State (Persistent Volumes) in die Build-Pods zu bekommen.

Azul supportet eine JVM (OpenJDK Basis). Hat auch in Österreich einige Kunden. Auch sie gehen mit Performance hausieren. Concurrent GC. Mal sehen, ob sie auf Dauer mit Shenandoah GC oder ZGC mithalten können.

Sonargraph macht statische Codeanalyse mit Fokus auf Architektur. Schöne Abhängigkeitsgraphen, Möglichkeit zu Architekturdefinition und Überprüfung. Wäre interessant es mal auf Brocken wie LGK loszulassen. Ist allerdings nicht ganz billig.

Fazit

Ich persönlich fand den Vortrag sehr gelungen, sprachlich eine top Leistung ohne einen einzigen störenden Aufhänger. Falls jemand die Gelegenheit hat, einen Vortrag von Christian Seifert zu erleben, kann ich nur empfehlen,  diese auch zu nutzen.