Microservices? Ja! (Aber….)

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.

 

Doch wo Licht ist, ist auch Schatten. Wir gehen also der Frage nach, was die Pros und Contras der Architektur sind, warum man sie für Lean Startup und digitale Produktentwicklung kennen sollte und wann es doch besser ist, einen Monolithen zu bauen. 

 

In Teil 1 unserer Blogserie gehen wir zuerst darauf ein, was Microservices und ihre Vorteile sind.

Was sind Microservices eigentlich?

Es geht hier um ein komplexes technisches Architekturthema. Also lasst uns zunächst definieren, über was wir eigentlich reden.

 

Microservices-Architektur ist eine Art, Software zu schreiben, bei der die Software in einzelne Teile aufgebrochen wird - meist anhand eines sogenannten „fachlichen Schnitts“. Diese einzelnen Teile (die eigentlichen „Microservices“) laufen jeweils in ihrem eigenen Prozess und kommunizieren miteinander über Webservices.

 

Etwas anschaulicher: Man stelle sich einen Webshop vor, bei dem die Funktionalitäten wie Warenkorb, Produktbeschreibung oder Preise nicht von einem einzelnen (man sagt gewöhnlich „monolithischen“) Software-Artefakt zur Verfügung gestellt werden, sondern aufgeteilt sind in einzelne Teile. Der große Unterschied zur klassischen Architektur? Microservices lassen sich einzeln und unabhängig voneinander entwickeln und in Betrieb nehmen.

 

Das kann ganz einfach dargestellt dann so aussehen:

 

Unterschied & Macher | Microservices versus Monolith
Eine einfache Darstellung Monolith vs. Microservice anhand eines Webshops

Merken Sie sich den auf der rechten Seite dargestellten Webshop, er begleitet uns als Beispiel durch den Artikel.

 

Wenn man den Vorteil einer Microservices-Architektur in einen einzelnen Satz verpacken möchte, ist es wohl dieser:

Microservices helfen beim Bewältigen von Komplexität, bei gleichzeitigem Gewinn von Flexibilität und Skalierbarkeit.

Komplexität, Flexibilität und Skalierbarkeit

1. Komplexität bewältigen

Komplexität wird durch eine Microservices-Architektur hauptsächlich bewältigt, indem sich kleinere Entwicklungsteams um einen klar abgegrenzten Bereich kümmern können. Diese Entwicklungsteams werden um den oben erwähnten „fachlichen Schnitt“ herum gebildet. Es gibt also nicht mehr riesiges Team, das die Gesamtarchitektur betrachten muss.

Unterschied & Macher | Kommunikation, Komplexität und Microservices.

Kommen wir zurück zu unserem Webshop als Beispiel.

 

In einer Microservice-Architektur kümmert sich „Team Warenkorb" ausschließlich um die Bereitstellung der Warenkorb-Funktionalität. Idealerweise ist es auch in der Lage, Änderungen an dieser Funktionalität ohne die Zuarbeit von anderen Beteiligten durchzuführen - von der Erhebung der Anforderungen bis zum Livegang des Features.

 

Dadurch wird zum einen die Kommunikation innerhalb des Teams einfacher, weil die Teams kleiner sind und Team-übergreifende Kommunikation durch den engen Verantwortungsbereich reduziert wird.

 

Dieser Effekt macht sich hauptsächlich bei großen Teams bemerkbar.

2. Flexibilität

Flexibilität in diesem Zusammenhang bedeutet vor allem technologische Freiheit.

 

Ein Microservice ist ein unabhängiges Deployment-Artefakt und meist in einen Docker-Container eingepackt. Daher kann das jeweilige Entwicklungsteam Programmiersprache und Betriebssystem frei wählen.

Unterschied & Macher | Flexibilität durch Microservices.

Übersetzt auf unser Webshop-Beispielkönnte man sich das folgendermaßen vorstellen:

  • der Warenkorb wird in Java mit Spring in einem Linux-OS bereitgestellt,
  • die Produktdetails dagegen als C#-Anwendung auf .NET in Windows.

Das eröffnet den Teams die Möglichkeit, den jeweils besten Technologiemix für die konkrete Anwendung zu verwenden. Völliger Wildwuchs ist zwar vermutlich nicht sinnvoll - aber die Möglichkeit zu haben, nicht mit einer einzigen Technologie das komplette Produkt entwickeln zu müssen, ist schon ein großer Vorteil.

 

Dadurch kann das jeweilige Team die Technologie wählen, die einerseits für das Problem am besten geeignet ist und andererseits gezielt Spezialisten Know-how im Team erfolgreich einsetzen. Auch auf lange Sicht ist das ein Vorteil: eine Applikation, die schon länger live ist könnte bspw. so stückweise (also: „Microservice-weise“) auf einen neuen Technologie-Stack gehoben werden.

3. Skalierbarkeit

Die Skalierbarkeit zeigt sich anhand der Möglichkeit, die einzelnen Microservices unabhängig voneinander in Betrieb zu nehmen und daher auch unabhängig voneinander zu skalieren.

Unterschied & Macher | Skalierung mit  Microservices.

Im klassischen, monolithischen Deployment-Modell ist es nur möglich die Gesamtapplikation zu skalieren, was üblicherweise durch „mehr Server" oder „stärkere Server" getan wird.  Manchmal ist es aber nur ein Teil der Gesamtapplikation, der eigentlich skaliert werden müsste.

 

Zurück zum Webshop-Beispiel:

Wenn man Microservices verwendet und merkt, dass die Warenkorb-Funktionalität besonders häufig benutzt wird, kann dieser Aspekt der Anwendung einzeln skaliert werden.  

 

Der Rest der Applikation kann also bei den aktuellen Ausprägungen bleiben – was sich unter anderem in Sachen Skalierungs-Geschwindigkeit und Betriebskosten bemerkbar macht.

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

Auch wenn die obigen Punkte so klingen, als sollten nun alle auf Microservices setzen und das „alte" Architekturmodell nicht mehr benutzen - das wäre ein voreiliger Schluss!

 

Warum Monolithen durchaus auch Ihre Vorteile haben und wann man vielleicht lieber keine Microservice-Architektur einsetzen sollte, diskutieren wir im zweiten Teil unserer Artikel-Reihe "Microservices? Ja, aber..."


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

Unterschied & Macher | Benedikt Eger

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!

Unterschied & Macher | Vorgehen bei der digitalen Produktentwicklung

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.

Unterschied & Macher | Design Thinking 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.