oliverlorenz.com

Dieses ist der zweite Teil der Blog-Serie "Developer Open Space". Zuvor habe ich bereits allgemein über die Konferenz geschrieben. In diesem Teil möchte ich genauer auf den Workshop-Tag eingehen.

Das Schöne am Workshop-Tag ist, dass man tatsächlich nicht nur einen groben Überblick bekommt, sondern wirklich per Deep-Dive in ein Thema einsteigt und tatsächlich praktische Erfahrung sammelt. In meinem Fall habe ich mich im Vorhinein für den Workshop "Microservices in der Praxis" von Andreas Helmberger und Mike Bild entschieden, welcher mich in der Umsetzung und Dynamik sehr positiv überrascht hat.

Im Workshop "Mircoservices in der Praxis" ging es darum, über mehrere Teams hinweg eine Microservice-Architektur aufzubauen und einen kleinen Online-Shop live zu bringen. Eine nicht ganz kleine Aufgabe für einen Workshop von 8 Stunden Länge.

Bevor es richtig losging wurde uns eine kurze theoretische Einführung gegeben und die vorbereitete Infrastruktur gezeigt. Uns wurde ein vorbereiteter Docker-Container zur Verfügung gestellt, in dem eine NodeJS-Instanz lief, die wir nutzen konnten. Darüber hinaus gab es einen TravisCI, der das ganze dann in die Cloud deployed. Das hatte zum einen den Vorteil, dass wir sofort loslegen konnten, zum anderen haben wir damit das etwas lahmende WLAN zum Teufel gejagt, da alle breitbandintensiven Operationen in der Cloud stattgefunden haben. Großes Kompliment! Richtig gut und gleichzeitig praxisnah umgesetzt!

Der erste Teil des Workshops war am Anfang etwas holprig. Das lag aber mehr an den anwesenden Leuten als an den Speakern. Alle beschnupperten sich erstmal ein wenig. Wir diskutierten wie wir das ganze aufbauen wollten. Ich habe diesen Teil vor allem als Verständnisschärfung innerhalb der Gruppe für eine Microservice-Architektur wahrgenommen.

Ich persönlich habe die Diskussionszeit ein bisschen schleppend wahrgenommen. Man hätte an der Stelle meiner Meinung nach gern etwas flotter durch diese Diskussion gehen können. Das Thema war mir allerdings auch nicht ganz neu. Das Endergebnis war Schlussendlich sehr positiv. Ich hatte das Gefühl, dass jeder Workshop-Teilnehmer wusste was zu tun ist.

Nachdem wir festgelegt hatten wie wir die Services schneiden, haben wir Teams gebildet, die sich jeweils um einen Service kümmerten. In unserem Fall haben wir uns für folgenden Schnitt entschieden, um unseren E-Commerce-Shop auf die Beine zu stellen:

• UI-Service
• Produkt-Service
• Warenkorb-Service
• Order-Service
• Order-Notification-Service

Die Aufteilung der Teams ging schnell. Einzig und allein der UI-Service schien unter den Workshop-Teilnehmer nicht so beliebt zu sein. Um das Ganze voranzutreiben habe ich mich dafür entschieden diesen Teil zu übernehmen, worauf sich ein zweiter Teilnehmer anschloss.

Startschuss in die Praxis

Das wichtigste am Anfang war es, dass jeder deployen konnte. Zur Unterstützung wurde ein physisches Board erstellt wodurch angezeigt werden sollte, ob man bereits deployen konnte oder nicht.

Wie bei Microservices selbst, sind einige Absprachen notwendig um ein vernünftiges Service-Ökosystem auf die Beine zu stellen. Es müssen IP-Adressen, Protokolle und Formate definiert werden. Ich hatte den Eindruck, dass diese Diskussion sehr viel Zeit in Anspruch genommen hat und immer sehr dezentral verlaufen ist. Das Ergebnis war im Endeffekt, dass die linke Hand nicht wusste was die Rechte tut. Nichtsdestotrotz haben es alle Teilnehmer geschafft, ihren Service zu deployen.

Eine Microservice-Architektur ist ein lebendes Konstrukt. Vor allem als UI-Team, welches alle Services miteinander verbindet, standen wir immer wieder vor Problemen:

• Der anzuschließende Service war noch gar nicht vorhanden
• Der anzuschließende Service änderte "plötzlich" sein Format

