Cloud-native Java, Domain-driven Design und C64: 10 Take-aways von der W-JAX 2019

Die W-JAX 2019 versammelte über 1100 IT-Profis in München, um aktuelle Trends der Java-Szene zu diskutieren. Wir fassen einige der Highlights zusammen. Was haben wir von der Konferenz mitgenommen?

Take-away #1: Java steht vor einer Mauer

Mit welcher Java-Version arbeiten Sie? Die Chancen stehen gut, dass in Ihrem Unternehmen noch Java 8 im Einsatz ist – wie bei insgesamt 83% der Java-Nutzer. Diese regelrechte Mauer, hinter der sich viele Entwickler offenbar verschanzt haben, ist aber ein Problem, wie Sebastian Meyen in seiner W-JAX-Eröffnung ausführte.

Java vor der Mauer Java 8, Quelle: JetBrains

Während die Innovationsgeschwindigkeit von Java mit der erhöhten Release-Frequenz gestiegen ist, sinkt gleichzeitig die Bereitschaft zum Update. Und wer nicht updated, läuft Gefahr, abgehängt zu werden. Warum? Weil inkrementelle Updates von einer Version zur nächsten meist einfacher sind als der Sprung über viele Versionsnummern hinweg. Die Mauer wird dann zwar nicht höher, dafür aber umso breiter.

Wie auch immer man mit den schnelleren Java-Releases umgeht – es wäre tragisch, wenn der Java-Zug just zu dem Zeitpunkt zum Stillstand käme, da die Innovation Fahrt aufnimmt. Meyen:

Es wäre schade, wenn Java zum neuen Cobol würde, wenn die IT-Welt in einigen Jahren resümieren müsste: Java ist bei Version 8 stehengeblieben – den Rest hat niemand mehr mitgemacht.

Take-away #2: Es gibt keinen Grund, bei Java 8 zu bleiben

Arno Haases Übersichtsvortrag „Neues in Java“ knüpfte an die Eröffnungskeynote an und begann mit einer wichtigen Aussage:

Es gibt keinen Grund, bei Java 8 zu bleiben.

Eine anschließende Umfrage unter den Anwesenden zeigte allerdings, dass diese Botschaft noch nicht sehr weit durchgedrungen zu sein scheint. Das lässt zumindest die Tatsache vermuten, dass sich auf die Frage, wer noch Java 8 nutzt, deutlich mehr Session-Besucher meldeten, als auf die Frage, wer bereits höhere Versionen verwendet.

Hierauf ging Haase in medias res und erläuterte – wie angekündigt „mit einem Minimum an Folien und viel Quelltext“ -, was es Neues in Java gibt, also unter anderem Switched Expressions in Java 13, besserer Docker-Support (Java 10), das var-Keyword (Java 10), Nests (Java 11), Factory-Methoden für Collections (Java 9). All diese und andere Neurungen zeigte Arno Haase direkt im Code und schaffte es auf diese Weise, die Aufmerksamkeit des Publikums auf sich zu ziehen.

Man darf gespannt sein, ob sich die Bindung an Java 8 langsam aber sicher lösen wird und höhere Versionen zur Anwendung kommen werden, oder ob es bei der konservativen Haltung bleibt, die derzeit vorzuherrschen scheint. Haases subjektiver Überblick über die neuen Features in Java stellte zumindest ein profundes Plädoyer für ein Annehmen der und ein Upgrade auf die neuen Versionen dar.

Take-away #3: Java ist nicht mehr kostenlos – oder doch?

Wir haben es also nun verstanden: Java steht aktuell vor einer Java-8-Mauer. Dass Oracle sein Lizenzmodell geändert hat und man ab JDK 11 dieses nicht mehr kostenfrei in der Produktion nutzen kann, gibt Entwicklern allerdings auch keine Räuberleiter, um die Java-8-Mauer zu überwinden.

Seit Januar 2019 gibt es zudem keine freien Updates mehr für das momentan noch viel genutzte Oracle JDK 8. Doch wer wird denn hier den Kopf in den Sand stecken? Denn in diesem Fall soll der Volksmund recht behalten: Wo sich eine Türe schließt, geht eine andere auf.

In seiner Session erklärte Falk Sippach (OIO – Trivadis), welche Türen das im Speziellen sind. So gibt es doch noch andere kommerzielle Anbieter wie Azul, IBM und Red Hat sowie die freien Versionen OpenJDK, AdoptOpenJDK, Amazon Correto, Alibaba Dragonwell und SapMachine.

