Microservices Praxisbuch

Lucas Dohmen: Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcast. Heute habe ich Eberhard zu Gast. Hallo Eberhard.

Eberhard Wolff: Hallo Lucas.

Lucas Dohmen: Wir wollen heute noch einmal über Microservices sprechen und zwar auch über das “Microservices-Praxisbuch” - aber erst einmal, wer bist du eigentlich, Eberhard?

Eberhard Wolff: Mein Name ist Eberhard Wolff und ich bin Fellow bei der INNOQ. Das heißt, ich mache im wesentlichen Training, Consulting und Vorträge und schreibe auch Bücher und Artikel. Der Schwerpunkt ist im Moment Microservices, aber generell auch modernere Technologien und Vorgehensweisen, beispielsweise Continuous Delivery, NoSQL und solche Sachen.

Lucas Dohmen: Du hast schon einmal ein Buch zu Microservices geschrieben, richtig?

Eberhard Wolff: Ja, genau so ist es.

Lucas Dohmen: Warum hattest du jetzt Lust noch ein Buch zu Microservices zu schreiben? Was hat in dem alten Buch gefehlt?

Eberhard Wolff: Das erste Buch ist ein Architekturbuch. Also es spricht sehr viel darüber, warum man Microservices machen sollte, worauf man achten muss. Gerade bei architekturellen Themen, welche organisatorischen Rahmenbedingungen und Auswirkungen es hat. Es gab ein sehr kurzes Kapitel über Technologien und ich hatte das Gefühl, dass sich einige der Leser noch etwas mehr Inhalt über konkrete Technologien und Technologieeinsätze gewünscht hätten. Das ist genau der Grund, warum ich dann das Microservices-Praxisbuch geschrieben habe. Als Ergänzung, die sich darauf fokussiert: Wie mache ich das? Also weniger als warum mache ich das und das große Bild, sondern wie man Microservices konkret technisch umsetzen kann.

Lucas Dohmen: Wenn ich mir das Cover von dem Buch anschaue, dann wirkt es wie eine “Rezeptmetapher”. Wo kommt diese Metapher her?

Eberhard Wolff: Ja, genau. Ursprünglich war die Idee, das Buch zu einem Microservices-Kochbuch zu machen. Die Idee der Rezepte ist, dass man, ähnlich wie wenn man ein Menü kocht, verschiedene Rezepte, verschiedene Technologien kombinieren muss, um ein Microservices System zu bauen. Das heißt, das Buch diskutiert bestimmte einzelne Rezepte und es liegt dann am Autor oder am Leser, daraus ein eigenes Menü zusammenzustellen und vielleicht auch die Rezepte, Technologien und den Einsatz der Technologie zu variieren, um dann am Ende bei dem einen Menü, bei dem einen System rauszukommen, was der Leser tatsächlich umsetzen will und was in seinem speziellen Kontext den größten Sinn macht.

Lucas Dohmen: Das klingt doch gut. Es gibt also nicht genau ein Rezept für ein großes Menü, sondern viele kleine Rezepte, aus denen man ein eigenes Menü komponieren kann.

Eberhard Wolff: Genau so ist die Idee.

Lucas Dohmen: Wenn du sagst, dass es praxisrelevanter ist, ist dann die erste Frage, die ich dir stellen sollte, welche Technologien man für einen Microservice braucht oder ist das eine schlechte Frage?