Um diesen Problemen von Anfang an entgegen zu wirken, haben wir uns dazu entschieden in der ersten Version die entsprechenden Endpunkte zu mocken. Das hatte den Vorteil, dass wir nicht durch die anderen blockiert waren und uns nicht ständig anpassen mussten.

Somit waren wir in der Lage, bereits einen Produkt-Katalog anzuzeigen, wärend die anderen noch implementierten. Das Anschließen der Services haben wir dann einmalig an das Ende der Implementierung gesetzt.

Technisch war unser UI-Service eine Single-Page auf Basis von Twitter Bootstrap 3 und jQuery der über die REST-Endpoints der Services gefüttert wurde. Das entsprechende Repository kann hier eingesehen werden.

Die gesamten Repositories aller Teams sind hier zu finden.

Schlussendlich haben wir es zeitlich nicht geschafft alles zusammenzubringen. Macht aber nichts, denn ich glaube dass alle verstanden haben, worum es ging und wo die Herausforderungen lagen.

Die Speaker

Andreas und Mike haben ein super Team abgegeben. Während Andreas vor allem den technschen Teil übernommen hat, hat Mike vor allem die Rolle des Projekt-Managers eingenommen, was sich perfekt ergänzt hat.

Der Workshop war super vorbereitet! Man hatte von Anfang bis Ende das Gefühl, dass sie wissen wovon sie reden und auch schon eine gewisse Routine in der ganzen Thematik mitbringen.

Auf alle aufkommenden Fragen oder auftretende Probleme wurde eingegangen und diskutiert. Auf alles gab es eine Antwort, die uns als Workshop-Teilnehmer weiterbrachte!

Solltet ihr die Möglichkeit haben an einem Workshop der beiden Teilzunehmen: Macht es! Kann ich uneingeschränkt empfehlen!

Meine Learnings

Auch wenn es im Endeffekt dazu gefüht hat, dass wir insgesamt nicht fertig geworden sind, spiegele der Workshop die Herausforderung der Microservice-Architektur sehr gut wieder. Eine Microservice-Architektur ist from Scratch ein beherrschbares Konstrukt. Sobald es aber um Änderungen geht (und das tut es ja qausi immer), sollte man sich genau überlegen was man tut. Änderungen in einem Microservice können und werden dazu führen, dass andere abhängige Services kaputt gehen.

Besonders deswegen habe ich mitgenommen, dass man Microservices nur einsetzen sollte wo es tatsächlich notwendig ist. Microservices bieten auf der anderen Seite eine hohe Ausfallsicherheit, da - bei entsprechender Einrichtung - mehrere Instanzen parallel laufen können.

Die größte Herausforderung sehe ich bei der Microservice-Architektur in der Abstimmung der Services oder Teams untereinander. Wir haben im Worshop selbst fefstgestellt, dass zum Anfang elementare Absprachen gefehlt haben, die das Zusammenarbeiten schwierig gemacht haben. Ohne ein gewisses Regelwerk wird eine Microservice-Architektur im Chaos enden.

Fazit

Ein großartiger Workshop, in dem ich mein Wissen technisch vertiefen konnte, aber vor allem der Kommunikationsfaktor DAS Key-Learning war. Ich bin sehr froh, diesen Workshop gewählt zu haben, denn ich weiß jetzt welche Herausforderungen auf mich zukommen, wenn ich mich für eine solche Archiketur entscheide.

Insgesamt hätte ich mir ein bisschen mehr vordefinierte Regeln gewünscht. Zum Beispiel:

• Ein festgelegtes Commitment zum JSON-Format
• Eine festgelegte Notation der Keys in der Kommunikation
• (vielleicht sogar festgelegte Schemas)

Das hätte uns eine Menge Zeit und Implementations-Interationen gespart, wobei man prüfen müsste ob das Learning damit immernoch so effektiv gewesen wäre.

Der Workshop selbst war sehr abwechslungsreich, unterhaltsam und vor allem kommunikativ! Ich hatte sehr viel Spaß und habe viel gelernt, was ich nun in meinen Arbeitsalltag integrieren kann! Vielen, vielen Dank dafür!

Die Blogreihe

Im nächsten Teil meiner Blog-Reihe werde ich etwas zu den Spaces-Tagen erzählen. Dabei werde ich weniger etwas zu konkreten Spaces erzählen (das wird Teil 4) sondern eher auf den allgemeinen Ablauf bzw. deren Organisation an diesen Tagen erzählen.

{% include blog-posts-include/devopenspace.md %}