events-meetups

JAX 2019

// 16-05-2019

Monolithen vs. Micro-Services

Es spricht generell nichts gegen einen gut strukturierten Monolithen und Micro-Services sind kein Allheilmittel! Wenn man einen „Big Ball of Mud“ (Wollknäuel, Monolithisches Konstrukt mit hohen Abhängigkeiten zwischen den Modulen) in Micro-Services aufteilt, bekommt man typischerweise einen „Distributed Big Ball of Mud“. Dies ist die schlechteste Lösung, da man alle Nachteile des Monolithen mit den Nachteilen von Micro-Services kombiniert.

Domain-Driven Design

Das Modell soll die Wirklichkeit abbilden, sprich der Code soll nicht mehr ermöglichen als die Realität. Ein schlechtes Zeichen sind beispielsweise Setter für jedes Feld. „Setters cause model anemia“ („Blutleere“ Domänenmodelle). Man soll unbedingt die „Ubiquitous language“, also die Worte der Fachlichkeit nutzen. Wenn also die Fachsprache Deutsch ist, soll man diese auch verwenden.

Wichtig bei DDD: Duplications im Domänenmodell sind ausdrücklich erwünscht. Wenn mehrere Sub-Domains die „gleiche“ Entity benötigt, implementiert jede Sub-Domain die eigene Sicht darauf. „Sharing“ einer Entity führt zu Abhängigkeiten zwischen den „Bounded Contexts“ (abgegrenzte Bereiche innerhalb der Domäne) und ist daher unerwünscht.
DDD war auch Thema von Ludwigs Workshops am Montag. Anhand eines praktischen Beispiels wurden die „Bounded Contexts“ des Domänenmodell ermittelt und mittels „Event Storming“ eine „Context Map“ erstellt. In dieser wurden die „Domain Events“ und „Trouble Spots“ ausgemacht. Abschließend wurden die Sub Domains in „Core-“, „Supporting-“ und „Generic-Domains“ eingestuft.

Security

Am Montag hat Sabrina beim Pentesting Workshop teilgenommen. Dabei wurde das Bewusstsein für die kritischsten Sicherheitslücken geschaffen, und gezeigt wie wir diese finden und verhindern können. Der praktische Teil war sehr interessant, weil wir eine unsichere Webapplikation angreifen durften und selbstständig versucht haben, verschiedenste Arten von Sicherheitslücken zu finden, zB SQL Injection oder Cross-Site Scripting.
Erkenntnisse aus dem Vortrag “Die sieben Security-Sünden agiler Projekte” sind, dass es für eine sichere Applikation wichtig ist sich zu überlegen, wo die Applikation angreifbar ist (Whiteboard Hacking). Automatisierte Security-Tests und Aktualisieren von Dependencies sollte ebenfalls gemacht werden. Jährliche Pentests und Vorbereitung auf einen potentiellen Angriff, zB durch hilfreiches Logging und Monitoring, ist empfehlenswert.

Hibernate Workshop jenseits von CRUD

Am Freitag haben wir beide an einem Power-Workshop zu Hibernate teilgenommen. Nach jeweils einer kurzen theoretischen Einführung wurde das gelernte gleich anhand mehrerer Programmier-Übungen praktisch umgesetzt. Die Themen waren „Multitenancy“ (Trennen der Daten bei Applikation mit mehreren Mandanten), „Volltextsuche mit Lucene bzw. Elasticsearch“ und „Auditing/Versionierung mit Envers Audit“.

Neues (Lizenz-)Modell von Oracle JDK

Updates gibt es alle 3 Monate, Feature Releases alle 6 Monate. Versionen mit LTS kommen alle 3 Jahre (JDK 11, 17, 23, …). Oracle JDK 1.8_201 ist die letzte freie LTS Version.