Neben all den Alternativen stellte Falk Sippach jedoch eines klar: Java-Updates gab es schon immer. Zudem kam das größte Update mit Java 9 – alles danach hatte mehrheitlich kleine Änderungen im Gepäck. Also los, liebe Java-Coder, lasst uns die Java-8-Mauer überwinden!

Take-away #4: Java ist eine Cloud-native Technologie

Wohin geht die Reise bei Enterprise Java? Mit Vollgas in die Cloud, zeigten viele Sprecher der W-JAX in ihren Sessions auf. So auch Lars Röwekamp (Open Knowledge) in „Enterprise Java on Steroids.” Zum einen haben wir gerade die Verschiebung der Java-EE-Standards zur Eclipse Foundation hinter uns, wo sich mit Jakarta EE 8 jüngst ein erstes Release herausgeschält hat. Zum anderen ist das Eclipse Microprofile angetreten, die EE-Standards zu modernisieren und zu erweitern, um sie ins Cloud-Zeitalter zu tragen. Beide Projekte werden sich gegenseitig befruchten – auch wenn noch nicht ganz ausdiskutiert ist, wie genau das vonstatten gehen wird.

Wem Standards nicht so wichtig sind, findet mittlerweile bei zahlreichen Microframeworks wie Micronaut, Javalin oder Ktor nützliche Helferlein. Den Sweet Spot zwischen Standard-Konformität und Innovation trifft laut Röwekamp momentan das Quarkus Framework. Das von Red Hat initiierte Projekt nutzt die GraalVM, um aus Java-Code native Binaries herzustellen, die es in Sachen Performanz und Memory Footprint mit Cloud-native-Lieblinge wie Go oder Node.js aufnehmen können. Aber auch ein JVM-Mode ist eingebaut, genauso wie die Unterstützung gängiger EE-Standards und verbreiteter Java-Projekte wie Spring, Hibernate, Apache Camel, Flyway, Kafka, Vert.x….

Wir müssen unser Wissen, das wir in den letzten Jahren als Java-Entwickler aufgebaut haben, also nicht wegwerfen – und können dennoch Cloud-native Anwendungen der neuesten Generation schreiben!

Take-away #5: Von Monstern und Microservices …

Die Session von Hanna Prinz (INNOQ) zum Thema Service Mesh zeigte zunächst vor allem, dass das Thema viele interessiert, da der Raum zum Bersten gefüllt war. Wie die Umfrage per Handzeichen zeigte, halten nicht allzu viele das Thema für eines, vor dem man einen riesigen Respekt haben muss. Dass dennoch nicht unbedingt viele mit Service Meshes arbeiten, wie die nächste Anfrage ins Plenum offenbarte, war dann doch erstaunlich.

Die Grundfrage zu Beginn: Wenn sich ein Monolith so wunderbar in Microservices aufspalten lässt, wozu braucht man dann einen Service Mesh? Das Service Mesh Tool verhindert, dass sich Microservices zu sehr an eine Umgebung binden, sie erhalten einen Beiwagen (sidecar) und eine zentrale Anwendung (Control Plane), die mit diesen Sidecars verbunden ist (Data Plane). Kurz gesagt: Komplexität wird ausgelagert. Das Ganze zeigte Prinz anhand von Monsterbildern sehr anschaulich.

Doch die Speakerin verabschiedete sich schnell von den goldigen Gruselviechern, und es wurde deutlich technischer. Anhand einer Beispielanwendung zeigte Prinz, wozu ein Service Mesh gut ist, auch wenn nicht ganz klar wird, wozu Eberhard Wolff 12 iPods braucht!?!

Doch Spaß beiseite. Schnell wurde klar, wo die Vorteile des Service Meshs liegen respektive wobei er helfen kann und Features zur Verfügung stellt: Observability (Telemerie-Metriken und -Logs, Daten an Tracing-Backend senden), Routing (Komplexe Routing-Regeln, Canary Releasing & A/B-Testing), Resilience (Automatische Timeouts & Retrys, automatisches Circuit Breaking) und Security (Authentifizierung mit mTLS, Autorisierung).

Nach der Vorstellung diverser Service-Mesh-Implementierungen und zahlreichen interessierten Zwischenfragen sowie einer weiteren Frage ans lebhaft antwortende Publikum, was für die Auswahl eines Service Meshs wichtig ist (Features, Kompatibilität, Performance, Usability), bleibt die Conclusio: Ein Service-Mesh-Werkzeug löst viele wesentliche Probleme von Microservices, und das ohne Codeänderungen. Nachteil: Man führt eine weitere komplexe Technologie ein.

