Konferenz-Logbuch: BEDCon 2018

Bei der diesjährigen BEDCon ist synyx gleich doppelt vertreten gewesen. Nicht nur der Talk “Observability in einer Microservice Welt” von Andreas Weigel (@aendi) und Jakob Fels (@JakobFels) war dieses Mal eine Premiere. Auch unser Stand im Messe-Bereich der Konferenz hat das erste Mal zu Gesprächen, Diskussion und natürlich jede Menge synyx Stickern eingeladen.

Thomas Kraft am Bedcon Stand
Zwar nicht der größte Stand, dafür aber komplett in der Bahn transportiert.

Unsere Reisegruppe von insgesamt fünf synyxern und Jakob war zwar in allen belangen bestens auf die Konferenz vorbereitet (z. Bsp. waren alle Folien für den Talk bereits VOR der Abreise fertig) nur bei der getränketechnischen Versorgung war wohl etwas knapp kalkuliert worden, sodass am Ende auch das Boardbistro nur noch mit leeren Kästen da stand.

Getting started Bedcon
Gut vorbereitet aber was fehlt?

Immerhin konnte eine vermeindlich kaputte Zapfanlage, der Techniker war bereits informiert, wieder in Gang gebracht werden, sodass wir relativ entspannt in Berlin ankamen und einen ruhigen ersten Abend mit vietnamesichen Essen und kleineren Arbeiten am Talk verbrachten.

Feilen bis zur letzen Minute
Feilen bis zur letzen Minute

Talks

Observability in einer Microservice Welt

#somethingwithbananas
#somethingwithbananas

Der erste Konferenztag startete gleich mit einen Höhepunkt der zwei Tage. Direkt im ersten Slot starteten Andi und Jakob mit ihrem Talk zum Thema Observability. Die Migration bei dm-drogerie markt zu einer verteilten Systemarchitektur hat viele Herausforderungen nach sich gezogen. Neben vielen Einblicken in die tägliche Arbeit und Erkenntnissen durch den DevOps-Kulturwandel, wurden die Themen Logging, Metriken und Tracing vorgestellt. Dabei kam der visuelle Part nicht zu kurz. Die Folien von @schdaff führten nicht nur wie ein roter Faden durch das Thema, sondern machten den Talk auch noch sehr anschaulich und unterhaltsam.

Kernaussagen

  • Unterscheidung zwischen verschiedenen Sichten auf verteilte Systeme mit Logging, Metriken und Tracing
  • Livedemo mit entsprechenden Umsetzungen:
    • Logging via Logstash in Elastic Search und Visualisierung mit Kibana
    • Metriken mit dem Micrometer Framework als Metrikenfassade und Influx und Grafana zur Speicherung und Visualisierung
    • Tracing mit Spring Cloud Sleuth und Zipkin
  • DevOps-Kulturwandel bringt Chancen zur Verbesserung der Zusammenarbeit: Weg von Schuldzuweisungen hin zu verantwortungsbewussteren Handeln.

Offline First – kein Netz, kein Fehler, zufriedene Nutzer

Viele Webanwendungen glänzen nicht gerade wenn es um ihre Offline-Fähigkeit geht. Direkt von Anfang an bei der Entwicklung auch Nutzer ohne oder mit sehr schlechter Verbindung etwa bei Usability Fragen mit zu beachten, liegt oft genug nicht im Projektscope. Genau darum ging es bei “Offline First – kein Netz, kein Fehler, zufriedene Nutzer” von Ulrich Deiters, der damit viele wichtige Grundsätze und Denkanstöße lieferte.

Disconnected-Dino

Die Nutzererwartung ist dagegen ganz klar – solange die Anwendung keine klare Aussage zum aktuellen Netzwerkzustand liefert, ist man eher enttäuscht wenn etwa der formulierte Tweet auf Grund von Timeouts oder anderen Fehlern im Nirvana verschwindet. Anhand von vielen teils auch sehr amüsanten Beispielen wurde einem schnell klar wie oft man sich in die Zone begibt, in der der Endnutzer recht verärgert die App schließt und oder am liebsten deinstallieren würde. Aber auch CAP und der die damit verbundene Partition Tolerance kam im Talk nicht zu kurz und wurde nochmal näher beleuchtet, sowie Fallstricke aufgezeigt, in die man laufen kann wenn der Client keine Verbindung hat.

Ansätze zum Handeln

  • Zeitstempel der letzten Änderung der Daten bzw. der letzten Synchronisation anbieten, dadurch ist der Nutzer in der Lage die Datenqualität und -aktualität besser einschätzen zu können.
  • Klare Aussage über den aktuellen Zustand der Netzwerkverbindung treffen, nicht unbedingt nur wenn der Nutzer offline ist.
  • Lokale Datenbank/Caches können einem über so manche Verbindungsunterbrechung retten auch wenn dann vielleicht nicht alle Daten konsistent sind. Hier gilt es abzuwägen.

Das Credo

“Kein Netz” ist nicht zwingend ein Fehler!

Self-Contained Integrationstests mit Docker und Testcontainers

