Was sind Microservices, welche Vor- und Nachteile bieten sie und wann lohnt sich ihr Einsatz? Dies sind Fragen, denen wir in unserer Blogserie auf den Grund gehen wollen. In diesem Teil geht es um die Fragen, warum man Microservices für Lean Startup und digitale Produktentwicklung verwenden sollte und wann es doch besser ist, einen Monolithen zu bauen.

Tags: , , , 5.4 Min. LesezeitZuletzt aktualisiert: 17. September 2021

Im ersten Teil der Blogserie über Microservices haben wir die Vorteile einer Microservice-Architektur gegenüber einer monolithischen Architektur aufgezeigt. Microservices helfen beim Bewältigen von Komplexität und bringen gleichzeitig Flexibilität und Skalierbarkeit.

Aber welche Voraussetzungen braucht es für einen erfolgreichen Einsatz von Microservices in der Produktentwicklung? Welche Herausforderungen bringt der Einsatz von Microservices mit sich?

Dem wollen wir in diesem Artikel auf den Grund gehen.

Monolithische Architektur bedeutet in der Softwareentwicklung, dass man eine Anwendung „in einem Stück“ live bringen muss.

Im Unterschied dazu ist bei einer Microservices-Architektur die Anwendung in einzelne Teile aufgeteilt und jedes einzelne Teil kann unabhängig von den anderen entwickelt und produktiv genommen werden.

Jetzt bitte nicht „Monolith“ mit „Spaghetticode“ gleichsetzen: intern kann so ein Monolith trotzdem sehr modular und strukturiert aufgebaut sein und ist für viele Anwendungen immer noch die richtige Architektur!

Wann lohnen sich Microservices in der Produktentwicklung?

Die Einführung von Microservices bringt tatsächlich eine ganze Menge Herausforderungen mit sich, die sich hauptsächlich beim Betrieb und der organisatorischen Struktur manifestieren. Man muss sich also bewusst machen, dass der Einsatz von Microservices einen gewissen Overhead erzeugt. Der eigentliche Vorteil macht sich daher erst ab einer gewissen Komplexität der Gesamtapplikation bemerkbar.

Aktiendepot als Monolith
Aktiendepot mit Microservices

Unterschiede der Software-Architektur bei Nutzung von Microservices im Vergleich zu einer monolithischen Struktur © Unterschied & Macher

Microservices brauchen Automatisierung

Monolith bedeutet, dass man nur ein einzelnes Artefakt in Betrieb nehmen und überwachen muss. Bei der Umstellung auf Microservices wird man auf einmal mit einer großen Anzahl an Artefakten konfrontiert, also wird auch die Infrastruktur komplexer.

Um diese Komplexität überhaupt bewältigen zu können, muss das Betriebsmodell einen sehr hohen Grad an Automatisierung besitzen. Vereinfacht gesagt bedeutet das: für die Inbetriebnahme neuer Features darf nicht viel mehr als ein Knopfdruck notwendig sein und schon gar kein aufwändiger manueller Prozess mit mehreren Schritten.

Diese hohen Anforderungen an Automatisierung und Tooling umfassen übrigens auch das Testing und Debugging massiv verteilter Applikationen.

Organisatorische Abhängigkeiten bedenken

Wie in Teil eins der Blogserie erwähnt, sehen Microservices vor, dass sich ein einzelnes Team um einen Microservice von A bis Z kümmert.

Diese Unabhängigkeit zu bewahren, ist eine wichtige Aufgabe. Sie muss also bei der Bildung neuer Teams, die sich um eine Aufgabe kümmern, bedacht werden.

Gibt es beispielsweise ein Datenbank-Team, das sich um die Datenbank-Entwicklung für mehrere Microservices kümmert, entsteht eine organisatorische Abhängigkeit. Diese macht die technische Unabhängigkeit wieder zunichte: Teamübergreifende Kommunikation und Koordination wird notwendig.

In unserem Aktiendepot-Beispiel, das wir schon in Teil 1 verwendet hatten, könnte beispielsweise der Extremfall entstehen, dass der Microservice „Börsenkurse“ nicht live gehen kann, weil sich das Datenbank-Team noch um den Microservice „Kundenservice“ kümmern muss.

Man sollte das Thema „Microservices“ also nur dann ernsthaft in Betracht ziehen, wenn man sich sicher sein kann, die Infrastruktur beherrschen zu können und wenn sich die Organisation flexibel genug anpassen kann.

