Im September habe ich mit meinem Kollegen Olli Kracht an der SEACON digital 2020 teilgenommen, meiner ersten voll digitalen Konferenz, 100% remote. Obwohl das vollständig remote Arbeiten für uns schon seit einer Weile selbstverständlich und eigentlich gar nichts besonderes mehr ist, war ich doch gespannt, wie es sich auf eine Konferenz auswirken würde, da zuvor viele Veranstalter kalt erwischt wurden und so manche Veranstaltung gänzlich abgesagt wurde.
Remote-Konferenzen
Das Konferenztool und die Technik haben eigentlich sehr gut funktioniert, die Tech-Admins haben da sicherlich einen guten Job gemacht. Für alle Teilnehmer empfiehlt sich auf jeden Fall eine kabelgebundene Internetverbindung, ein ordentliches Headset und eine gute Webcam. Die Open Spaces habe ich als eher zäh wahrgenommen, bei den Workshops hat es besser geklappt. Die übrigen Beiträge lassen sich abgesehen von einigen Pecha Kucha am ehesten als Webinare charakterisieren, wobei jeder Beitrag von einem Beiratsmitglied moderiert wurde. Die Sprecher haben dann zumeist 20 Minuten referiert und anschließend rund 10 Minuten moderiert Fragen der Teilnehmer beantwortet. Im Anschluss an eine Session bestand zudem die Möglichkeit, in einer virtuellen Coffee Lounge in direkteren Austausch mit Kameras auf beiden Seiten zu treten. Gerade bei den Coffee Lounges ist es dann am ehesten zu den berühmt-berüchtigten Hallway Tracks gekommen, wobei die Hemmschwelle in digitalen Formaten schon spürbar höher ist, als bei einem On-Site-Event: die anderen Teilnehmer sind einfach nicht so nahbar.
Ein schöner Nebeneffekt der digitalen Konferenz ist sicherlich, dass es deutlich mehr Teilnehmer (rund 500) gab, da für alle die Kosten niedriger sind und man auch schnell mal zwischen Terminen für ein oder zwei Sessions, die einen besonders interessieren, reinspringen und dann auch schnell wieder rausgehen konnte. Bei einer on-site-Konferenz musste man sich ja immer gleich mehrere Tage komplett blocken, Hotel und An-/Abreise organisieren. So gesehen war das ganze schon komfortabel und so mancher Teilnehmer wird sicherlich von der gemütlichen und sicheren heimischen Couch dabei gewesen sein. Warum auch nicht!
Sozio-technische Systeme
Die SEACON beschäftigt sich, wie der Name schon vermuten lässt, vornehmlich mit Themen aus dem Software Engineering und der Software Architektur. Am meisten konnte ich mich bei der diesjährigen Ausgabe mit dem Beitrag „Alles hängt zusammen – über das Wechselwirken von Architektur, Teams und Organisation“ von Moritz Friedheim identifizieren. Am Beispiel von FFG FINANZCHECK hat er wunderbar nachvollziehbar dargelegt, dass man durch konsequentes zu Ende denken von Conway’s Law nur dann ernsthaft Software Architektur entwerfen kann, wenn man zugleich auch Organisations- und Teamentwicklung betreibt. Denn diese Aspekte gehören unweigerlich zusammen. Software interagiert heute immer mehr mit Individuen, Nutzergruppen, teilweise ganzen Gesellschaften und wird dabei zunehmend nicht mehr von einzelnen, sondern von zumeist mehreren Teams innerhalb einer Organisation entworfen und entwickelt. Und die Organisation, innerhalb derer die Software entsteht, bestimmt die Software nun einmal entscheidend mit – ob wir wollen oder nicht!
Microservices
Entgegen aller Abgesänge waren Microservices auch auf der SEACON wieder eines der beherrschenden Themen. Obwohl man zuletzt immer mehr den Eindruck gewinnen musste, dass der Trend eher wieder von Microservices weg geht und in vielen Fällen abgeraten wird, scheinen sich in der Zwischenzeit viele Organisationen für diese Form der Softwarearchitektur entschieden zu haben und haben auch bei der SEACON ihre Erfahrungen und Probleme geteilt.
Ein gutes Beispiel für eine der vielen kritischen Stimmen mit Blick auf Microservices ist der Beitrag „Microservices sind nicht die Antwort auf alle Fragen“ von Annegret Junker, in dem sie aufzeigt, dass Microservices schnell heikel werden können, wenn zum Beispiel das Netzwerk zwischen den Services nicht höchst zuverlässig ist, oder Daten über mehrere Dienste hinweg konsistent persistiert werden müssen (eventual consistency). Zudem handelt man sich die hohe Komplexität eines verteilten Systems ein, der man mit Deployment-Monolithen („Modulithen„) begegnen kann. In diesem Fall kann man dann nicht mehr wirklich von einem Microservices-System sprechen, sondern eher von einer hybriden Architektur.
Auch Eberhard Wolff hat in seinem Beitrag darauf hingewiesen, dass sich gezeigt hat, dass Microservices oftmals gar nicht in Reinform eingesetzt werden, da wie so oft Green Field Projekte nach wie vor eher die Ausnahme als die Regel sind. Viel mehr findet man sie als Ergänzung von bestehenden Architekturen vor, zum Beispiel, um es sich zu ermöglichen, in einem „Big Ball Of Mud“ noch Features umsetzen zu können. Eine schrittweise Migration unter Berücksichtigung von Bounded Contexts aus dem Domain-Driven-Design kann hier durchaus sinnvoll sein.
Microservices: eine Success Story der Deutschen Bahn
Dass eine reine Microservices-Architektur sehr wohl beherrscht und auch in der Praxis stabil und zuverlässig betrieben werden kann, haben mein Kollege Olli Kracht und ich in unserem Erfahrungsbericht zu einem großen Microservices-System mit mehr als 60 Microservices geteilt. In unserem Erfahrungsbericht haben wir geschildert, wie es gelungen ist, dieses hochverteilte System mit mehreren Teams gemeinsam zielorientiert zu entwickeln und wie wir die Landschaft mit allen Tücken von verteilten Systemen wie Nebenläufigkeit, verteilten Transaktionen, Aufruf-Kaskaden, zentralisiertem Logging, Tracing usw. erfolgreich betreiben. Insbesondere gelingt es uns, mit dem DevOps-Mindset mit geringer Lead-Time schnell auf Incidents zu reagieren.
In dem Beitrag haben wir versucht, auf verschiedenen Flugebenen zu erläutern, weshalb wir uns überhaupt für eine Microservices-Architektur entschieden haben und welchen Herausforderungen wir damit wie begegnet sind.
Unser Beitrag ist übrigens so wie alle anderen Beiträge der diesjährigen SEACON digital weiterhin online über das Konferenztool einsehbar – ein weiterer schöner Nebeneffekt einer digitalen Konferenz.