Zur Entscheidungshilfe „Mesh oder nicht Mesh“ gab Prinz den Zuhörern den folgenden Ratschlag mit auf den Weg: Ein Service Mesh lohnt sich, wenn ein Großteil in Kubernetes läuft, wenn es viele Microservices und viele synchrone Aufrufe gibt und wenn viele ungelöste Probleme beim Monitoring, Routing, Resilienz und/oder Security existieren.

In diesem Zusammenhang ist ein Hinweis auf den Schwerpunkt von Hanna Prinz und Eberhard Wolff zum Thema Service Mesh im Java Magazin angebracht, der das Thema vertieft, und allen Interessierten ans Herz gelegt sei.

Take-away #6: Mobbing ist agile

Unter diesem Motto hielt Thomas Much (freiberuflicher Agile Developer Coach und Softwareentwickler) eine Session zum Thema „Mob Programming“ und räumte zunächst einmal ein paar Vorurteile aus dem Weg. In Expertenkreisen ist schließlich auch gerne mal von „Mobbing“ die Rede, allerdings sollte dieses nicht mit dem deutschsprachigen Gebrauch des Wortes verwechselt werden.

Mobbing ist im agilen Kontext also keinesfalls mit dem englischen „bullying“ gleichzusetzen. Mob Programming ist ein Nachfolger des Pair Programmings, wodurch sich auch die Idee dahinter ableiten lässt – nämlich das Programmieren im Team.

Berechtigterweise kommt hier die Frage auf, wozu Mob Programming nötig ist, wenn es doch bereits Pair Programming gibt. Diese Frage beantwortet Much mit einem Zitat von Tim Ottinger:

If your agile team has individual work assignments, I suspect it is neither agile nor team.

Im Gegensatz zum Pair Programming wird der Gedanke beim Mob Programming etwas weitergeführt: Die Teams bestehen nicht mehr länger aus zwei Entwicklern, sondern Devs, Ops, Product Owner und QS arbeiten zusammen. Dazu wird etwa der Platz an der Tastatur alle 5-10 Minuten gewechselt. Die ideale Mob-Größe besteht laut dem Speaker aus 5-6 Personen. Zu den Vorteilen zähle etwa die weniger enge Zusammenarbeit als im Zweier-Team, die mitunter schwierig sein könne. Zudem sei es nicht nötig, dass alle Beteiligten kontinuierlich anwesend seien. Ziel ist die gute und zügige Fertigstellung der wichtigsten Aufgabe.

Das Resümee Muchs am Ende: Vielleicht wird Mob Programming in 20 Jahren selbstverständlich sein.

Take-away #7: Wir sagen Docker, aber meinen Container!

Es scheint ein indirektes Motto der W-JAX 2019 zu sein: die Kommunikation in der IT! Bereits am zweiten Tag erklärte uns J.B. Rainsberger (Diaspar Software Services, Inc) „Programming is the Easy Part“ – die größte Herausforderung liegt in der Kommunikation.

Wohl ungeplant daran anknüpfend, tauchte Laurie Barth (GatsbyJS) in ihrer Keynote noch etwas tiefer in die Materie ein. Auf amüsante Weise zeigte sie den Zuschauern, wie oft man eigentlich aneinander vorbeiredet, fest davon überzeugt, dass man mit dem Gegenüber über dasselbe Problem diskutiert.

Schuld daran sind nicht nur verschiedene Definitionen von bestimmten Begriffen, sondern auch Synonyme, die sich unbewusst in unseren Wortschatz einschleichen. Wir sagen Tempo, meinen aber ein Taschentuch; wir sagen Docker, wenn wir über Container sprechen; wir sagen Git, aber meinen GitHub. Neben zahlreichen Do’s and Dont’s machte Laurie aber vor allem eines deutlich: Während man stetig an seiner Entwickler-Karriere arbeitet und seine technischen Fähigkeiten wie selbstverständlich erweitert, wird die Kommunikationsfähigkeit eher stiefmütterlich behandelt. Ein Experte zeichne sich allerdings nur dadurch aus, dass er alle Fähigkeiten beherrschen und erklären könne: Technologien, Bugs und das Vokabular!

Take-away #8: Nur eins ist konstant – die Veränderung