Eberhard Wolff: Es geht in dem Buch tatsächlich um Technologien und da ist die Frage: Was sind denn Technologien, die man für Microservices braucht? Die Antwort, die glaube ich häufig gegeben wird ist, wenn ich einen Microservice brauche, brauche ich irgendein Framework um den konkreten Microservice umzusetzen. Und ich finde es ein bisschen komisch, denn einer der Vorteile von Microservices ist ja gerade der, dass ich die konkreten Implementierungstechnologien in den Microservices variieren kann. Sicher muss ich irgendeine Implementierung wählen; Ich muss mich für eine Programmiersprache entscheiden; Ich muss mich für ein Framework entscheiden. Aber die Technologieentscheidungen, die tatsächlich das Gesamtsystem betreffen, das sind die, die die Kommunikation der Microservices untereinander betreffen und auch Technologien zum Betrieb der Microservices. Betrieb kommt, aufgrund der vielen Microservices, die ich in solchen Systemen habe im Vergleich zu einem Deployment-Monolithen, eine viel größere Bedeutung zu. Das sind also Themen, die man beachten muss: Technologien für Kommunikation und für den Betrieb. Das sind Technologieentscheidungen, die man treffen muss, die man einmal für das gesamte System trifft, und dann die konkreten Umsetzungen in den verschiedenen Microservices. Die Frameworks dort, das ist gerade das, was ich variieren kann. Deswegen macht es eigentlich nicht so viel Sinn, sich auf die Frameworks zu fokussieren, mit denen man die einzelnen Microservices schreibt.

Lucas Dohmen: Und wenn wir über Kommunikation sprechen, dann muss man über synchron und asynchron sprechen. Was würdest du da bei einer Microservices Architektur vorziehen?

Eberhard Wolff: Ich glaube, dass man mit einer asynchronen Kommunikation besser dasteht. Letztendlich ist es ein Trade-Off. Der Vorteil asynchroner Kommunikation ist, wenn der Kommunikationspartner, mit dem ich spreche, nicht da ist, weil das System gerade ausgefallen ist oder aus welchen Gründen auch immer. Dann bekomme ich bei einer asynchronen Kommunikation nur eine Latenzzeit, das heißt, ich schicke dem Service eine Nachricht. Ich sage zum Beispiel: “Schreib' mal bitte eine Rechnung.” Es dauert dann irgendwie länger bis die Rechnung geschrieben wird, aber das ist nicht weiter schlimm. Bei einer synchronen Kommunikation habe ich den Vorteil, dass ich eher aktuelle Daten bekomme. Ich könnte zu einem Kundenservice gehen und sagen: “Gib' mir mal bitte die Information über den Kunden.” Und ich bekomme die aktuellen Informationen über den Kunden. Dafür müsste ich mich damit beschäftigen, was ich mache, wenn ich auf den Service, der Kunden verwaltet, gerade nicht zugreifen kann.

Bei einer asynchronen Kommunikation könnte ich so auf einen Kundenservice gar nicht zugreifen, da müsste ich die Daten wahrscheinlich replizieren und das ist auch der Nachteil: Ich müsste bei asynchroner Kommunikation Datenreplikation in Kauf nehmen, aber dafür habe ich dort eine höhere Resilienz, eine höhere Ausfallsicherheit.

Dazu kann man jetzt noch ein paar Sachen hinzufügen. Ich glaube, dass synchrone Kommunikation sehr populär ist, weil es einfach zu verstehen ist. Wir sind gewohnt lineare Programmabläufe zu schreiben, und wenn ich synchron kommuniziere, sind Teile dieses linearen Programmablaufs irgendwie auf einem anderen System. Das ist also nichts überraschendes für einen Entwickler, aber am Ende bekommt man eine große Komplexität, weil diese Aufrufe fehlschlagen können, länger dauern können und abgesichert sein müssen und so weiter. Ich glaube, das ist der Grund, warum es so populär ist, aber es ist ein Weg, der bei größeren Systemen zu echten Schwierigkeiten führen kann. Die andere Sache ist, wenn man sich die architekturellen Ansätze zusammen mit Datenreplikation anschaut, spricht man bei Microservices auch von “Domain-driven-Design” oder “Bounded-Context”. Jeder Microservice hat sein eigenes Domänenmodell, das bedeutet, dass vielleicht so etwas wie Kundendaten zu replizieren gar nicht wirklich notwendig ist, sondern in Wirklichkeit will der eine Service dem Kunden nur eine Rechnung schicken und benötigt dafür beispielsweise die Information “Rechnungsadresse” vom Kunden. Ein anderer Service will dem Kunden die Ware schicken und braucht dafür die Lieferadresse - das sind zwei unterschiedliche Darstellungsweisen des Kunden, also das Replikationsthema zusammen mit Bounded-Context ist gar nicht so schlimm, wie es sich anfangs anhört.

