Microservices-Architektur: Patterns in Spring implementieren

Von Michael Schäfer, Achim Müller und Rafael Kansy

Die Microservices-Architektur ist ein moderner Architekturstil für die Bereitstellung von autonomen Services im Web. Die lose Kopplung, die hohe Skalierbarkeit und ein flexibles Deployment sind die herausragenden Merkmale der Architektur. Der Aufbau einer Microservices-Architektur stellt uns vor einige Problemstellungen, die mit bestehenden Patterns effizient gelöst werden können. Der shortcut zeigt, wie man Patterns in Spring implementieren kann.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 10. März 2016
• ISBN: 9783868025835

Buchvorschau

GmbH

1 Microservices Architecture

1.2 Warum Microservices Architecture?

Die Gesellschaft konsumiert Produkte und Services überwiegend im Internet. Ganz neue digitale Geschäftsmodelle entstehen. Start-up-Unternehmen wie Uber und Airbnb schießen wie Pilze aus dem Boden. Diese Unternehmen sind stark disruptiv, das heißt, sie verdrängen bestehende Technologien und Produkte vollständig vom Markt. Aber auch große und bereits bekannte Unternehmen wie Google, Amazon, Netflix oder Spotify etablieren neue Produkte und Services in neuen und bestehenden Märkten. Mit der Veränderung der Gesellschaft und den neuen technologischen Möglichkeiten haben wir es mit einer ganz neuen Art von Kunden zu tun. Der Kunde ist sehr stark individualisiert und erwartet daher personalisierte Produkte. Er hat keine Zeit und möchte das passende Produkt für sein Problem sofort haben. Das Produkt muss einfach sein und ihn begeistern. Es muss schnell und fehlerfrei funktionieren. Fehler in den Produkten müssen umgehend beseitigt werden und neue Features schnell verfügbar sein – und das rund um die Uhr, unabhängig von Ort und Kanal (Desktop, Mobile, TV …).

Mit diesen Anforderungen stehen wir als IT-Architekten vor einem ganz neuen Anwendungskontext, der uns vor neue Herausforderungen stellt. Wir benötigen eine dafür passende IT-Architektur. Die Microservices Architecture verspricht uns, genau für diesen Anwendungskontext die beste Architektur zu sein. Aber warum? Schauen wir uns dazu die Merkmale und die sich daraus ergebenden Vorteile etwas genauer an. Microservices sind

klein

autonom

miteinander kombinierbar

Dabei bedeutet klein, dass der Microservice genau eine fachliche Aufgabe optimal umsetzt, beispielsweise die personalisierte Anzeige meiner Filme bei Netflix. Die LOC¹, nach denen in diesem Zusammenhang immer wieder gefragt wird, spielen dabei nur eine untergeordnete Rolle. Es geht um den Business Value², den der Microservice liefern soll.

Dabei bedeutet autonom, dass die Microservices unabhängig voneinander entwickelt und ausgeliefert werden können. Somit ist es möglich, dass Facebook täglich neue Features releast und sich Features wie Likes ändern, ohne dass die gesamte Anwendung davon betroffen ist. Oft bekommt man Änderungen gar nicht mit.

Kombinierbar bedeutet, dass es möglich ist, eine Anwendung aus einer Menge von Microservices zusammenzusetzen. Für verschiedene Anwendungen müssen Microservices daher wiederverwendbar sein. Beispielsweise ist die gesamte Amazon-Seite aus vielen kleinen Microservices aufgebaut, die nicht nur die Funktion, sondern auch die User-Interface-Komponenten für die Darstellung der Seite liefern. Aus diesen Eigenschaften ergeben sich die folgenden Vorteile:

Heterogenity

Resilience

Scalability

Easy Deployment

Organizational Alignment

Composability

Reusability

Replaceability

Diese Vorteile werden von Sam Newman in seinem Buch „Building Microservices"³ ausführlich beschrieben. Genau diese Vorteile unterstützen die Anforderungen aus dem neuen Anwendungskontext. Wir können in diesem shortcut nicht auf alle Vorteile eingehen, aber anhand des Vorteils Easy Deployment, der leicht verständlich ist, wollen wir verdeutlichen, wie die neuen Anforderungen unserer Kunden umgesetzt werden.

Easy Deployment bedeutet, dass wir einen Bugfix oder ein Feature einfach und schnell deployen und damit dem Kunden zur Verfügung stellen können. Genau das benötigen wir! Der Kunde erwartet, dass Fehler umgehend beseitigt werden und Features schnell zur Verfügung stehen. Das ist nicht möglich, wenn wir nur wenige Releases im Jahr ausrollen. Nein, wir brauchen mindestens tägliche Releases, um unseren Kunden zu begeistern, wenn nicht sogar mehrere Releases pro Tag.

Aber Vorsicht! Die Anforderungen unserer Kunden sind nicht überall identisch. Wird die Microservices Architecture in einem falschen Anwendungskontext eingesetzt, kann sie auch schnell zu einem Misserfolg und damit zum Scheitern des IT-Projekts führen. Gerade in klassischen Unternehmen, beispielsweise im Versicherungs-, Finanz- oder Automobilwesen, ist das Zerlegen eines bestehenden Monolithen⁴ in Microservices nicht zwingend die beste Lösung. Auch von einer zwanghaften Zerteilung einer Anwendungslandschaft in Microservices, die dafür nicht geeignet ist, ist abzusehen. In Unternehmen ist der Kunde oft der Mitarbeiter, für den wir Produkte bauen, und der erwartet nun wirklich nicht täglich ein neues Release, ganz im Gegenteil.

Hat man sich allerdings für eine Microservices Architecture entschieden, wird man vor große Herausforderungen gestellt, diese auch erfolgreich umzusetzen – Herausforderungen wie das Design, das User Interface, die Datenhaltung, die verteilte synchrone und asynchrone Kommunikation, die Versionierung oder das Monitoring, um nur einige zu nennen. Dabei wird klar, dass wir die Vorteile, die Microservices uns bieten, nicht geschenkt bekommen, sondern eine Menge dafür