Sam Newman: Microservices

You are currently viewing Sam Newman: Microservices

Sam Newman
Übersetzung: Knut Lorenzen
Microservices: Konzeption und Design

1. Auflage
2015, 318 S., Broschur
mitp-Verlag
ISBN: 978-3-95845-081-3

Informationen zum Buch im Katalog der Deutschen Nationalbibliothek.



Sam Newman gibt dem Leser in seinem 2015 erschienen Buch einen Überblick über so ziemlich alle Themen rund um die Microservice-Architektur. Zwar werden viele der Themen nicht allzu detailliert angegangen, aber die Prinzipien der Microservice-Architektur werden klar. Der Microservice-Neuling findet in Newmans Buch alles, was er braucht, um mit Microservices loslegen zu können.


Inhalt und Struktur

Das erste Thema, das Newman angeht, ist selbstverständlich das Wesen der Microservices: was ist ein Microservice, welche Vor- und Nachteile hat der Microservice-Architekturstil und wie lassen sich Microservice-Architektur und Serviceorientierte Architektur (falls überhaupt) voneinander abgrenzen. Eine Microservice-Architektur bringt viele Änderungen mit sich, so bedeutet dies auch für die Rolle des Architekten einen Wandel. Konkret geht der Autor im zweiten Kapitel auf die (neue) Rolle des Architekten ein.

Auf Eric Evans Konzept des Bounded Context aus dem Buch Domain-Driven Design Bezug nehmend beschreibt Newman im dritten Kapitel Gestaltung von Services, wie Microservices geschnitten werden können, um sich dann im vierten Kapitel den technischen Aspekten der Integration der einzelnen Dienste zu widmen. Wenig verwunderlich ist das vierte Kapitel eines der umfangreichsten des Buches. Darin geht es unter anderem um solche Themen wie RPC vs. REST, Orchestrierung oder Choreografie, Versionierung und vielem anderem.

Die Frage, wie man seinen Monolithen in Microservices aufspaltet, dürfte für viele Teams besonders relevant sein. Dieser geht Newman im fünften Kapitel nach. Ein wichtiges Konzept zur Identifikation von Grenzen entlang derer die Microservices geschnitten werden können, erscheint Newman Michael Feathers Seam-Konzept aus dessen Buch Effektives Arbeiten mit Legacy Code. Wie die Datenbank aufgeteilt werden kann, wird in diesem Kapitel ebenfalls besprochen.

In den Kapiteln sechs bis acht widmet sich der Autor Themen, die einerseits gegenüber einer monolithischen Architektur komplizierter werden aber andererseits dringend notwendig sind, um in den Genuss der Vorteile der Microservice-Architektur zu kommen (Kapitel 6: Deployment, Kapitel 7: Testen, Kapitel 8: Monitoring). So ist z.B. eine automatisierte Deployment-Pipeline unumgänglich, Testen wird generell komplexer durch Microservices und ein sinnvolles Monitoring ist auch vonnöten.

Im neunten Kapitel werden Sicherheitsaspekte besprochen: Single-Sign-On (SSO), SSL/TLS, API-Schlüssel und Intrusion Detection Systeme (IDS) sind einige der Themen, die im Kapitel gestreift werden. Das zehnte Kapitel geht auf das im Zuge des Microservice-Hypes stark popularisierte Gesetz von Conway ein und entsprechend auf den Einfluss der Organisation auf den Schnitt der Microservices.

Zu guter Letzt widmet sich der Autor Aspekten der Skalierung: diverse Patterns wie Circuit Breaker und das Bulkhead Pattern (beide initial von Michael Nygard in seinem Buch Realse It! Design and Deploy Production-Ready Software beschrieben), das CAP-Theorem, Caching, Lastenverteilung, Serviceregistrierung usw. Das letzte Kapitel fasst das Buch kurz zusammen.

Diskussion

YAGNI – damit ließe sich die Eignung von Microservices für die meisten Anwendungsfälle zusammenfassen. YAGNI ist ein Akronym aus der Extreme Programming-Welt, der für „you ain’t gonna need it“ (wahlweise auch „you arn’t gonna need it“) steht. Dabei ist YAGNI quasi die Implementierung des XP-Wertes „Einfachheit“, was durch den relativ berühmten Satz „What is the simplest thing that could possibly work?“ (Kent Beck. 2000. Extreme Programming: Die revolutionäre Methode für Softwareentwicklung in kleinen Teams. Addison-Wesley. S. 30) zusammengefasst wird. In den meisten Fällen ist die einfachste Lösung eben etwas nicht zu implementieren, zumindest bis klar wird, dass man dieses etwas wirklich braucht, weswegen: „you ain’t gonna need it“. Nach einer mehrjährigen Hype-Phase hat sich mittlerweile der Rummel um das Thema Microservices gelegt. Eberhard Wolff stellt sogar im Artikel Und jetzt? Microservices nach dem Hype eine Umkehrung des Hypes ins Gegenteil fest. Aber ganz tot kann das Thema ja nicht sein, sonst würde sich eine zweite Auflage des vorliegenden Buches nicht gerade in Bearbeitung finden.