Lucas Dohmen: Es gibt sicherlich Situationen, in denen synchrone Kommunikation unvermeidbar ist, oder?

Eberhard Wolff: Da bin ich mir gar nicht so sicher, ich will jetzt nichts ausschließen. Am Ende ist es so, wenn mehrere Systeme hohe Anforderungen an konsistente Daten haben. Beispielsweise will ich eine Rechnungsnummer haben und jede Rechnungsnummer darf nur einmal vergeben werden und muss aufsteigend sein. So etwas kann ich nur realisieren, indem ich einen zentralen Service habe, der solche Rechnungsnummern vergibt und auf den mehrere Systeme zugreifen. Ob so etwas wirklich unvermeidlich ist? Man könnte so argumentieren, dass so ein Service dann eher darauf hinweist, dass das Schreiben der Rechnungen auf zu viele Services verteilt ist und deswegen das Problem erst existiert, weil man auf architektureller Ebene nicht sauber getrennt hat.

Lucas Dohmen: Also würdest du sagen, dass die Notwendigkeit, synchron zu kommunizieren, eine Art “Architektur-Smell” ist, also wie ein Code-Smell, nur auf Architekturlevel?

Eberhard Wolff: Das könnte ein Hinweis darauf sein, ja. Insgesamt ist es nach meinem Empfinden so, dass synchrone Kommunikation auch überbenutzt wird. Viele Leute denken bei Microservices direkt an REST-Services - es gibt auch große Systeme, die genau so gebaut sind, aber ich habe ganz bewusst deswegen diese Art der Kommunikation im Buch nach hinten gestellt um zu sagen, das ist nicht das, was man typischerweise machen sollte, sondern das ist etwas, was man eher vermeiden sollte und typischerweise eher ein schlechter Trade-Off: Man muss sich mit dem Ausfall der Systeme und hohen Latenzzeiten beschäftigen, die dort möglicherweise auftreten könnten und so weiter. Genau aus dem Grund habe ich das nach hinten gestellt und um mich davon abzuheben, was der Leser vermutlich schon als Vorurteil mitbringt. Dem möchte ich widersprechen und aufzeigen, dass asynchrone Kommunikation vielleicht der bessere Weg sein könnte.

Lucas Dohmen: Wenn ich jetzt asynchron kommunizieren will, welche Tipps, welche Rezepte kannst du da unseren Hörern mitgeben?

Eberhard Wolff: Ganz konkret ist es im Buch so, dass als Vertreter für die message-orientierten Systeme “Kafka” diskutiert wird. Kafka ist gerade im Microservices-Bereich etwas, was relativ viel Aufmerksamkeit bekommen hat, weil es eine Historie aller Events speichert, also alle Nachrichten, die jemals ausgetauscht worden sind. Das hat einige nette Konsequenzen. Man kann zum Beispiel im Prinzip aus diesen Events den Zustand eines Microservices rekonstruieren. Dann gibt es weitere message-orientierte Systeme, da gibt es eine Vielzahl, denn es ist schon sehr lange ein Thema, mit dem Systeme betrieben werden. Was vielleicht noch überraschend oder interessant ist – was im Buch auch diskutiert wird – man kann mit REST auch asynchron kommunizieren. Konkret ist es im Buch so, dass dort die Bestellungen als ein Atom-Feed angeboten werden. Atom ist eigentlich ein Format, mit dem man Blogposts oder Podcasts verbreiten kann. Ich kann über Atom auch einfach Bestellungen anbieten. Wenn ich diesen Atom-Feed abonnieren will, dann hole ich mir regelmäßig diese Information sehr effizient gestaltet über HTTP ab, denn HTTP hat ein eingebautes Caching. Das ist auch eine Sache, die ich dem Leser ans Herz legen will: Dass HTTP, REST und asynchrone Kommunikation mit Atom beispielsweise eine nette Alternative sind, weil ich dann nicht noch eine messageorientierte Middleware in mein System einbauen muss, sondern ich kann diese Kommunikation über HTTP betreiben. Und HTTP ist etwas, was jedes System heutzutage machen kann.