Wichtig: Oracle JDK ist für Entwickler selbst immer frei, erst sobald die Runtime „kommerziell verwendet wird“ ist eine Subscription notwendig. Wenn beispielsweise ein anderes System die Java Runtime nutzt (z.B. Jenkins) ist das auch während des Entwicklungsprozesses kostenpflichtig.
Parallel zur Oracle JDK gibt es Oracle OpenJDK, wofür keine Subscription benötigt wird. Allerdings sind dafür nur 2 Sicherheitspatches vorgesehen, dann folgt die nächste Version.

Java in Containern

Ziele: Schnellere Startup Times, häufige Deployments, GC mit sehr kurzen Latenzen, weniger Speicher, kleinere Runtimes, „static compile“ statt JIT

Neuerungen in JAVA 9-12

  • Sprach Features (Switch Expressions, Verbesserungen bei Nested Classes, „var“ Keyword, private Methoden in Interfaces [Defaults])
  • Operations (G1 GC gibt heap wieder zurück, verbesserter Docker Support, Multi-Version JARs, neuer Garbage Collector ‘Shenandoah’)
  • Libraries (diverse Verbesserungen bei Strings, Sets, Streams, IO, HTTP Client, Stackwalkers, Spinlocks, UTF8 Property files [Resource Bundles])

 

Shenandoah

In diesem Vortrag wurde die Funktionsweise von Shenandoah erläutert. Shenandoah ist ein neuer Garbage Collector (ab JDK12) mit sehr niedrigen Stop-the-world Zeiten (<10 ms). Als Ausgleich dafür ist allerdings das Erzeugen von Objekten, Lese- und Schreibzugriff verlangsamt und der Heap vergrößert.

Neuerungen im SQL-Standard seit SQL-92

Durchgängiger Tenor: SQL ist eine sehr leistungsfähige, transformative Sprache, die von den meisten nur für CRUD genutzt wird obwohl sich viele Aufgaben bzw. Probleme einfacher, effizienter und performanter direkt in SQL lösen lassen würden (Provokantes Stichwort: „Business logic in the persistence layer / database“.
Neue Funktionalitäten sind beispielsweise GROUPING SETS für mehrere GROUP BY-Klauseln, WITH RECURSIVE für Rekursionen oder OVER für Aggregationen ohne Merge der Zeilen.
Viele Features des Standards werden selbst nach 10-20 Jahren noch nicht von den großen DBs unterstützt. Prominentes Beispiel: Seit SQL-2011 gibt es „System Versioning“, mit dem Auditing und Historization automatisch und ohne großes zutun in der Datenbank möglich wäre. Es wird aber wie viele anderen Features noch von keiner DB umgesetzt.

Kubernetes Patterns

Es wurden einige Patterns für Kubernetes vorgestellt, die auch für Openshift anwendbar sind:

  • Predictable demands: Man soll Resource Limits für CPU und Memory setzen, da Kubernetes so besser planen kann
  • Health probe: Liveness probe und Readiness probe sollten für jede Applikation gemacht werden
  • Init Container verwenden: Container innerhalb eines Pods, die zu Beginn gestartet werden. Erst wenn diese fertig sind werden die Applikations-Container eines Pods gestartet.
  • Operator: ist nützlich für die Installation und Konfiguration von Applikationen.

 

Timeless Design Principles over Time

Es wurden die „modular Design Principles“ (single responsibility, polymorphism, interface segregation und encapsulation) anhand von aktuellen Sprachen (Kotlin), ältere Sprachen (Ruby, Visual Basic, C) bis hin zu SIMULA67 (die erste „objekt-orientierte“ Sprache aus den 60er Jahren) betrachtet.

Technical Excellence in agilen Projekten

In diesem Vortrag ging es darum, wie man in agilen Projekten eine gute (technische) Qualität liefern kann obwohl kontinuierlich neue Features entwickelt werden. Helfen kann hier beispielsweise eine Zero Bug Policy (wodurch jeder Bug im nächsten Sprint behoben werden muss, dadurch sinkt die Velocity und die Qualität wird messbar) oder Collective Ownership.

 

Fotos: Jax 2019