Dem Thema Software-Architektur nahm sich die Keynote von Patrick Kua an. Der Chief Scientist und ehemalige CTO der Bank N24 stellte die brennende Frage: Wie schafft man es in Zeiten sich immer schneller verändernder Rahmenbedingungen, Software-Architekturen zu bauen, die mit dem steten Wandel Schritt halten?

Kua sieht die Antwort in dem Konzept evolutionärer Architekturen. Wodurch zeichnen sich diese aus?

Patrick Kua in seiner W-JAX Keynote: Building Evolutionary Architectures

Evolutionäre Architekturen tragen zunächst einmal der Erkenntnis Rechnung, dass Software in inkrementellen Schritten entsteht. Software-Entwicklung ist kein linearer Prozess, an dessen Anfang eine Architektur-Skizze steht, die dann stur implementiert wird, um am Ende das fertige Produkt zum Release auszukotzen. Evolutionäre Software-Architektur vollzieht sich vielmehr in vielen Schleifen: Nach dem Release einer kleinen Einheit wird Feedback eingeholt, auf dessen Basis Entscheidungen für die Weiterentwicklung getroffen werden können.

Feedback ermöglicht fundierte Veränderung – Guided Change, sagt Kua. Grundlage dafür können sogenannte Fitness Functions sein, die messen, wie gut eine gegebene Lösung einen bestimmten Zweck erfüllen. Auch die Konzepte des Chaos Engineering sind hilfreich, insofern hier gezielt überprüft wird, wie gut Software-Systeme mit Ausfällen zurecht kommen. Resiliente Software-Architekturen lautet hier das Stichwort.

Von diesem Punkt aus kommt man dann schnell auf die Idee des Continuous Delivery. Grundlage für die Etablierung einer CD-Pipeline sei allerdings eine passende Kultur, ergänzte Kua, eine Art „DevOps-Mindset“, bei dem interdisziplinäre Teams die Verantwortung über den gesamten Feedback-Zyklus übernehmen. Kuas Liebslingszitat aus dem Buchklassiker „Continuous Delivery“ von Jez Humble und David Farley lautet:

If it hurts, do it more often.

Zu guter Letzt vollzieht sich Weiterentwicklung stets auf mehreren Dimensionen. Auf technischer Ebene sind dies zum Beispiel neue Sprachen, Frameworks, Tools und Systemupdates. Auf fachlicher Ebene können Änderungen des Marktes, neue Einkommensmodelle, ein verändertes Konsumverhalten oder eine neue Wettbewerbssituation Anpassungen an die Software-Architektur verlangen.

Kuas Fazit: Software-Architektur beschäftigt sich nicht nur mit dem Problem der richtigen technischen Entscheidung. Software-Architekten sind zunehmend mit der Frage konfrontiert, WIE gewisse Entscheidungen getroffen werden (sollten). Es geht um die Entscheidungskultur, die Grundlage ist für eine evolutionäre Software-Architektur.

Take-away #9: C64 – Früher war (fast) alles besser!

Core Java, Microservices, Kubernetes – Domain-Driven Design, DevOps, Serverless. Das Themenspektrum der W-JAX war wieder einmal riesig. An den Tagen der Hauptkonferenz liefen zu jeder Zeit 8 Sessions parallel, gehalten von über 130 Experten und Trainern der Szene.

Doch wäre die W-JAX nicht die W-JAX, hätte sie nicht auch ein unterhaltsames Rahmenprogramm im Gepäck: Nach den informationsgeladenen Konferenztagen konnten sich die Besucher abends bei einem Freibier, in der Casino Night oder beim Ballroom näher kennenlernen und die eine oder andere Praxiserfahrung austauschen.

Zum Abendprogramm gehörten auch die Night Sessions am Mittwoch. Ab 20:45 ließen hier zum Beispiel Jörg Neumann (CGI) und Christian Weyer (Thinktecture) den alten Zauber von C64 und 8-Bit-Programmierung wiederaufleben.

Hand aufs Herz: Wieviele von Ihnen haben mit einem 8-Bit Homecomputer und Basic ihre ersten Programmiererfahrungen gemacht? Mit Peeks und Pokes ihre Games manipuliert oder vielleicht sogar via 6502 Assembler die volle Kontrolle über die Maschine erlangt – ganz ohne Betriebssystem, Compiler, Garbage Collector oder IDE? „Die coolen Jungs konnten das damals ganz ohne Sprungmarken“, witzelte Neumann. „Nur Zivilisten zählten mit 0 bis 9 – bei uns hieß das damals #0 – #F“.