Sehr spannend in diesem Kontext ist übrigens die „Monolith first“-Idee von Martin Fowler. Diese besagt, dass man zunächst mit einer monolithischen Architektur starten soll und dann, sobald es sinnvoll ist, einen ersten Teil davon als Microservice „herausbrechen“. Ob diese Vorgehensweise wirklich praktikabel ist und man den geeigneten Punkt immer auch erkennt, sei dahingestellt. Und genau das bringt uns zu unserem nächsten Punkt.

Der richtige Zeitpunkt zur Einführung von Microservices

Die in Teil eins genannten Beispiele um Netflix & Co. gehen ja explizit auf innovative, digitale Produkte ein. Da liegt der Gedanke nahe, bei der Produktentwicklung denselben Weg zu gehen und sein innovatives Vorhaben auf Microservices aufzubauen.

Das kann allerdings eine gefährliche Idee sein.
Schauen wir uns dazu die ersten drei „großen Phasen“ der digitalen Produktentwicklung an:

  • Genesis.
    Der Startpunkt der Produktentwicklung. Man hat ein lösenswertes, relevantes Problem gefunden. Und eine gute Idee für eine Lösung.
  • Problem-Solution-Fit (PSF).
    Löst mein Produkt oder Service ein relevantes Problem meiner Zielgruppe? Und gibt es im Vergleich zu verfügbaren Alternativen ein Markt-Potenzial dafür? Dazu gilt es möglichst schnell mit einem ersten wertschaffenden Produkt an den Markt zu gehen (auch Minimum Viable Product genannt).
  • Product-Market-Fit (PMF).
    Ist das MVP erfolgreich, kann man den PMF anstreben. Hier gilt es nun ein funktionales, programmiertes Produkt zur Verfügung zu stellen und echte Nutzer in das System zu bekommen. Durch die stetige Weiterentwicklung und Verprobung neuer Ideen kann man den PMF erreichen.

Gerade in diesen frühen Phase, in der man sein Produkt noch schärft, in der noch viele Hypothesen und Ideen mit einem kleinen Team und wenig Budget getestet werden müssen, gibt es eine einfache Daumenregel:

Daumenregel: In der frühen Phase der digitalen Produktentwicklung sollte man keine Microservices einsetzen!

Wenn das MVP validiert wurde und man mit dem Produkt den richtigen Product-Market-Fit gefunden hat, kann man das Augenmerk darauf legen, das Ganze solide (und skalierbar!) zu bauen.

Dann können Microservices die richtige Wahl sein. „Können“ deshalb, weil mindestens eben die oben genannten Voraussetzungen erfüllt sein müssen, damit die Microservices-Architektur ihre Vorteile entfalten kann.  Weitere interessante Ausführungen zum Thema „About When Not to Do Microservices“ finden sich im gleichnamigen Artikel.

Die nachfolgende Grafik stellt den Entwicklungsverlauf eines digitalen Produkts im Zusammenhang mit Monolithen und Microservices schematisch dar.

Einsatz von Microservices zur Skalierung des Projektes

Einsatz von Monolithen und Microservices bei der Entwicklung eines digitalen Produkts © Unterschied & Macher

Bitte kein Microservice Neid!

Man kann übrigens auch ohne Microservices erfolgreich sein. Denn auf keinen Fall sollte man in die Falle tappen zu sagen „alle machen Microservices also mache ich das auch“. Das kommt so häufig vor, dass es dafür sogar einen eigenen Begriff gibt – den „Microservice envy„.

Netflix sagt dazu selbst „Be aware of your situation and what works for you“.

Und genau darum geht es ja eigentlich bei jeder Architekturentscheidung: die aktuellen Rahmenbedingungen kennen, Vor- und Nachteile abwägen und informiert diejenige Entscheidung treffen, die in der aktuellen Situation angemessen ist.

Und diese Entscheidung ist nicht nur eine architektonische. Sie hat, wie erwähnt, Auswirkungen auf die Organisationsstruktur und damit auf alle Projektbeteiligten und am Ende auf das ganze Unternehmen.

Daher sollte man mit der „Monolith first“-Idee im Hinterkopf starten – denn auch Netflix hat nicht mit einer Microservices-Architektur angefangen, sondern als DVD-Verleihdienst in einer Welt, in der es nur Monolithen gab.

Autor

Benedikt Eger
Head of Technology, Managing Director bei Unterschied & Macher. Mit mittlerweile jahrzehntelanger Expertise in der digitalen Produktentwicklung berate ich Kunden aus Legal und Finance. Mein Fokus liegt dabei immer darauf, die richtige Lösung für die aktuelle Challenge zu finden - sei es durch den Einsatz eines existierenden Produktes oder individuelle Implementierung.
DT&B Newsletter Logo

Insights aus den Bereichen Legal, Finance & Digital Tech. Bleiben Sie informiert.