Lucas Dohmen: Wenn wir jetzt die beiden Möglichkeiten gegenüberstellen, ist es ja so, dass bei der Version mit Kafka eine zusätzliche Komponente eingeführt wird, auf die alle eine Abhängigkeit haben und die bei Updates oder Austausch eventuell größere Kosten verursachen kann, weil es alle Microservices betrifft. Siehst du da Probleme oder Ideen, wie man diese Kopplung etwas lockern kann oder ist das einfach inhärent?

Eberhard Wolff: Das ist einfach so. Ich muss auch gestehen, ich finde das gar nicht so schlimm. Am Ende ist es so, dass Microservices miteinander kommunizieren müssen und dazu müssen sie irgendeine gemeinsame Technologie haben. Mindestens einmal Netzwerk Switches und Kabel und irgendetwas. Dann gehört bei Kafka auch die messageorientierte Middleware dazu und das finde ich nicht sehr dramatisch. Es gibt ein paar Probleme oder Herausforderungen, die sind aber eher auf architektureller Ebene. Wenn ich tatsächlich sage, dass alle Microservices ihren Zustand aus Kafka rekonstruieren können, dann habe ich ein zentrales Datenmodell im Kafka und das ist eigentlich genau das, was ich mit Microservices nicht machen will. Das ist aber ehe eine Arichtekturfrage: getrennte Datenmodelle, Bounded-Context, verschiedene Variationen des Kunden. Und da ist die Frage, wie man das damit verheiratet, dass man in in einem System wie Kafka ein zentrales Datenmodell haben muss oder haben will. Wie gesagt, eine architekturelle Frage. Ich kann Kafka auch ganz normal für bilaterale Kommunikation zwischen zwei verschiedenen Microservices benutzen und muss nicht unbedingt ein zentrales Datenmodell drauf bauen.

Lucas Dohmen: Es gibt aber in irgendeiner Art und Weise immer eine Shared-Language zwischen diesen Microservices, oder? Das, was auf Kafka gesprochen wird.

Eberhard Wolff: Wenn ich es so implementiere, also sage, alle Microservices sprechen über ein “Kafka-Topic” miteinander. Wenn ich also einen Microservice baue und du den anderen und wir haben unser privates Kafka-Topic, dann hätten wir so etwas gerade nicht, sondern ein bilateral ausgehandeltes Datenmodell. So etwas wie Customer-Supplier, wo der eine dem anderen das Datenmodell vorgibt. Dann würde ich dort gerade kein zentrales Datenmodell bauen, sondern etwas, das nur uns beide interessiert.

Lucas Dohmen: Magst du ganz kurz für die Hörer, die Kafka nicht so gut kennen, erklären, was ein Topic in Kafka ist?

Eberhard Wolff: Das ist ein benamtes Ding in Kafka, wo man Records – das sind letztendlich Nachrichten– reinschreiben und rauslesen kann. Das heißt, wenn ich den Kafka-Broker unter seiner IP-Adresse und seinem Port kenne und seine Topic kenne, dann kann man miteinander kommunizieren.

Lucas Dohmen: Wir haben jetzt über synchrone und asynchrone Kommunikation zwischen Microservices gesprochen. Gibt es noch weitere Möglichkeiten, wie sie miteinander kommunizieren können?

Eberhard Wolff: Ja, eine weitere Möglichkeit ist Front-End-Kommunikation. Das ist eine der Sachen, die auch überraschend ist, wenn man glaubt, dass Microservices einfach REST-Services sind und gar nicht auf die Idee kommt, dass ein Microservice ein Front-End haben kann. Ich glaube aber, dass Microservices, wenn sie ein Front-End haben, eigentlich auch “besser” sind, weil ich dann die gesamte Funktionalität inklusive Front-End innerhalb eines Microservices umgesetzt habe. Das bedeutet, wenn ich eine Änderung machen will, die auch das Front-End verändert, dann kann ich das auf einen Microservice begrenzen. Der andere Vorteil ist, Front-End-Integration ist sehr einfach und flexibel. Im Buch benutze ich als Beispiel, woran du ja auch mit gebaut hast, wo das System im wesentlichen aus verschiedenen Services besteht, die über Links miteinander kommunizieren. Wo zum Beispiel ein Versicherungskunde ist, der dann Links zu seinen Schadensmeldungen hat. Und das sind zwei getrennte Services, die über Links miteinander integriert sind.

