The cloud has fundamentally changed how we design applications and introduced whole new categories of software-development disasters. With a focus on Java, this talk will introduce some of the new tools, patterns, and best practices for modern distributed application development. It also gives a tour of some of the most painful anti-patterns Holly has seen as a cloud consultant.

Target Audience: Architects, Developers, Strategic Decision Makers
Prerequisites: Basic experience of cloud computing, Knowledge of Java
Level: Advanced

Extended Abstract:
The cloud is just someone else's data center, but it has fundamentally changed how we design software and what we expect from our platforms. Our applications have gotten bigger, more distributed, and more complicated, and there are whole new categories of mistakes we can make. Some things that were a good idea ten years ago turn out to be a terrible idea in the cloud; and what used to be ‘good enough’ for testing really isn’t anymore. Managing microservices architecture demands a lot of us, to ensure observability, operational resiliency, and organisational agility. With a focus on Java, this talk will introduce some of the new tools, patterns, and best practices for modern distributed application development. It also gives a tour of some of the most painful anti-patterns Holly has seen as a cloud consultant.

In der Vorweihnachtszeit 2021 wurden viele IT-Abteilungen von Zero-Day-Sicherheitslücken im weitverbreiteten Java-Logging-Framework Apache Log4j kalt erwischt. Diese Session fasst das Ereignis zusammen und sucht Parallelen zu ähnlichen Zero-Days. Hinweise zu proaktiven Maßnahmen helfen, zukünftig in ähnlichen Situationen schneller reagieren zu können. In diesem Zusammenhang wird u.a. auf Configuration Management und Infrastructure as Code nebst Automation eingegangen, aber auch auf Tools wie Web, DNS und Netzwerk-Firewalls.

Zielpublikum: Architekt:innen, Entscheider, Manager, IT-Sicherheitsbeauftragte
Voraussetzungen: Generelles Verständnis für IT-Sicherheitsherausforderungen bei Web-Anwendungen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In der Vorweihnachtszeit wurden viele IT-Abteilungen von Sicherheitslücken im weitverbreiteten Java-Logging-Framework Apache Log4j kalt erwischt.

Diese Session fasst das Ereignis zusammen und beantwortet die folgenden Fragen, um zukünftig in ähnlichen Situationen schneller reagieren zu können:
•    Welche Möglichkeiten bieten Web, DNS und Netzwerk-Firewalls, um eine Ausnutzung derartiger Lücken zu verhindern?
•    Welche Tools kann ich nutzen, um bspw. mithilfe automatisierter Scans und Analysen des Netzwerkverkehrs festzustellen, welche Bestandteile meiner IT-Infrastruktur betroffen sind?
•    Wie kann ich mit Legacy-Anwendungen umgehen, die ich nicht aktualisieren kann?
•    Wie sollte ich mein Deployment und Betriebsabläufe modernisieren, um Patching zukünftig schneller realisieren zu können?

Automation in Verbindung mit Playbooks und Runbooks ist dabei ein Kernaspekt, um einen Incident Response-Prozess in einer großen IT-Landschaft skalieren zu können.

You've heard about this new feature in C++20, Coroutines, but it's the first time you have encountered this term? Then this talk is what you're looking for. We start from the beginning with just "normal" functions. Next, we introduce Coroutines. Using them, we explore the various customization points C++ offers. Another distinction we make is cooperative and preemptive multitasking, opening the door for another beauty of Coroutines, why we don't need locks.
By the end of this talk, you've learned what coroutines are and where you can use them.

Target Audience: Developers
Prerequisites: C++ knowledge
Level: Basic

Extended Abstract:
You've heard about this new feature in C++20, Coroutines, but it's the first time you have encountered this term? Then this talk is what you're looking for. We start from the beginning with just "normal" functions. Next, we introduce Coroutines.
Using them, we explore the various customization points C++ offers. We look at what the new keywords co_await, co_yield, and co_return are for.
Sadly, we also have to talk about how to write a generator for a coroutine since there is no STL part for that in C++20.
Another distinction we make is between cooperative and preemptive multitasking, opening the door for another beauty of
Coroutines, why we don't need locks.
By the end of this talk, you've learned what coroutines are and where you can use them.