Wer kennt es nicht, die lokale Datenbankinstallation hat wieder mal nicht die Migration beim Initialisieren des Integrationstests überlebt. Oder aber man möchte möglichst mit echter Datenbankanbindung testen da die Implementierung sehr vom jeweiligen Datenbanksystem abhängt und nicht durch eine In-Memory Datenbank umgesetzt wird. Ein weiteres Einsatzgebiet sind UI Tests die beispielsweise mit Selenium Tests durchführen und ebenfalls ein spezielles Testsetup benötigen. An dieser Stelle sind die in “Self-Contained Integrationstests mit Docker und Testcontainers” von Michael Vitz vorgestellten Testcontainers ein sinnvoller Ansatz um die Herausforderung zu meistern.

Das Konzept der Testcontainer basiert auf Docker Containern die sich als JUnit Rules in den Testcode integrieren lassen. Dabei bieten sich auch die Möglichkeit komplett eigene Container bzw. Setups zu nutzen. Für viel verwendete Fälle gibt es zusätzlich dedizierte Abstraktionen die das Handling vereinfachen:

  • mysql, postgresql oder oracle-xe
  • selenium
  • nginx

Test the Architecture

Tests können auf ganz unterschiedliche Aspekte der Software abzielen. Ein oft, vielleicht auch in Zeiten von Microservices, vernachlässigter Teil ist die Architektur bzw. das einhalten, von beim Projektstart getroffenen Architekturentscheidungen. An dieser Stelle setzt der Talk “Test the Architecture” von Dennis Rippinger an und zeigt Möglichkeiten wie man getroffene Entscheidungen nachhaltig automatisiert festzuhalten.

Während des Talks wurden anhand von Code Beispielen verschiedene Tools vorgestellt die Architekturen in Regeln und Tests gießen lassen:

  • Degraph: Visualisierung von Klassen und Package Strukturen mit Junit Testing Support Bietet allerdings nur Layer-basiertes Testing und hat durch den Scala Background weniger Fokus auf Java.
  • jqAssist: Bietet auch die Möglichkeit der Visualisierung ähnlich wie Degraph. Im Talk wurde gezeigt das auf Basis der Graphen eine Graphdatenbank (Neo4J) befüllt werden kann. Darauf aufbauend können dann in der Cypher Query Language (Querylanguage der Neo4J Datenbank) Tests schreiben.
  • ArchUnit: Dieses Framework bietet die ebenfalls die Möglichkeit zum Testen der Architektur in Unittests. Dabei können zum Beispiel Zugriffe zwischen Packages klar abgetestet werden.

Danke für die vielen Beispiele die dazu auf GitHub zu finden sind.

Wie werde ich ein erfolgreicher Software-Architekt?

Es gehört wohl mehr dazu gute Softwaredesignentscheidungen zu treffen als nur die neuesten Buzzwords von Konferenzen in das eigene Projekt einfließen zu lassen. Genau darum ging es im Vortrag “Wie werde ich ein erfolgreicher Software-Architekt?” von Eberhard Wolff, in dem die Rolle des klassischen Softwarearchitekten mit einer moderneren Interpretation anhand von unterschiedlichen Aspekten vorgestellt wurde.

Generische Architekturaspekte wie

  • Saubere Architektur und hohe Code Qualität
  • Skalierbarkeit
  • Favorisiertes Framework/Sprache

lösen generell erstmal keine Probleme.

Es geht viel mehr darum technische Expertise im Team zu nutzen und zu fördern statt die Expertise und damit die Entscheidung bei einer Person zu halten. Entsprechend nimmt der Architekt eher eine moderierende Rolle ein da die Entscheidung im Team getroffen wird. Im Talk wurde dieser Aspekt auch mit dem Bild eines kollaborativen Gesellschaftsspiel verglichen da durchaus ähnliche Aspekte Rolle spielen:

  • Keiner kann alleine gewinnen
  • Jeder übernimmt eine gewisse Rolle
  • Gute Kommunikation ist eine sehr wichtige Komponente

Das Fazit des Talks

“Aufgabe eines Architekten ist es kontinuierlich Entscheidungen ohne genug Informationen zu treffen”

Dabei gilt:

  • Die besten Entscheidungen sind solche die man später treffen kann
  • Oft können Entscheidungen nur auf Grundlage von wenig oder unzureichender Informationslage getroffen werden und das ist auch OK so.

Aus meiner Sicht brachte der Talk zwar wenig wirklich neue Erkenntnisse stattdessen war er eine klare Bestätigung von vielen Erfahrungen und Werten die wir bei synyx in der täglichen Arbeit erleben und fördern.

Fazit

Die diesjährige BEDCon hat sich in allen belangen gelohnt. Nicht nur wegen den vielen wirklich guten Vorträgen, sondern auch die synyx & Jakob Reisegruppe eilte von einer Überraschung zur nächsten. So gab es für drei von uns tolle Preise zu gewinnen! Zwar waren auch zwei Trostpreise dabei, aber hey immerhin wars kein jQuery-Buch! Und auch wenn die parallel laufende “Lack & Leder”-Konferenz nicht zwingend bei jedem den Geschmack getroffen hat, trug sie zur allgemeinen Heiterkeit der Truppe bei 😉

In diesem Sinne:

Code-with-Attitude-Bier