Ich finde das sehr schön, weil Links eine sehr einfache Integration ist. Es ist technologisch sehr unaufgeregt, sehr einfach und gleichzeitig kommt man sehr weit damit, wie das Beispiel von eben zeigt. Darüber hinaus ist es so, dass man dabei auch sehr flexibel ist: Wenn jetzt jemand darauf kommt, dort nicht mehr HTML-Seiten zurückzugeben, sondern PDFs oder etwas ganz anderes, dann geht das einfach. Das finde ich eine sehr schicke Sache. Es gibt weiter die Möglichkeit über Transklusion noch weiterführende Dinge zu tun, also Teile eines anderen Microservices einzublenden. In dem Beispiel ist es dann die “Post-Box”, wo man beispielsweise in der aktuellen Seite einen Überblick über die erhaltenen Nachrichten eingeblendet bekommt. Das sind auch nur ein paar Zeilen Javascript-Code, also technisch wieder sehr unaufgeregt, und es ist natürlich etwas, das sehr deutlich zeigt, dass die Implementierungstechnologie für den Microservice eigentlich gar keine Rolle spielt. In dem Beispiel von eben, das ihr gebaut habt, sind die Microservices in Node und Spring Boot geschrieben und das merkt man nicht, die sehen gleich aus und sind am Front-End integriert und das zeigt sehr deutlich, dass dort die unterschiedlichen Technologien, die hinten auf dem Server genutzt werden, eigentlich gar keine Rolle spielen.

Lucas Dohmen: Für mich ist daran das spannendste, dass man unabhängige Deployments hat. Dass ein Team sagen kann, dass es sowohl im Back-End als auch im Front-End etwas gebraucht hat und es einfach released, ohne dass die anderen Services etwas davon wissen müssen.

Eberhard Wolff: Wobei unabhängiges Deployment bei allen Microservices der Fall sein sollte, das ist für mich eigentlich eine Voraussetzung. Du hast insofern Recht, dass ich ein Feature, welches Front-End plus Back-End umfasst mit einem Deployment sozusagen scharf schalten kann.

Lucas Dohmen: Genau. Wir haben letztes Jahr dazu schon eine INNOQ Podcastfolge aufgenommen, in der du Falk und Till dazu interviewt hast, richtig?

Eberhard Wolff: Genau, zu dem Transklusionsthema. Dort haben wir noch einmal sehr ausführlich über diese Themen gesprochen. Im Buch ist, wie gesagt das Beispiel dargestellt, welches letztendlich der Arbeitsplatz eines Versicherungsmitarbeiters ist. Das Versicherungsbeispiel finde ich sehr schön, weil es sehr klassisch und technisch unaufgeregt ist, im Gegensatz zu einem Start-Up, in dem irgendwelche Microservice-Geschichten diskutiert werden. Das andere Beispiel im Buch ist “ESI – Edge Side Includes”, wo HTML auf dem Server aus mehreren Quellen durch einen Cache, im Beispiel ist es “Varnish”, zusammengebaut wird, was auch einige interessante Konsequenzen hat. Zum Beispiel kann ich hier einfach die Back-Ends abschießen und das System läuft erst einmal weiter, weil der Cache die Seiten im Cache hält. Das geht natürlich nur, wenn ich lese, aber immerhin, und das hat mit dem Thema Resilienz zu tun: ich darf kein System bauen, wo der Ausfall eines Microservices das gesamte System zum Ausfallen bringt, weil ich sehr viele Microservices habe und damit ein hohes Risiko hätte. Genau dort kann so etwas wie Edge-Side-Includes und der Cache hilfreich sein.

Lucas Dohmen: Du hast in dem Buch auch über Betrieb gesprochen. Deine Bespiele hast du in Docker gemacht, richtig?

Eberhard Wolff: Ja, genau. Es sind alles dockerisierte Beispiele - mittlerweile die standardisierte Technologie für Mircoservices, glaube ich.

