Von Monolithen und Microservices: Funktionierende Microservices-Architekturen erstellen

Von Markus Lackner, Michael Hofmann, Carola Lilienthal und 2 weiteren

Der inzwischen schon eine Weile anhaltende Trend zu kleinen, modularen Services ist ungebrochen und gewinnt für viele Unternehmen immer höhere Bedeutung. Im Gegensatz zu allumfassenden Softwaremonolithen stehen Microservices für Flexibilität, Skalierbarkeit, schnellere Entwicklungs- und Updatezyklen und gelten ganz allgemein als State of the Art moderner Softwarearchitektur.
Zum Einstieg in diesen shortcut diskutiert Marco Schulz zunächst die Frage, wann Microservices für ein Unternehmen wirklich Sinn ergeben und welche organisatorischen und technischen Rahmenbedingungen notwendig sind. Wie der Wechsel vom Monolith zu Microservices unter Beachtung von Domain-driven Design gelingen kann, zeigt Dr. Carola Lilienthal an einem gut nachvollziehbaren Beispiel aus der Praxis. Lars Röwekamp geht dem Problem der getrennten Datenhaltung einzelner Microservices nach und zeigt Möglichkeiten auf, wie Sie Businesstransaktionen mit Microservices durchführen können und sich trotzdem keine Sorgen um die Konsistenz Ihrer Daten machen müssen. Zum Abschluss erläutern Michael Hofmann und Markus Lackner, wie Sie mit dem Cloud-basierten Tool Istio dem Service Mesh, der Masse einzelner Microservices, die eine Microservices-Architektur ausmachen, Herr werden.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 5. Apr. 2019
• ISBN: 9783868028485

Buchvorschau

GmbH

1 Wann Microservices (nicht) sinnvoll sind

Microservices haben mittlerweile für viele Unternehmen eine sehr hohe Bedeutung gewonnen. Durch die Verwendung dieser neuen Technologie erhofft man sich größere Flexibilität, um auf künftige Änderungen reagieren zu können. Allerdings ist es nicht damit getan, das bestehende Projekt in kleine Fragmente aufzuteilen und diese als Services zu bezeichnen. Neben den technischen Herausforderungen sind auch viele strukturelle Rahmenbedingungen zwingend erforderlich, um langfristig erfolgreich zu sein. Dieses Kapitel zeichnet ein weites Bild um die vielen Details und hilft dabei, Entscheidungen zu verstehen.

Fragt man nach den Beweggründen, weshalb in einem Unternehmen Microservices eingeführt werden sollen, sind die Antworten meist identisch. Durch einen modularen Aufbau der gesamten Anwendung haben viele Projektverantwortliche das Bild eines LEGO-Baukastens vor Augen. Man glaubt, einzelne Fragmente beliebig kombinieren zu können, um so einen hohen Grad an Wiederverwendung und natürlich implizit auch erhebliche Kosteneinsparungen in der Entwicklung zu erzielen. Die Realität schaut aber ein wenig anders aus. Ein gebetsmühlenartiges Proklamieren von wiederverwendbaren Komponenten ist für den Erfolg nicht ausreichend. Diese Evangelien wurden bereits aus dem objektorientierten Design, der vorangegangenen Religion, abgeschrieben. Auf die Erfüllung warten viele Jünger teilweise noch heute.

Standhaftigkeit

Wenn wir von Stabilität sprechen, bewegen wir uns im Kontext der nicht funktionalen Anforderungen. Aus Erfahrung wissen wir um die Schwierigkeiten, eine solche Anforderung zu artikulieren. Die meisten Beteiligten haben oft eine eigene oder nur eine vage Vorstellung über die für das Projekt relevante Bedeutung des Begriffs Stabilität. Um hier ein gemeinsames Verständnis zu schaffen, ist es unumgänglich abzugrenzen, wie im Konkreten Stabilität verstanden werden soll. Betrachten wir hierzu eine Arbeit von Boehm [1] aus dem Jahr 1976, deren Thematik Softwarequalität ist. Die von Boehm aufgezeigten verschieden Betrachtungsweisen, was der Qualitätsbegriff im Kontext von Software bedeuten kann, soll auch uns als Ausgangspunkt dienen. So können wir für den Begriff Stabilität die Aspekte Fehlertoleranz von Benutzerinteraktionen oder Netzwerklatenzen außen vor lassen. Fokussieren wir uns daher auf den Bereich Maintenance (Wartung). Denn bei Enterprise-Projekten können wir uns stets gewiss sein: Die Laufzeit der entstandenen Anwendung wird viele Jahre, wenn nicht sogar Jahrzehnte umfassen. Das impliziert kontinuierliche Anpassungen und Erweiterungen. So existieren hinreichend viele Beispiele von Anwendungen, die komplett neu entwickelt werden mussten, da sich die Aufwendungen für notwendige neue Funktionen nicht tragen konnten. So sehen einige Unternehmen in der Umstellung zu einer Service-orientierten Architektur durchaus reale Chancen, Altlasten loszuwerden. Um diese neuen Pfade erfolgreich zu beschreiten, ist es notwendig, sich mit gewonnen Erkenntnissen und Standards auseinanderzusetzen, die wir im Folgenden genauer betrachten werden.

Bonusrunden

Rekapitulieren wir an dieser Stelle besser einmal, welche Anforderungen mit einer monolithischen Architektur schwierig umzusetzen sind. Ein sehr wichtiger Aspekt ist die Risikominimierung bei der Zusammenarbeit mit externen Dienstleistern. So können beispielsweise eigenständig lauffähige Module als separates Projekt mit eigenem SCM Repository verwaltet werden, ohne dass den Offshore-Kontraktoren Zugang zu sämtlichen Interna bereitgestellt werden muss. Dieses Bild lässt sich auch für verschiedenste kollaborative Szenarien weiterentwickeln. So verhindert man bei Teams, die noch keine gemeinsame Kultur entwickelt haben, dass ein Entwickler mal schnell nach eigenem Ermessen Änderungen an Codebereichen vornimmt, die er nicht zu verantworten hat.

Wenn bei der Entwicklung auch einige Standards und Disziplin eingehalten werden, können die so entstandenen Artefakte durchaus in weiteren Applikationen ihre Verwendung finden. Neben der Vermeidung der üblichen Fallstricke im Design der Wartbarkeit gehört zu einer erfolgreichen Wiederverwendung auch eine ausführliche Dokumentation, die mehr als nur triviale Beispiele aufführt. Wenn die Forderung nach wiederverwendbaren Artefakten essenziell ist, müssen sich die Beteiligten sehr wohl im Klaren darüber sein, dass dies zusätzliche Kosten verursachen wird. Zur Risikominimierung ist es unumgänglich, den Funktionsumfang von wiederverwendbaren Komponenten erheblich einzuschränken. Es sollen für das entsprechende Einsatzszenario hochspezialisierte Komponenten entstehen und keine „eierlegende Wollmilchsau." Diese Forderung findet sich auch in der Konzeption von Microservices wieder. Ein iteratives Vorgehen, das dafür Sorge trägt, dass keine Funktionalität im Voraus entwickelt wird und nur aktuell notwendige Anforderungen umgesetzt werden, senkt die Entwicklungskosten erheblich. Ein Grund dafür liegt in reduzierten