Beim Thema Microservices – wie bei allen anderen gehypten Themen im Bereich Software Engineering – muss man zwischen den sinnvollen Anwendungsfällen und den nicht so sinnvollen unterscheiden. Und Microservices haben sehr wohl ihre sinnvollen Anwendungsfälle und ihre Vorteile, aber auch ihre Nachteile (Martin Fowler spricht von einem Microservice Premium, einem „Aufschlag“, den man bei deren Verwendung zahlen muss). Die Vorteile sind in erster Linie, und ich muss hinzufügen meiner Meinung nach, da es hier teilweise auch andere Meinungen gibt, die Flexibilität und die Skalierbarkeit. Der Nachteil ist ganz klar die gesteigerte Komplexität, die eine verteilte Datenhaltung und -bearbeitung nach sich ziehen. Ein Monolith – Monolith, der zum Schimpfwort verkommen ist im Zuge des Microservice-Hypes, ähnlich wie „Wasserfall“ zum Schimpfwort der Agilisten wurde – ist in den meisten Fällen doch die einfachere und ausreichende Lösung.

Wie positioniert sich nun Newman in seinem Buch zu dem bisher Geschriebenen? Ich glaube, dass er sich durchaus der Problematik bewusst ist, er hebt wiederholt die Komplexität hervor, die mit einer Microservice-Architektur einhergeht und er warnt vor einem naiven Vorgehen beim Einsatz von Microservices. Am Ende des Buches widmet er auch etwa eine Seite der Frage, wann Microservices nicht einzusetzen wären. Dass in einem Buch über Microservices „you ain’t gonna need microservices“ aber nicht geschrieben stehen kann, ist zu erwarten. Viele andere haben aber schon diese Aussage gemacht und ich wiederhole sie hier gerne: für die allermeisten Anwendungen (und Teams) ist ein Monolith vollkommen ausreichend.

Wie ist aber nun das Buch zu bewerten, wenn man Microservices tatsächlich gebrauchen kann oder zumindest probieren würde? Wenn man das Buch betrachtet, wirkt es etwas dünn für seine über 300 Seiten, wenn man es dann aber zu Ende gelesen hat, muss man jedoch feststellen: es ist erstaunlich umfangreich und ziemlich komplett. Selbstverständlich steht nicht „alles“ drin, aber immerhin alles, was man braucht, um zu verstehen, was Microservices sind, wie deren Betrieb aussieht und auch welche Auswirkungen Microservices auf die Organisation des Unternehmens haben (können). Das Buch setzt Leser voraus, die schon ein paar Jahre Erfahrung als Entwickler haben. Angesichts der Komplexität der Thematik ist das aber nicht verwunderlich. Was das Thema Microservices angeht, spricht das Buch in erster Linie Microservice-Neulinge, oder solche, die noch nicht viel Erfahrung mit diesem Architekturstil haben, an. Ein Microservice-Experte dürfte dem Buch nicht mehr viel abgewinnen können. Der Microservice-Neuling findet in Newmans Buch jedoch alles, was er braucht, um mit Microservices loslegen zu können.


Zum Autor

Sam Newman ist ein international aktiver Softwareberater, Autor und Speaker. Er hat zwei Bücher zum Thema Microservices geschrieben:

  • 2015. Building Microservices: Designing Fine-Grained Systems. O’Reilly Media
    Deutsche Ausgabe: Microservices: Konzeption und Design. mitp. 2015.
  • 2019. Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith. O’Reilly Media.
    Deutsche Ausgabe: Vom Monolithen zu Microservices: Patterns, um bestehende Systeme Schritt für Schritt umzugestalten. O’Reilly. 2021

Quellen: Die Informationen über den Autor sind seiner Selbstbeschreibung auf seiner Webseite entnommen. Bibliographische Angaben gem. Library of Congress und Deutsche Nationalbibliothek. (Abruf: 17.05.2021).


Folgende Rezensionen könnten Sie ebenfalls interessieren:

Petre Sora

Petre Soras Interessen sind vielfältig und befinden sich an der Schnittstelle zwischen Mensch und Informationstechnologie. Nachdem er sein Bachelorstudium im Fach Psychologie abschloss, orientierte er sich neu und studierte Software Engineering an der Hochschule Heilbronn, ebenfalls mit einem Bachelor abgeschlossen. Anschließend war er knappe sechs Jahre als Java-Entwickler in mehreren Unternehmen tätig. Aktuell ist er mit dem Masterstudium der Praktischen Informatik und der Rezensionsplattform für IT-Fachbücher nososo.de beschäftigt.

Schreibe einen Kommentar