Lucas Dohmen: Welche Plattformen kannst du da empfehlen oder welche hast du schon ausprobiert, um die Docker Container im Betrieb zu betreiben?

Eberhard Wolff: Die meisten Beispiele in dem Buch arbeiten mit ganz normalem Docker, also plain Docker, so, wie man es herunterladen kann, und die laufen dann auf einem lokalen Rechner oder mit Docker Machine in einer Cloud-Umgebung. Docker Machine erlaubt es einem sehr einfach, auf einem Rechner Docker zu installieren. Es gibt dann interessante Systeme wie Kubernetes, die einem erlauben Docker Container auszuführen, bieten darüber hinaus aber noch viel mehr, beispielsweise Service Discovery, Load Balancing und alle Geschichten, die man für synchrone Mircoservices benötigt. Das ist eine sehr spannende Sache, weil ich dadurch nicht nur eine Betriebsumgebung bekomme, wo ich die Docker Container ablaufen lassen kann, sondern auch die notwendigen Technologien für eine synchrone Kommunikation geliefert durch die Umgebung. Das Beste dabei ist dann, dass die Software selbst nichts darüber weiß, dass es diese Technologien überhaupt gibt. Service Discovery in Kubernetes funktioniert mit DNS; es gibt irgendwelche Hosts für irgendwelche Microservices, aber sonst eben keine Abhängigkeiten darauf. Aus genau diesem Grund ist es eine ganz spannende Alternative. Eine andere Plattform, die einen anderen Ansatz wählt, ist “Platform as a Service”. Der Unterschied dort ist, dass ich die Docker Container nicht mehr selber baue, sondern eine Anwendung anliefere, in Java beispielsweise ein JAR-File, wo die gesamte Anwendung als Gesamtpaket drin ist, und dann kümmert sich das “Platform as a Service” darum, die zum Ablaufen zu bringen. Auch hier ist der Code selbst unabhängig von der Service Discovery und Load Balancing ist auch eingebaut und so weiter. Deswegen sind diese Plattformen sehr spannende Möglichkeiten an der Stelle.

Lucas Dohmen: Bieten diese Plattformen auch Möglichkeiten für Monitoring und Logging an oder ist das etwas, was ich mir noch dazu nehmen muss?

Eberhard Wolff: Mindestens die Verwaltung von Logs unterstützen die meisten und ich kann zumindest ein einfaches Monitoring bekommen. Im Buch gibt es ein eigenes Kapitel für den Betrieb und dort diskutiere ich “Prometheus” als Werkzeug, mit dem man gerade so etwas wie Monitoring von Microservices ganz gut erschlagen kann. Wahrscheinlich würde man in so einer Umgebung noch ein paar Sachen zusätzlich einbauen wollen, beispielsweise ein eigenes Monitoring-Werkzeug.

Lucas Dohmen: Was Logging angeht, ist es auch immer schwieriger in einer verteilten Umgebung als in einem Monolithen - was hast du da für Möglichkeiten?

Eberhard Wolff: Da gibt es sehr unterschiedliche Möglichkeiten. Wie erwähnt, Systeme wie Kubernetes unterstützen da etwas. Im Buch selbst habe ich den “Elastic Stack”, der sehr populär ist, und wo man über Elasticsearch die ganzen Logging Informationen sammelt und über Kibana analysiert. Das System, was ich dort umgesetzt habe, loggt die Ausgaben direkt als JSON in eine Datei, die dann in Elasticsearch weiter gereicht wird und da es JSON ist, muss es nicht noch einmal geparst werden. Normalerweise müsste man die Logzeile auseinander schneiden und sagen: hier ist der Timestamp, hier ist der Thread, in dem etwas passiert ist, hier ist die eigentliche Nachricht und das nach dem Parsen an Elasticsearch übergeben. Dass hier aber direkt in JSON geloggt und in Elasticsearch eingebracht werden kann, ist glaube ich, ein ganz geschickter Ansatz.

Lucas Dohmen: Gibt es auch Möglichkeiten Tracing in so einem System durchzuführen?

