Beim Bauen von Softwaresystemen werden tolle Technologien, Programmiersprachen und Tools eingesetzt. Das ist gut und richtig und außerdem macht das viel Spaß.
Dabei verlieren wir immer mal wieder aus den Augen, dass das Entscheidende für den Erfolg unserer Software nicht die Technik, sondern die Fachlichkeit ist.
Haben wir die Anforderungen der Anwender fachlich sinnvoll umgesetzt?
Haben wir unsere Software so strukturiert, dass sie ohne viele Umbauarbeiten um weitere fachliche Funktionalität erweitert werden kann?
Können sich neue Entwickler schnell in unsere Software einarbeiten?
Skaliert unsere Software, wenn mehr und mehr Anwender anfangen sie zu benutzen?
In dieser Keynote wollen wir uns den verschiedenen Ursachen und Missverständnissen widmen, die unseren Fokus immer wieder von der Fachlichkeit weg zur Technik lenken, obwohl wir doch wissen, dass das kontraproduktiv ist.
Die Kommunikation zentraler Architekturideen im Team und gegenüber anderen ist heute wichtiger denn je. Visualisierungen können dabei unterstützen, tun es aber nicht automatisch.
In diesem Workshop vermittle ich Erfolgsfaktoren, um mit angemessenem Aufwand wirkungsvolle Abbildungen Ihrer Softwarearchitektur zu erstellen und zu pflegen. Zur Sprache kommen Notationsoptionen, empfohlene Werkzeuge und Vorgehen.
Der dicht gepackte halbe Tag liefert Ihnen Checklisten, Tipps, Tricks und Hinweise zu häufigen Fehlern aus der Praxis.
Das Gelernte üben die Teilnehmer direkt in kleinen, fokussierten Übungen.
Beim Bauen monolithischer Systeme nutzen Entwicklerteams eine Reihe typischer Muster um die Interaktion verschiedener Systemteile zu implementieren. Behält man diese Interaktionsmuster bei, während man ein System in verschiedene aufteilt, ergeben sich oft große Komplexität und architektonische Nachteile, die oft die ursprüngliche Idee, die hinter der Aufteilung stand, konterkarieren.
Der Workshop betrachtet ein konkretes Beispiel von Modulinteraktion in einem monolithischen System und identifiziert die Problemstellungen die sich ergeben, wenn man dieses System in exakt dem gleichen Interaktionsstil aufteilt. Danach wird eine alternative Implementierungsstrategie für das monolithische System diskutiert, die die Modularität des Ursprungssystems stark verbessert und im Falle einer Aufteilung in unabhängige Teilsysteme zu einer besseren Architektur führt.
Bei Softwareentwicklungsprojekten kommt oft nicht das heraus, was sich der Fachanwender vorgestellt hat. Erst im Einsatz werden die Kommunikationsprobleme zwischen Fachleuten und Entwicklern sichtbar und damit viel zu spät. Wie wäre es, wenn Fachseite und Entwickler miteinander in derselben Sprache sprechen und dadurch frühzeitig merken würden, ob sie sich verstehen? Hier setzt Domain Driven Design (DDD) an: Fachexperten und Techniker entwickeln ganz bewusst eine gemeinsame Fachsprache, die die Basis für die domänengetriebene Architektur bildet.
Aber nicht nur die Fachanwender und die Entwickler missverstehen sich, sondern auch die Entwickler untereinander haben verschiedene Vorstellungen von der Architektur des zukünftigen Systems. Um auch an dieser Stelle hohe Qualität zu gewährleisten, bietet DDD vordefinierte Muster, wie Entity, ValueObject, Service etc. an. Diese DDD-Muster vereinfachen die Kommunikation im Entwicklungsteam und führen zu einer einheitlichen Architektur.
Fachsprache und Muster funktionieren nicht nur für ein System, sondern auch in großen Softwareprojekten mit mehreren Entwicklungsteams oder bei getrennt entwickelten Microservices. Hier kommen Konzepte wie EventStorming, Bounded Context, Context Map, Shared Kernel, Domain Events, Anticorruption Layer etc. zum Tragen.
Carola Lilienthal zeigt Ihnen in diesem Workshop, wie eine Fachsprache entwickelt, verschiedene Bounded Contexts identifiziert und die DDD-Muster eingesetzt werden, um eine an der Fachdomäne orientierte Anwendung zu entwerfen.
Anhand eines großen Systems zeigen Ralf und Gernot, wie Sie mit ziemlich wenig Aufwand angemessene und vernünftige Dokumentation für unterschiedliche Stakeholder produzieren – sodass Entwicklungsteams dabei auch noch Spaß haben.
Das Rezept: AsciiDoc mit arc42 mischen, Automatisierung mit Gradle und Maven hinzufügen und bei Bedarf mit PowerPoint, Grafik- oder Modellierungstools Ihrer Wahl kombinieren - schon bekommen Sie schicke HTML- und PDF-Dokumente generiert, auf Wunsch auch Confluence und docx als Zugabe.
Wir zeigen, wie Sie Doku genau wie Quellcode verwalten können, stakeholderspezifische Dokumente erzeugen und Diagramme automatisiert integrieren können.
Zwischendurch bekommen Sie zahlreiche Tipps, wie und wo Sie systematisch den Aufwand für Dokumentation reduzieren können, geschickt Aufgaben im Team verteilen und ganz nebenbei lesbare, verständliche und praxistaugliche Ergebnisse produzieren.
Zum Schluss zeigen wir, wie Sie Teile dieser Doku automatisiert testen können.
Ralf D. Müller arbeitet als Architekt und Entwickler und erlebt täglich die Notwendigkeit effektiver Dokumentation. Er ist erklärter AsciiDoc-Fan und Committer bei arc42 sowie Gründer des docToolchain Projektes.
We build systems with the assumption of safety: transactions commit atomically, writes are visible now (or at least visible *eventually*) and reads see consistent cuts across our application. However, the databases we rely on often fail to provide these guarantees, especially under distributed systems failure conditions, such as network partitions, partial failure, and clock skew. We will learn how to experimentally verify correctness properties, through case studies of commercial and open-source distributed data stores.
Lernen Sie VENOM kennen, ein großes und über mehrere Jahre lang auch erfolgreiches IT-System.
Hören Sie Erfolgsberichte begeisterter Anwender und Trauerreden beteiligter Entwicklerinnen,
Horrorgeschichten aus Betrieb und Support. Die Protagonisten dieses Systems sind zufriedene und erschrockene Benutzer, motivierte, engagierte und frustrierte Entwickler, scham- und rücksichtslose, effektive und chaotische Manager, Admins und Betreiber und andere.
VENOM stößt an vielerlei Grenzen, das Management wechselt häufig die Fahrtrichtung, das Entwicklungsteam alterniert zwischen Stress, Depression und Euphorie.
Das Management beauftragt „Verbesserung“ - und dann erleben Sie, wie’s gehen kann. Soviel sei verraten: Nicht jeder Ansatz führt zu Erfolg - und manches drohende Desaster kann sich dann
doch noch zum Positiven wenden. Ausserdem sollen Vollbremsungen bei hoher Geschwindigkeit schon so manches Vehikel vor der Kollision mit der (harten) Wand bewahrt haben.
Das hier beschriebene VENOM-System (für _very normal system_) ist einerseits
völlig fiktiv - aber andererseits basieren viele der zugrunde liegenden Entscheidungen, Strukturen und Konzepte maßgeblich auf real existierenden Systemen... Die Verbesserungsansätze, die Sie erleben werden, entstammen sämtlich der Realität.
In this class for engineers who need an overview of distributed systems concepts and techniques, from papers to production, we’ll cover the basics of nodes and networks, common network protocols, clocks, availability, consistency, and a spectrum of distributed algorithms, followed by a discussion of latency scales, engineering patterns, and running services in production.
Alle reden von der Cloud, nur man selbst scheint noch meilenweit davon entfernt. Zu viele offene Fragen, zu wenig konkrete Antworten. Und genau das soll sich in diesem Workshop ändern.
Gemeinsam nehmen wir uns ein typisches Anwendungsszenario aus dem Enterprise-Umfeld vor und migrieren es Schritt für Schritt in die Cloud.
Beginnend bei der Plattforminfrastruktur (DB, Storage etc.) über Standardservices (User Management) bis hin zur anwendungsspezifischen Businesslogik.
Am Ende steht eine rein Cloud-basierte Lösung und natürlich die Diskussion, ob wir es nicht evtl. ein wenig übertrieben haben. Denn nicht alles, was technologisch möglich ist, macht auch für jeden Kontext Sinn.
In this class for engineers who need an overview of distributed systems concepts and techniques, from papers to production, we’ll cover the basics of nodes and networks, common network protocols, clocks, availability, consistency, and a spectrum of distributed algorithms, followed by a discussion of latency scales, engineering patterns, and running services in production.
Alle reden von der Cloud, nur man selbst scheint noch meilenweit davon entfernt. Zu viele offene Fragen, zu wenig konkrete Antworten. Und genau das soll sich in diesem Workshop ändern.
Gemeinsam nehmen wir uns ein typisches Anwendungsszenario aus dem Enterprise-Umfeld vor und migrieren es Schritt für Schritt in die Cloud.
Beginnend bei der Plattforminfrastruktur (DB, Storage etc.) über Standardservices (User Management) bis hin zur anwendungsspezifischen Businesslogik.
Am Ende steht eine rein Cloud-basierte Lösung und natürlich die Diskussion, ob wir es nicht evtl. ein wenig übertrieben haben. Denn nicht alles, was technologisch möglich ist, macht auch für jeden Kontext Sinn.
In einem Fishbowl verschwimmt die Grenze zwischen Sprechern und Teilnehmern: Es bietet eine großartige Möglichkeit, die Themen des Summits ohne vorbestimmte Agenda zu diskutieren. Die Sprecher starten die Diskussion und stellen dabei sicher, dass sie eine möglichst große Menge kontroverser Statements abgeben, um die Diskussion anzufeuern. Danach haben Sie die Chance, an der dynamischen Diskussion teilzunehmen und Ihre eigenen Erfahrungen und Meinungen zu teilen.
Keine Präsentation über moderne Architekturen ohne „Conways Law“: Der Zusammenhang zwischen Organisationsstruktur und Architektur ist mittlerweile fast ein Allgemeinplatz. Aber was machen wir aus dieser profunden und doch gleichzeitig trivialen Erkenntnis?
Mit diesem Vortrag werden wir versuchen, gemeinsam einen Blick auf Herausforderungen, Patterns und Antipatterns von Architekturarbeit in der Praxis zu werfen – und daraus möglichst konkrete Empfehlungen für die tägliche Arbeit abzuleiten.
Bis vor wenigen Jahren bestanden große Applikationen noch aus etlichen Servern mit regelmäßigen Wartungsfenstern und monolithischen Applikationen.
Aktuelle Architekturen bestehen aus simplen Microservices, die untereinander kommunizieren und Nachrichten austauschen. Endnutzer erwarten heutzutage ständige Verfügbarkeit und minimale Antwortzeiten bei gleichzeitig hohen Datenraten.
Diese Anforderungen werden durch reaktive Systeme sehr gut adressiert, da reaktive Architekturen antwortbereit, widerstandsfähig, elastisch und nachrichtenorientiert sind.
In diesem Workshop werden die grundlegenden Muster von reaktiven Architekturen näher betrachtet und ein vollständiges System skizziert.
Zuerst werden die Grundzüge eines reaktiven Microservices anhand eines Beispiels vorgestellt.
Im Anschluss wird gezeigt, wie der Service mit anderen Microservices interagiert und die komplette Architektur hochverfügbar und global in mehreren AWS Regionen ausgerollt werden kann.
Jeder macht heutzutage Microservices - und es zeigt sich, dass auch Microservices nicht die Lösung aller Probleme sind. Dieser Workshop vermittelt, was Microservices bringen – bessere Modularisierung, eine Vielzahl technischer Vorteile, optimale Unterstützung für Continuous Delivery. Wir diskutieren dann die Nachteile, etwa erhöhte Komplexität, aufwändigerer Betrieb und Mehraufwand wegen der verteilten Kommunikation.
Schließlich erörtern mögliche Lösungen und alternative Ansätze, die immer noch die meisten der Vorteile bieten, aber Nachteile vermeiden. Um die Ansätze konkret zu illustrieren, werden wir beispielhafte Architekturen erarbeiten.
Manchmal muss es schnell gehen. Wir wissen noch nicht, ob unsere User ein Feature auch schätzen werden, das wir bauen. Also versuchen wir, in kurzer Zeit zu verstehen, was gebraucht wird, und es dann prototypisch zu entwickeln, um uns sofort Feedback abzuholen. Erst dann bauen wir das System in hoher Qualität.
In diesem Workshop gehen wir in der Gruppe in drei Stunden von der Idee über einen klickbaren Prototyp einer Smartphone-App bis zum Domain-Driven Design des zugehörigen Backends in Java.
Als Teilnehmer erfahren Sie, wie Sie durch intensive Zusammenarbeit mit dem User den Entwicklungszyklus abkürzen, Kosten sparen und mehr Spaß an der Entwicklung haben können.
JUnit 5 hat sich die Vision "The Future of Testing on the JVM" auf die Fahne geschrieben. Dazu gehört nicht nur, dass das betagte JUnit 4 als Test-Framework abgelöst werden sollte, sondern auch die Lösung des Grundproblems: Der Erfolg von JUnit 4 als Plattform, hat die Weiterentwicklung von JUnit 4 als Werkzeug verhindert.
Eine neue Architektur musste daher einen Spagat ermöglichen:
- Leichte Migrierbarkeit von JUnit 4 auf JUnit 5 und zukünftige Versionen
- Abwärtskompatibilität zu JUnit 4 und sogar 3
- Gute Integration mit IDEs, sowie mit Build- und Reporting-Werkzeugen
- Erweiterbarkeit auf unterschiedlichen Ebenen
- Modularer Aufbau, um nicht schon bei der Einführung von Java 9 wieder obsolete zu sein
- Möglichst wenige, am besten keine Abhängigkeiten zu anderen Bibliotheken
Herausgekommen ist eine Trennung zwischen konkreten "Test-Engines" und der "JUnit-Plattform". Im Workshop wird die bestehende Architektur mit ihren Vorteilen und Problemen vorgestellt und diskutiert. Im praktischen Teil können die Teilnehmer an ihrer eigenen JUnit-Erweiterung oder gar einer eigenen Test-Engine arbeiten.