Wie man damals mit dem „Open-Source-Knopf“ einer C64 Final Cartridge „unendlich gültige Evaluierungsversionen“ von Spielen herstellen konnte, brachte ebenso Lacher wie die abschließende Zockerrunde mit den C64 Winter Games von Epyx. Dazwischen lagen nostaligische Erinnerungen an Datasetten-Sounds, C64-Werbejingles und Einblicke in die Hardware- und Software-Architektur.

Retro Computing: Spaß mit C64 & 8 Bit – Slides

Zum Mitnehmen war die Erkenntnis, dass Programmierung mit den beschränkten Mitteln von damals mitunter doch einen höheren Spaßfaktor hatte als die langwierigen Großprojekte von heute mit ihren komplexen Entwicklungsumgebungen, ausgeklügelten Microservices-Architekturen und von der Hardware entkoppelten vituellen Maschinen.

Wir haben den Code damals einfach direkt auf den Chip geprügelt.

Und der 8-Bit Sound von damals ist heute immer noch Kult!

Take-away #10: DDD – das Segel vorausschauend setzen!

Die letzte Keynote der W-JAX 2019 wartete mit einer ganzen Armada hochkarätiger Speaker auf, um genau zu sein, derer fünf. Oliver Drotbohm (Pivotal Software, Inc.), Arno Haase (Freiberufler), Marco Heimeshoff (Heimeshoff IT), Dr. Carola Lilienthal (WPS – Workplace Solutions) und Eberhard Wolff (INNOQ Deutschland GmbH) sprachen darüber, wie man Domain-driven Design erfolgreich in Unternehmen einführt. Natürlich ging es darum, von eigenen Erfahrungen bei der Einführung von DDD bei unterschiedlichsten Kunden zu erzählen, aber auch darum, über die neusten Trends und durchaus auch über den einen oder anderen Fallstrick zu berichten.

Der erste Diskussionspunkt: Wo setzt man an, wenn DDD eingeführt werden soll? Beim Management, bei Entwicklern, Architekten oder … ? Von Workshops über dialogfördernde Maßnahmen wie Event Storming oder „von unten“ mit taktischem Design reichten die Vorschläge, und wieder einmal führen viele Weg nach Rom.

Aber funktioniert die Einführung von DDD einfach so? Gibt es keine Probleme und Fallstricke? Doch, natürlich! Von Kunden, die ihre Datenbank und ihr Datenmodell für heilig halten und gegen ein Refactoring sind, bis hin zur Problematik, eine gemeinsame Sprache zu entwickeln, was zwar tendenziell alle gut finden, was sich aber tatsächlich schwer in die Praxis umsetzen lässt. Zum Scheitern verurteilt ist das Ganze laut Marco Heimeshoff, wenn das Management ohne Einbeziehung der Technik DDD einzuführen versucht oder vice versa. Fazit: Es muss Konsens darüber herrschen, Domain-driven Design einführen zu wollen, und Klarheit darüber, wohin man damit will.

Der Kern von DDD lässt sich daran anschließend laut Marco Heimeshoff in folgendem Bild fixieren: das Segel vorausschauend setzen und sich nicht ohne Vorbereitung von Seitenwinden überraschen lassen. Arno Haase ergänzte, dass für ihn das notwendige Mindset des Refactorings darin besteht, beständig lernen zu wollen und auf dem Laufenden zu bleiben.

Eine weitere Erkenntnis: DDD ist kein Ziel, DDD ist ein Werkzeugkasten, der entsprechend viele Tools bietet und nicht auf eine Vorgehensweise festgelegt ist. „Wer motiviert ist, eines dieser Werkzeuge auszuprobieren, möge das tun“, ist Heimeshoffs Botschaft an die Besucher, sei es Tactical Design, sei es Strategic Design. Zudem ist laut Oliver Drotbohm die Einführung von DDD kein Schalter, den man einfach umlegt à la „es werde DDD“, sondern ein andauernder Prozess, in dem man immer und immer dazu lernt, um- und neu denkt – eine motivierende Schlussbotschaft, mit der das Panel schließt.

Weitere Stimmen zur W-JAX 2019

Das war natürlich längst nicht alles, was die W-JAX 2019 zu sagen hatte. Wir haben einige Speaker nach ihren ganz persönlichen Themen auf der Konferenz gefragt!