oliverlorenz.com

[feed] [twitter] [xing] [linkedin] [github]

Dieser Blog ist nicht kaputt.

2015-10-28

Developer Open Space - Der Workshop Tag

Dieses ist der zweite Teil der Blog-SerieDeveloper 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:

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:

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:

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.

Developer Open Space 2015

Was ist das?

Der Developer Open Space ist eine Unkonferenz. Das schöne an Unkonferenzen ist, dass vorher nicht bekannt ist zu welchen Themen es überhaupt Talks geben wird. Und: Jeder ist dazu angehalten etwas beizutragen oder aktiv Themen anzustoßen über die man mit anderen ins Gespräch kommen möchte.

Was für einige Leute abschreckend und unkonkret klingt, fördert meiner Meinung nach die Kommunikation und zieht einen besonderen Typ Mensch an, was mir sehr, sehr angenehm war.

Ich möchte in dieser kleinen Blog-Reihe einen kleinen Einblick geben, wie ich diese Konferenz wahrgenommen habe und warum der Developer Open Space für mich nächstes Jahr definitiv ein Pflichtveranstaltung ist.

Organisation

Die Konferenz selbst fand in einem Tagungshotel Namens “Commundo Tagungshotel” in Leipzig statt, welches sich sehr gut für dieses Event eignete. Parkplätze waren ausreichend vorhanden, ebenso war es möglich direkt Hotelzimmer zu beziehen. Wir hatten insgesamt 7 Räume verschiedener Größe zur Verfügung. Das Rundum-Sorglos-Paket aus der Feder des Torsten Weber.

Torsten ist dieses Jahr alleiniger Organisator gewesen. Wie ich gelernt habe ist das aber nach acht Jahren Developer Open Space die Ausnahme und hat sich im Endeffekt nicht anders ergeben. Ich habe Torsten wieder als Innovator wahrgenommen, der das Talent hat Dinge einfach zu delivern, die Zügel an den entsprechenden Stellen straff zu halten und trotzdem eine gewisse Leichtfüßigkeit und Gelassenheit an den Tag zu legen. Anders hätte man dieses Event wohl auch nicht auf die Beine stellen können. Einen besonderen Dank an dieser Stelle an ihn!

Aufbau der Konferenz-Tage

Die Konferenz teilt sich in zwei Grundlegend unterschiedliche Teile.

Der erste Tag ist ein ist ein Workshop-Tag. Das heißt in diesem Fall, dass ein oder mehrere Coaches einen Workshop vorbereiten und mit den zuvor angemeldeten Teilnehmern durcharbeiten. Da geht es von Agile-Themen oder reinen Kommunikationsthemen bis in in tiefe Technologie-Topics. Das klare Motto dieses Tages ist Mitmachen und Deep-Dive!

An den anderen zwei Tagen werden in einer mehr oder minder festen Timeline so genannten “Spaces” abgehalten. Spaces sind nicht definiert. Es kann ein klassischer Talk sein, ob vorbereitet oder nicht. Eine Diskussionsrunde, ein Erfahrungsaustausch, oder eine Art Workshop im Kleinen Maßstab sein. Der Phantasie sind keine Grenzen gesetzt! Ebenso ist es möglich einfach zu sagen, dass man an einem bestimmten Thema Interesse hat.

Zum ersten Mal da?

Leuten die das erste mal da sind möchte ich ans Herz legen: Seid offen. Es ist ein Open Space. Lasst euch treiben und kommt ins Gespräch! Keiner beißt und die meisten der anderen Nerds haben noch viel mehr Angst vor euch als ihr vor ihnen ;) Ein Guter Ort dafür war mal wieder der “Snack-Raum”. Ich habe ihn liebevoll das Füllhorn getauft: Denn gefühlt hat man einen Keks rausgeholt und es wurden drei nachgelegt. Unglaublich!

Die Blogreihe

Nun habe ich zu den eigentlichen Themen noch garnicht viel gesagt. Es ist aber auch so viel zu sagen! Deswegen habe ich mich entschieden das ganze Aufzuteilen.

In meinem nächsten Teil meiner Blog-Reihe werde ich etwas zu dem Workshop-Tag und meiner persönlichen Erfahrung zu diesem Tag schreiben.