Suche
Highlights von der W-JAX 2018

Raus aus dem Microservices-Chaos, Event Storming, DDD: 7 Take-aways von der W-JAX 2018

Hartmut Schlosser, Marius Nied, Katharina Degenmann

© Shutterstock / Kim Reinick (modifiziert)

Microservices, Docker, Cloud oder lieber Angular, Agile und Arduino? Die Fülle an Themen auf der W-JAX 2018 ist riesig! Wir fassen hier kurz und knackig zusammen, was wir auf der W-JAX Neues gelernt und Spannendes gesehen haben. Wie immer erheben wir keinen Anspruch auf Vollständigkeit.

Take-away #1: Macht Chaos – Continuous Chaos!

Wie schaffen wir es, resiliente IT-Systeme zu bauen, die auch bei Teilausfällen noch funktionieren? Eine Methode auf dem Weg dahin stellte Russ Miles (ChaosIQ) in seiner Keynote vor: das Chaos Engineering.

Chaos Engineering basiert auf der Idee, bewusst Störungen herbeizuführen und aus den Effekten zu lernen. Das Ziel besteht nicht darin, möglichst robuste Anwendungen zu bauen, in denen Fehler nicht vorkommen. Stattdessen greift Murphy’s Law: Alles was schief gehen könnte, wird auch irgendwann schief gehen!

Bei resilienten Systemen besteht die Herausforderung darin, auch unvorhergesehene Probleme adäquat zu beantworten. Das Ziel ist nicht die Fehlervermeidung – denn Fehler sind in komplexen Systemen schlicht nicht auszuschließen –, sondern die schnelle Regenerierung.

Russ hat dazu geraten, das Chaos durch kleine Experimente in der Staging-Umgebung zu testen. Am Ende könnte eine Plattform stehen, in der solche Chaos-Experimente automatisiert und als integraler Bestandteil des Entwicklungsprozesses behandelt werden. „Denn Chaos ist eine dieser C-Disziplinen”, sagt Russ Miles: “Continuous Integration, Continuous Deployment, Continuous Chaos.“

Take-away hier: Fehler sind nicht (nur) dazu da, behoben zu werden, sondern (vor allem), um aus ihnen zu lernen!

Take-away #2: So kommt Ihr raus aus dem Microservices-Chaos!

Schon wieder Chaos. Dieses Mal das Chaos, das ein ausuferndes Microservices-Projekt hinterlässt. Denn die Flexibilität, die Microservices-Architekturen einführen, erkauft man sich bekanntlich mit einer erhöhten Komplexität des Gesamtsystems. Allzu leicht kommt ein einfach gestartetes Microservices-Projekt an einen Punkt, an dem die Übersicht verloren geht und man plötzlich vor der Mammutaufgabe steht, die vielen Komponenten des Systems irgendwie zu orchestrieren.

Um einen solchen “Service Mesh” in den Griff zu bekommen, hat Michael Hofmann (Hofmann IT-Consulting) zum Einsatz eines speziellen Werkzeugs geraten, wobei hier besonders Istio und Linkerd herausstechen.

Momentan sieht es so aus, als gewinne Istio das Rennen um das populärste Service Mesh Tool. Hinter dem Werkzeug steht eine mächtige Koalition aus IBM, Red Hat und Google, die daran arbeitet, Istio als Standard-Werkzeug für Kubernetes- und OpenShift-Installationen zu etablieren. Möglich sind mit Istio beispielsweise inhaltsbasierte Request Routings zwischen unterschiedlichen Versionen eines Microservices, Rate Limiting, die Auswertung von ACLs und die Sammlung der Telemetriedaten. Auch Themen wie Traffic Management, Service Discovery, Security, Policy Enforcement und Load Balancing werden abgedeckt.

Version 1.0 von Istio ist im August erschienen – somit ist der Startschuss für den Einsatz in Produktivsystemen gegeben. Hofmann ist dafür, das Tool so früh wie möglich im Entwicklungsprozess einzusetzen, damit einem im Microservices-Marathon nicht frühzeitig die Puste ausgeht.

Take-away #3: Event Storming – räumliche Nähe ist (noch?) unabdingbar

In Nicole Rauchs Session „Event Storming für Domain-driven Design“ ging es nicht darum, auf welche Weise man am besten durchs W-JAX-Event stürmt, um möglichst viele Sessions mitnehmen zu können, sondern vielmehr um die Methode Event Storming, die bereits Titelthema des Java Magazins 12.18 war.

Bei Event Storming geht es darum, ein gemeinsames (sprachliches) Verständnis zu schaffen, um Missverständnisse zwischen Fachbereich und Entwickler aus dem Weg zu räumen. Das Mittel der Wahl: Post-its, die Gedanken sichtbar und begreifbar machen. Daraus entsteht ein Modell, das mittels Event-Sourced-Implementierung einfach realisierbar ist.

Fast unabdingbar, so ergab eine Nachfrage aus dem Publikum, ist die räumliche Nähe von Fachbereich und Entwicklern. Ergo: Es fehlt eine digitale Lösung für Event Storming, die die Anwendung der Methode auch bei räumlichen Distanzen zwischen Entwickler- und Fachbereichsabteilungen ermöglicht. Bis diese entwickelt ist, funktioniert die Methode letztendlich nur bei räumlicher Nähe.

Take-away #4: Sieben ist die optimale Teamgröße