As developers, our job is to deliver working software. With the shift to CI/CD and the move to the cloud, the need to have the right feedback at the right time only increases. There are many ways that testing can help us with that. Not only can testing help us verify our solution and prevent us from breaking things, it can also help us design our software, find flaws in our architecture and come up with better solutions. In this talk I will highlight some of the many ways that testing can help you to develop better software faster.

Target Audience: Developers
Prerequisites: Basic knowledge in Java
Level: Advanced

Extended Abstract:
Testing doesn't always get the attention it deserves in software development. Many developers claim to be bad at it, or are just not that interested. (These may or may not be related.)

As developers, our job is to deliver working software. With the shift to CI/CD and the move to the cloud, the need to have the right feedback at the right time only increases. There are many ways that testing can help us with that. Not only can testing help us verify our solution and prevent us from breaking things, it can also help us design our software, find flaws in our architecture and come up with better solutions.

In this talk I will highlight some of the many ways that testing can help you to develop better software faster.

In this session I’ll examine some of the things that can go wrong when organisations jump headfirst into micro-service architectures without understanding the potential pitfalls.

I'll explain contract testing from the ground up. You'll learn how it can decouple micro-service dependencies during development, allowing your teams to work effectively. And I'll describe sophisticated, free, open-source tooling that helps integrate contract testing into your software lifecycle, giving you the confidence to release micro-services independently.

Target Audience: Architects, Developers, Decision Makers, Release Managers, DevOps
Prerequisites: English, basic software design/architecture, software lifecycle
Level: Advanced

Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierte Enterprise Computing-Lösungen geht. Dies gilt zumindest immer dann, wenn die Anwendung als Monolith in einem Application Server deployed werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind?

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so, mithilfe von Side-Projekten wie dem Eclipse MicroProfile, den Anforderungen moderner Cloud-native-Anwendungen gerecht zu werden.
Ein Ausblick auf das Zusammenspiel mit GraalVM und Quarkus zeigt, dass Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien, aka Serverless, eine gute Figur macht.

Webanwendungen ohne automatisiert getestete APIs machen im Betrieb und Weiterentwicklung schlechte Laune, egal, ob es um APIs zwischen Frontend und Backend, zwischen Microservices oder zu Drittparteien geht. Typischerweise beschreiben wir das erwünschte Verhalten der Anwendung, in dem wir uns selbst Beispiele als Testfälle ausdenken. Da geht mehr. In diesem Beitrag werfen wir einen Blick auf über "naive Integrationstests" hinausgehende Ansätze, von Contract Based bis hin zu KI-Unterstützung.

Zielpublikum: Entwickler:innen, Tester:innen
Voraussetzungen: Erfahrung in der Entwicklung und im automatisierten Testing von Webanwendungen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Älteren unter uns werden sich noch an die Anfänge der Webentwicklung erinnern: Tester:innen klickten sich wieder und wieder durch umfangreiche Testpläne durch, die typischerweise nach dem Entwickeln erstellt wurden. Dieser Ansatz ist leider gerade in Konzernen immer noch nicht ausgestorben. Schlecht getestete Schnittstellen werden schnell zur Achillesferse gerade in modularen Architekturen und vor dem Wunsch, fertige Software schneller in die Produktion zu bringen. Consumer driven contract testing ist zumindest theoretisch mittlerweile in den Teams angekommen, neuere Ansätze wie Search based Software Testing oder Property based Testing sind dagegen noch exotisch.

Die Session will einen praxisorientierten Überblick über unbekanntere Verfahren geben.

Software containerisiert auszuliefern, ist mittlerweile sehr etabliert. Selbst bei Beachtung gängiger Best Practices ist es jedoch schwierig, Docker-Images reproduzierbar und sicher zu machen. Mögliche Folgen sind beispielsweise Versionskonflikte oder plötzlich fehlschlagende CI-Pipelines.

Mit dem Package-Manager Nix kann man einen großen Teil dieser Probleme vermeiden. Insbesondere das Nix-Tooling rund um Docker ermöglicht eine schmerzfreie Erstellung vollständig reproduzierbarer und minimaler Docker-Images.