Eberhard Wolff: Ja, das Beispiel im Buch ist da “Zipkin”, was dort eine relativ große Bedeutung hat. Mit Tracing kann ich schauen, wenn ich einen Aufruf an einen Microservices habe, welche anderen Microservices aufgerufen werden und wie lange das jeweils dauert um eine Analyse darüber zu bekommen, wo die Bottlenecks und Abhängigkeiten sind. Das kann man dort anhand von Zipkin nachvollziehen.

Lucas Dohmen: Wenn ich mir das konkreter vorstellen möchte, kann ich mir da Code zu den verschiedenen Rezepten ansehen? Welche Möglichkeiten habe ich da?

Eberhard Wolff: Das war bei dem Buch genau einer der wichtigen Punkte für mich: dem Leser konkreten Code mit an die Hand geben, um die Beispiele direkt nachvollziehen zu können. Diese sind alle auf meinem GitHub Account oder auf meiner Homepage “ewolff.com”. Dort findet man unten einen Link, sowohl auf die Microservices-Demos, als auch den Link auf die GitHub Demos. Mein Anspruch ist dabei, die Demos besonders einfach zu halten, sodass sie schnell und einfach genutzt werden können. Deswegen sind die Beispiele fachlich meistens extrem trivial - mit Absicht, um den Einstieg dort möglichst einfach zu machen. Wie bereits erwähnt, sind es ja isolierte Rezepte und meine Vermutung wäre, dass man mehrere davon kombinieren muss, um sein eigenes System zu bekommen und da sieht man einen dieser Ansätze in Isolation. Die GitHub Beispiele haben eine ausführliche Anleitung wie man das System Schritt für Schritt starten können sollte. Auch wenn man das Buch nicht gelesen oder gekauft hat, bekommt man es auf jeden Fall hin, das System zu starten und damit ein paar Erfahrungen zu machen, es sich anzuschauen, den Code herunterzuladen und sich anzuschauen - da ist jeder eingeladen, damit zu tun oder zu lassen, was er will. Die Beispiele stehen alle auch unter der Apache-Lizenz, und ich freue mich auch darüber, wenn es Feedback gibt. Auch wenn das Feedback lautet “geht bei mir nicht” oder “ich hab dieses oder jenes nicht verstanden”, dann kann ich das entsprechend verbessern und aufarbeiten.

Lucas Dohmen: Das könnten die Leute dann einfach als GitHub-Issue machen? Oder was ist da der beste Weg?

Eberhard Wolff: Ja, genau. Ein GitHub-Issue einstellen ist der ideale Weg.

Lucas Dohmen: Wenn sich die Leute jetzt für das Buch interessieren, hast du dazu noch Infos? Wo findet man das Buch?

Eberhard Wolff: Es gibt eine Website zu dem Buch, “microservices-praxisbuch.de”, dort findet man einen Link auf die Microservices-Rezepte. Das ist eine Broschüre, ungefähr vierzig Seiten dick und über Leanpub kostenlos downloadbar. Man darf mir auch einen Dollar dafür bezahlen, aber man darf es auch sehr gerne kostenlos herunterladen oder man kann es sich auch bei Amazon für Kindle oder als gedruckte Version kaufen. Die Kindle-Version kostet ungefähr einen Euro und die gedruckte ungefähr vier Euro. Es handelt sich dabei um einen Ausschnitt aus dem Buch, der das, was wir diskutiert haben, noch einmal in gedruckter Form darstellt und auch die Beispiele in Ansätzen diskutiert. Also als Appetizer für das Buch selber, das noch einmal über dreihundert Seiten hat und deutlich weiter geht. Es gibt darin beispielsweise auch Aufgaben, mit denen man die Demos erweitern kann und die im kostenlosen Buch fehlen. Ich glaube aber, als Einstieg ist es eine gute Sache da noch einmal drauf zu gucken, um diese Ideen, über die wir diskutiert haben noch einmal genauer zu sehen.

Lucas Dohmen: Klasse! Vielen Dank, dass du zu Gast warst.

Eberhard Wolff: Danke, für die vielen interessanten Fragen und die Diskussion.

Lucas Dohmen: Bis zum nächsten Mal beim INNOQ Podcast.