In Dr. Annegret Junkers Session „Von Design Thinking zu DevOps: Wie Sie den Produktgedanken in den Mittelpunkt stellen“ spielte nicht nur der namensgebende Produktgedanke eine wichtige Rolle, sondern auch und vor allem der (agile) Teamgedanke. Und hier kommt die seit Menschengedenken als mythische, heilige und ordnende (siehe Thema „Chaos“) Zahl empfundene Zahl Sieben ins Spiel. Denn: Psychologische Untersuchungen haben ergeben, dass ein Team unter sieben Personen zu klein ist, um sich gegenseitig befruchten zu können. Teams, die hingegen größer als sieben Personen sind, neigen zur Bildung von Untergrüppchen.

Zwar bestätigen Ausnahmen die Regel, aber bei der Teamerstellung und der Planung der Teamgröße sollte die Sieben durchaus berücksichtigt werden. Dann klappt’s wahrscheinlich auch mit der Agilität und der Zentrierung auf den Produktgedanken, wobei natürlich auch noch ein paar andere Faktoren eine Rolle spielen…

Take-away #5: DevOps ist viel mehr als Devs + Ops

…zum Beispiel DevOps. Das Buzzword ist in letzter Zeit zwar immer häufiger in den Medien und der Literatur präsent. Nichtsdestotrotz wird es bisher nicht verbreitet eingesetzt. In ihrer Session zeigten Frank Frock und Peter Wurbs, wo die Stolpersteine bei der Implementierung von DevOps liegen können.

Um DevOps erfolgreich einzuführen, helfen die vier Säulen Kultur, Methodik, Architektur und Werkzeuge. In der Kultur liegt der Schlüssel zu DevOps. Disruptive Transformation und die Organisation von cross-funktionalen Teams sind dabei nur zwei Stichworte, die fallen. DevOps funktioniert nicht mit Wasserfall und Meilensteinen.

Werkzeuge unterstützen allenfalls den kulturellen Wandel. DevOps-Toolchains sollten gemeinsam, unter mehreren Teams, zu nutzen. Für jedes Projekt eine Tool-Chain zu erstellen, ist eher schädlich als hilfreich. Auch Unabhängigkeit ist für DevOps notwendig, und daher bieten sich Cloud-Services als Basis einer Tool-Chain an. Bezogen auf die einzelnen Baustellen und die verschiedenen mitwirkendes Teams, gibt es ein nachvollziehbares Fazit für alle: DevOps meint nicht, einfach Devs und Ops zusammenpacken. Vielmehr gilt: Immer auch das große Ganze sehen!

Take-away #6: Knigge für Software-Architekten

Gleich zu Anfang machte Gernot Starke klar: „Das wird keine angenehme Session“. Software-Architekten sollen davor bewahrt werden, das zu tun, was sie besser nicht tun sollten. Nur so erreicht man bessere Software-Architektur und eine produktivere Zusammenarbeit in Teams. Da Verhalten die Qualität bestimmt, gab Starke Knigge-Regeln für Software-Architekten an die Hand.

Neben proaktivem Verhalten, im Sinne von „aktiv auf die Stakeholder zugehen“, wird auch zu einem Perspektivwechsel geraten, externe Schnittstellen lautet das Stichwort. Gewarnt wurde hingegen vor „Notationskriegern“, die die Form über den Inhalt stellen. Auch der „Krise-Simplizist“ ist zu vermeiden, da er oft das tut, was er kann, aber nicht das, was notwendig ist.

Im Grunde geht es bei Software-Architekten um das richtige Weglassen und das nützliche Hinzufügen. Letztendlich ist ein Software-Architekt nichts anderes als ein Jongleur, der mit verschiedenen Bällen wie Performance, Kosten, Sicherheit, Verständlichkeit usw. jongliert. Konzentriert er sich zu viel auf einen Ball, werden die anderen Bälle hinunterfallen, jongliert man mit zu vielen Bällen, kommt man ins Schleudern.

Take-away #7: Verschiedene Tools schaffen Produktivität

Oftmals scheitern Agile, DevOps oder InnerSource in Unternehmen an der Chef-Etage. Mit dieser These eröffneten Lilli Seyther-Besecke und Johannes Nicolai ihre Session. Was man dagegen tun kann? Zahlen sprechen lassen, genauer gesagt, das Budget. Wie zahlreiche Beispiele aus der Praxis zeigen, sind glückliche Entwickler produktiver – was letztendlich auch dem Unternehmen zugute kommt.

Für Developer Happiness können unter anderem kreativer Freiraum sowie unterschiedliche Tools sorgen. Entwickler sollten die Möglichkeit haben, autonom zu arbeiten. Aber auch in der Verwendung unterschiedlicher Tools liegt der Schlüssel für Mitarbeitermotivation. Die goldene Regel ist eigentlich einfach umzusetzen: Autonomes Arbeiten und neue Tools machen Entwickler zufrieden, und zufriedene Entwickler sind produktiver.

API Summit 2018
Christian Schwendtner

GraphQL – A query language for your API

mit Christian Schwendtner (PROGRAMMIERFABRIK)

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Marius Nied
Marius Nied
Marius Nied ist Redakteur des Java Magazins.
Katharina Degenmann
Katharina Degenmann
Katharina Degenmann hat Politikwissenschaft und Philosophie studiert. Seit Februar 2018 arbeitet sie in der Redaktion der Software & Support Media GmbH und ist nebenbei als freie Journalistin tätig.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: