Ich weiß – ein Brett von einem Beitragstitel. Aber ja, ab und zu lese ich Fachliteratur. Es traf ein Buch zum Thema Microservices, das mir mit überschwänglichem Lob empfohlen wurde. Okay, warum nicht? Ich arbeite seit (erst) ca. vier Jahren mit Microservices. Meine Erwartungshaltung war über viele Basics zu stolpern, die man eben nicht zum ersten Mal liest. Aber auch manche Lücken stopfen zu können, die learning by doing hinterließ. Auch hätte ich gern Alternativen und Denkanstöße für eingetreten Pfade. Tatsächlich fand ich all das in Newmans Buch.

Bei dem Buch handelt es sich um die zweite, überarbeitete Ausgabe von Sam Newmans Building Microservices, das erstmalig 2015 erschien. Die überarbeitete und aktualisierte zweite Fassung erschien 2021 und ist meines Wissens bisher nur auf Englisch verfügbar, wohingegen man die erste auch auf Deutsch findet. Newman selber ist freiberuflicher IT-Consultant und arbeitet (wenig überraschend 🙂) vorrangig auf den Gebieten Cloud, Continuous Delivery und Microservices. Das Buch ist aufgeteilt in drei große Abschnitte: Foundations, Implementation und People. Nach einem Vorwort darüber, worin sich die beiden Ausgaben unterscheiden, beginnt der erste Abschnitt mit Grundlagen rund um Microservices, genauer der Definition wann man überhaupt von Microservices spricht, wie man diese modelliert und wie sie miteinander kommunizieren. Zusätzlich auch wie man einen Monolithen in Microservices schneidet. Bei dem Kapitel denken sicherlich viele an Erfahrungen und den Krampf mit monolithischen Anwendungen zurück, aber auch deren Vorteilen, die Newman auch erwähnt und klar macht: Microservices sind cool, aber nicht automatisch die Lösung für alle Probleme.

Das Buch ist allgemein sprach- & technologie-agnostisch, aber bestimmte Tools werden öfter erwähnt als andere. Spring und Java (die Welt aus der ich komme) finden Erwähnung, .Net definitiv mehr. Ähnliches lässt sich über spezifisches CI/CD Tooling, Monitoring, Testing Frameworks, etc. sagen. Newman gibt Tipps und manche Tools werden öfter erwähnt als andere. Er preist aber keine klaren Gewinner an, d.h. ich würde nicht von Werbung sprechen. (Was gut ist.) Wenn man aus einem bestimmten Erfahrungsschatz heraus schreibt, baut man eben auf etwas auf, was ich grundsätzlich besser finde als bloßes Tech Babble und Name Dropping. Da das Buch sprach-/technologie-agnostisch ist, gibt es keine code snippets, sondern eher schematische Darstellungen der Konzepte.

Durch das Grundlagen-Kapitel braucht man im Grunde kein Vorwissen Microservices betreffend. Andererseits würde ich es Coding-Einsteigern nicht empfohlen. Mehrjährige Erfahrung mit der Anwendungsentwicklung in einem professionellen Kontext erscheinen mir aber hilfreich. Oder in anderen Worten: es hilft, wenn man schon mal etwas releasen durfte, warten musste oder Erfahrung mit CI/CD hat. Grundlegendes Wissen über Cloud-Technologien ist auch von Vorteil. Der zweite Abschnitt des Buches (Implementation) widmet sich dann nochmals der Microservice-Kommunikation (jetzt im Detail), Workflows, Build, Deployment, Testing, Monitoring, Security, Resilienz & Skalierung und geht damit quasi einmal komplett durch die tool chain durch, die eine moderne IT-Architektur aufweisen sollte.

Der dritte und letzte Abschnitt dann widmet sich Menschen (People). Wenn nicht schon zuvor einige Themen aufkamen, über die gern gestritten wird, dann spätestens hier. 😉 Wie sollte man Teams schneiden? Separates Frontend-Team oder in ein (Scrum-)Team integrieren? Machen alle alles und ist das überhaupt sinnvoll? Organisationsstrukturen werden auch angeschnitten und am Ende erklärt Newman noch, was er unter dem Begriff bzw. der Rolle Evolutionary Architect versteht, bevor er alles wichtige nochmal handlich und kurz zusammenfasst. Wer schon wieder was vergessen hat, bekommt hier alles an die Hand oder kann nochmal im Stichwortverzeichnis nachschauen. Besonders gefallen hat mir auch Newmans dezent eingestreuter Humor, der sich nicht nur in den Fußnoten versteckt. Aber auch der Pragmatismus. Newman scheut sich nicht darauf hinzuweisen, wo Microservices Schmerzen bereiten. Sie sind auf andere Weise komplex als ein Monolith. Auch schätze ich sehr Newmans Erfahrungsschatz, der sich mit meinem deckt. BPM Tools benutzen, weil andere die Business Objekte definieren? Wird viel „gesagt“, aber quasi nie gemacht. Also warum Developer damit ärgern und Freiheitsgraden berauben? 👍 für Newman, der auch an Developer Experience denkt.

Jetzt aber nochmal honest talk: habe ich etwas Neues gelernt? Ja! Dinge, die ich gelernt habe: CodeScene zu benutzen für Teile einer Software, die sich öfter ändern. Interessant bei der Frage, ob ein Service gesplittet werden muss. Mehrere Ansätze wie/wann man cachen kann oder sollte. Außerdem kannte ich Begriffe wie Canary Release nicht. Ich wünschte ich hätte das Kapitel über Event Sourcing gelesen, bevor ich es das erste Mal machen musste. Habe ich mich auch mal gelangweilt? Oh ja, sehr oft sogar bei den Grundlagen. Das bleibt nicht aus. Das Fazit kann insgesamt nur lauten: ein absolut runder Überblick, der keine Wünsche übrig lässt.

Besprochene Ausgabe: 978-1-492-03402-5, O’Reilly

Netzgeflüster ist eine Kategorie meines Blogs in der ich mich immer zwischen dem 10. und 15. eines jedes Monats Themen aus IT, Forschung, Netzwelt und Internet widme genauso wie Spaß rund um die Arbeit mit Bits und Bytes. 🙂