Zielpublikum: Entwickler:innen, Architekt:innen, Dev-Ops-Ingenieure
Voraussetzungen: Docker-Basiswissen
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Es wird eine kurze Einführung in die Nix-Toolchain und -Programmiersprache geben. Wir schauen uns ein Beispielprojekt an, in dem verschiedene Technologien zum Einsatz kommen. Dabei identifizieren wir gemeinsam diverse Problem einer sehr naiven Dockerisierung des Projekts, und versuchen im Anschluss, diese mit einer "nixifizierten Variante" zu lösen. Als Resultat erhalten wir cache-freundlich minimale und reproduzierbare Docker-Images ‒ baubar sogar ohne Docker-Installation.

Grundlegende Erfahrung mit Docker wird vorausgesetzt. Vorwissen zu Nix ist keine Notwendigkeit.

Immer mehr Entwickler:innen schreiben Anwendungen, die später in einem Kubernetes Cluster laufen sollen. Was kann dabei so schwierig sein? Angefangen "Wie strukturiere ich meine Repositories?", "Wo lege ich meinen Code für das Deployment ab (Containerfiles, Helm Charts, Config Values)?", "Was muss bei der Entwicklung der Anwendung beachtet werden?", "Wie bekomme ich den Code lokal getestet?", "Wie bekomme ich mit, was im Test-Cluster passiert?"

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Kubernetes-Kenntnisse, allgemeine Entwicklungskenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Immer mehr Entwickler:innen schreiben Anwendungen, die später in einem Kubernetes Cluster laufen sollen. Was kann dabei so schwierig sein? Angefangen "Wie strukturiere ich meine Repositories?", "Wo lege ich meinen Code für das Deployment ab (Containerfiles, Helm Charts, Config Values)?", "Was muss bei der Entwicklung der Anwendung beachtet werden?", "Wie bekomme ich den Code lokal getestet?", "Wie bekomme ich mit, was im Test-Cluster passiert?"
Dieser Vortrag geht am Beispiel einer Java-Anwendung die typischen Entwicklungsschritte von der Ablage im VCS bis hin zum Deployment auf einem Cluster aus Sicht einer Entwicklerin durch.

Java applications are widely used and often several years old. You can use these applications in the cloud via lift-and-shift (helps nothing) or you can rewrite the application in cloud-native style and use the advantages of the cloud.

An alternative for existing applications is missing here. It must be possible to go to the cloud and use advantages such as serverless and scale-to-zero WITHOUT having to rewrite the entire application.
I will show what is already working well today and where the rough edges are.

Target Audience: Architects, Developers
Prerequisites: None
Level: Basic

Additional information:
In the session, we'll move an existing application to the cloud and save over 70 % of operating and maintenance costs with serverless and scale-to-zero.

Micro Frontends sind in aller Munde. Und dennoch: Die Integration mehrerer Single-Page Applications zu einem großen Ganzen ist nach wie vor eine Herausforderung!

Wir vergleichen die verfügbaren Optionen samt deren Konsequenzen. Danach werfen wir einen Blick auf die nächste Generation von SPA-Frameworks, die hierbei viele der heutigen Nachteile gekonnt kompensieren.

Am Ende kennen Sie die Optionen für die Integration von Micro Frontends und können sie für Ihre Projekte bewerten.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlagenwissen zu JavaScript von Vorteil
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Zunächst diskutieren wir anhand von Beispielen verschiedene Spielarten von Web Components, das Bootstrapping mehrerer SPAs sowie das Laden von Teilen anderer Anwendungen, wie es z. B. Module Federation oder SystemJS erlauben.

Im zweiten Teil besprechen wir, wie die SPA-Frameworks der nächsten Generation Server-side Rendering und Client-side Rendering gekonnt kombinieren. Hierdurch lassen sich viele Nachteile heutiger Ansätze zur Integration von SPA-basierten Micro Frontends umgehen.

Stellvertretend für diese aufkommenden neuen SPA-Frameworks nutzen wir qwik aus der Feder des Angular-Vaters und Vordenkers Misko Hevery.