Microservices? Was man über Microservices in der schlanken Produktentwicklung wissen muss.

Von Benedikt Eger und Anna Scheffold

Spotify, Tinder, Zalando – nur einige bekannte Beispiele für innovative Digitalunternehmen, die auf Microservices setzen. Und spätestens seit Netflix 2016 öffentlich gemacht hat, dass die Komplexität von globalem Videostreaming nur durch eine Microservices-Architektur bewältigt werden konnte, hat der Microservice-Hype seine Spitze erreicht.

 

Im ersten Teil der Blogserie haben wir die die Vorteile einer Microservice-Architektur aufgezeigt.

Um das Bild zu vervollständigen beschäftigen wir uns in diesem Artikel mit den Voraussetzungen für einen erfolgreichen Einsatz von Microservices in der Produktentwicklung.

Microservices sind super - weg mit den Monolithen? Bitte nicht!

Unterschied & Macher | Monolithen vs. Microservices EINFACH
Monolithen vs. Microservices - sehr vereinfacht dargestellt

Eine kurze Wiederholung der wichtigsten Begriffe aus dem vorigen Artikel: monolithische Architektur bedeutet, dass man die 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!

Denn die Einführung von Microservices bringt tatsächlich auch eine ganze Menge an 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 mit sich bringt. Der eigentliche Vorteil macht sich daher erst ab einer gewissen Komplexität der Gesamtapplikation bemerkbar

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. 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 Webshop-Beispiel, das wir schon in Teil 1 verwendet hatten könnte beispielsweise der Extremfall entstehen, dass der Microservice „Warenkorb" nicht live gehen kann, weil sich das Datenbank-Team noch um den Microservice „Produktdetails" kümmern muss.

 

Man sollte das Thema „Microservices" also nur dann ernsthaft in Betracht ziehen sollte, 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, man solle erstmal mit einer monolithischen Architektur starten 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.

Microservices in der digitalen Produktentwicklung

Die eingangs 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.

Unterschied & Macher | Monolithen und Microservices in der digitalen Produktentwicklung
So kann digitale Produktentwicklung ablaufen: Von der ersten Idee über ein funktionales Produkt hin zur Skalierung mit Microservices.

Bitte kein Microservice Envy!

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. 

 

Vielleicht gilt es also, 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. 


Mehr erfahren? Oder direkt gemeinsam mit uns loslegen? Dann einfach mal Kontakt aufnehmen!

BENEDIKT EGER, PARTNER

Ich arbeite am liebsten an der Einführung innovativer Technologien in bestehende Systemlandschaften. Dabei ist meine Architekturphilosophie: "So komplex wie nötig - so einfach wie möglich".

Sie sehen das genau so? Dann sollten wir miteinander sprechen!

+49 172 867 2500



Sie wollen digitale Lösungen entwickeln? Perfekt!

Poster: Unser Weg von der Produktidee bis zur Vermarktung

Wir unterstützen Sie bei allen Aspekten der digitalen Lösungsentwicklung. Erfahren Sie mehr über unser Portfolio und lassen Sie uns losfliegen!

Einfach mal machen. Zum Beispiel einen Design Thinking Workshop

Anna, Simon, Mona und Lara bei einem Workshop

Wir bieten verschiedene Einstiegsformate an, die Ihnen ganz konkrete Ergebnisse für Ihre Lösungsentwicklung bieten. Und ganz nebenbei können Sie uns im Arbeitsmodus kennenlernen. Egal ob Design Thinking oder ein kleiner Hackathon gemeinsam mit UuM. Einfach mal machen.