Genau an dieser Stelle unterscheiden sich Microservices von anderen Modularisierungsansätzen [1]. Microservices sind Module, die unabhängig in Produktion gebracht werden können. Um dieses Ziel zu erreichen, sind die Microservices beispielsweise eigene Prozesse, virtuelle Maschinen oder Docker Container als leichtgewichtige Alternative zur Virtualisierung. Das getrennte Deployment kann hierbei folgendermaßen funktionieren: Bei der Nutzung von Docker Containern wird eine neue Version eines Microservices ausgerollt, indem der alte Docker Container entfernt und ein neuer gestartet wird. Der Docker Container kann eine eigene Web-Oberfläche anbieten - beispielsweise für die Registrierung eines Kunden in einem eCommerce-System. Andere Microservices können andere Teile der Oberfläche anbieten. Microservices können sich aber auch gegenseitig über eine API beispielsweise mittels REST aufrufen.

Also nehmen Microservices die Idee der Modularisierung aus der Entwicklung auf und erweitern diese auf den Bereich des Deployments. Das erscheint zunächst nur eine kleine Änderung zu sein, hat aber viele Vorteile.

Damit zielen Microservices auf die Modularisierung einzelner Systeme. Sie sind im Gegensatz zu SOA kein Konzept, um die IT-Landschaft eines gesamten Unternehmens zu verbessern.

Organisation

Oft werden Microservices als eine Architektur dargestellt, die nicht zur Skalierung der Architektur selber dient, sondern zur Skalierung der Organisation:

Durch die Trennung in Deployment-Einheiten erreichen Microservices also eine bessere Entkopplung. Das führt zu weniger Abstimmungsbedarf, was für die Organisation vorteilhaft ist. Die Vorteile auf organisatorischer Ebene verleiten dazu, Microservices nur als Lösung für große Teams und komplexe Projekten in Erwägung zu ziehen. In der Praxis gibt es jedoch viele Projekte mit kleinen Teams, die Microservices nutzen. Es gibt also mehr Gründe für den Einsatz von Microservices.

Architektur

Auf Ebene der Architektur haben Microservices ebenfalls einige Vorteile:

Die architekturellen Vorteile sind für große Projekte wichtig, können aber schon bei kleinen Systemen vorteilhaft sein.

Technische Vorteile

Schließlich haben Microservices auch technische Vorteile:

Microservices bieten also Vorteile auf ganz verschiedenen Ebenen. Daher sollte man Microservices auch nicht als eine spezielle Lösung für ein Problem verstehen, sondern als einen Ansatz, der viele verschiedene Einsatzmöglichkeiten hat (Abb. 1).

Abb. 1: Vorteile von Microservices
Abb. 1: Vorteile von Microservices

Spielarten von Microservices

Abhängig vom konkreten Szenario und den angestrebten Vorteilen, können Microservices ganz unterschiedlich umgesetzt werden:

Abb. 2: Die Frontends nutzen eine API. Microservices
implementieren Teile der API auf und rufen gegebenenfalls
weitere Microservices auf.
Abb. 2: Die Frontends nutzen eine API. Microservices implementieren Teile der API auf und rufen gegebenenfalls weitere Microservices auf.
Abb. 3: Ein Algorithmus wird in sehr kleine Microservices
aufgeteilt. Alle Microservices können miteinander asynchron kommunizieren.
Abb. 3: Ein Algorithmus wird in sehr kleine Microservices aufgeteilt. Alle Microservices können miteinander asynchron kommunizieren.
Abb. 4: SCS können Teile eines Geschäftsprozesses abbilden und enthalten eine Web-Oberfläche. Sie kommunizieren möglichst wenig und bevorzugt asynchron.
Abb. 4: SCS können Teile eines Geschäftsprozesses abbilden und enthalten eine Web-Oberfläche. Sie kommunizieren möglichst wenig und bevorzugt asynchron.

Alle diese Spielweisen sind in Projekten erfolgreich und haben unterschiedliche Vor- und Nachteile. Auch das ist ein Hinweis darauf, dass Microservices einen breiten Einsatzkontext haben und mehr sind als nur eine Modeerscheinung.

Techniken

Da Microservices nur ein unabhängiges Deployment voraussetzen, können sie unterschiedlich umgesetzt werden:

Docker Container sind fast synonym zu Microservices. Aber auch die anderen Ansätze haben sinnvolle Einsatzkontexte. Die Technologien unterscheiden sich vor allem in der Isolation: Ein Docker-Container oder eine virtuelle Maschine hat eine komplette, eigene Betriebssytem-Installation. Änderungen am Betriebssystem betreffen also nur einen Microservice. Sind die Microservices Prozesse, dann teilen sie sich das Betriebssystem. Ein Microservice auf einem Java Application Server wiederum ist wesentlich schlechter gegen andere Microservices auf demselben Server isoliert, als dies bei Prozessen der Fall wäre. Wenn ein Microservice auf dem Application Server sehr viel Speicher verbraucht oder auf der CPU eine hohe Last erzeugt, beeinflusst das die anderen Anwendung auf dem Application Server - ein Absturz des Application Servers führt sogar zum Ausfall aller Microservices.

Wenn wirklich nur ein getrenntes Deployment notwendig ist, dann kann ein Ansatz mit einem Application Server ausreichend sein. Außerdem spart der Ansatz Ressourcen: Eine Anwendung auf einem Application Server verbraucht weniger RAM und CPU als ein Docker Container. Außerdem gibt oft schon viele Erfahrungen mit Application Server. Wenn aber eine bessere Isolation notwendig ist, können Docker-Container die bessere Wahl sein.

Die Wahl der richtigen Technologie kann also das Erreichen der Architektur-Ziele unterstützen und auch die Nachteile der Microservice-Architektur minimieren.

Nachteile

Microservice-Systeme haben natürlich viel mehr Einheiten, die in Produktion gebracht werden müssen und dort auch überwacht werden müssen, als das bei klassischen Systemen der Fall ist. Das ist eine der größten Herausforderungen beim Einsatz von Microservices. Begegnen muss man der Herausforderung durch Automatisierung. Diese ist wegen der höheren Qualität der Betriebsprozesse und der besseren Reproduzierbarkeit aber sowieso wünschenswert. In gewisser Weise sorgen Microservices dafür, dass bekannte Best Practices auch tatsächlich umgesetzt werden. Eine andere Möglichkeit, mit dem Problem im Betrieb umzugehen, ist die Nutzung von Plattformen wie den schon erwähnten Serverless-Umgebungen oder PaaS (Platform as a Service).

Jeder Microservice hat auch eine eigene Datenbank oder zumindest ein getrenntes Schema in einer gemeinsamen Datenbank. Nur so können die Microservices tatsächlich unabhängig gehalten werden. Wenn eine Gesamtsicht auf die Daten notwendig ist, müssen diese repliziert werden. Das ist aber kein neuer Ansatz - Data Warehouses machen so etwas schon lange - nicht nur wegen der Performance, sondern auch weil andere Datenmodelle für die Analyse notwendig sind.

Ebenfalls sind Tests eine Herausforderung: Wenn einzelne Microservices unabhängig in Produktion gebracht werden sollen, müssen die vorher notwendigen Tests ebenfalls möglichst unabhängig sein. Sonst müssen alle Microservices gemeinsam vor der Produktionseinführung getestet werden. Diese Testphase wird dann zu einem Flaschenhals. Selbst wenn die Tests der einzelnen Microservices schnell sind - durch den Flaschenhals bremsen sie sich gegenseitig aus. Bei einer Migration in eine Microservices-Architektur ist es nicht ausreichend, das System in Komponenten aufzuteilen. Die Tests müssen ebenfalls modularisiert werden.

Schließlich ist ein Microservices-System ein verteiltes System - wenn man es nach dem Netflix-Beispiel aufbaut. Aufrufe in verteilten System sind wesentlich langsamer als Aufrufe in einem System. Außerdem kann es vorkommen, dass der Empfänger eines verteilten Aufrufs gerade nicht zur Verfügung steht. Die Performance und Zuverlässigkeit sind also zusätzliche Herausforderungen bei Microservices.

Aber nicht jede Spielart von Microservices habe dieses Problem: SCS teilen ein System in eine Vielzahl von Web-Anwendungen auf. Ein HTTP-Request eines Benutzer wird dann typischerweise von einem einzigen SCS abgearbeitet und es gibt keine Verteilung. So nimmt die Komplexität des Systems ab.

Ähnliches gilt für die Infrastruktur: SCS sind Web-Anwendungen. Das System wird zwar mehrere Web-Anwendungen enthalten, aber es sind kaum neue Elemente in der Infrastruktur notwendig. Ein Netflix-Ansatz kommt beispielsweise nicht ohne Service Discovery zur Registrierung und Suche nach Microservices aus.

Durch die Wahl eines bestimmten Architektur-Ansatzes und eine Analyse, welche Ziele die Microservices-Architektur tatsächlich hat, können die Nachteile also begrenzt werden.

Vielleicht der größte Nachteil ist, dass Microservices gerade in Mode sind. Es kann daher gut sein, dass viele Microservices-Architekturen umsetzen, weil „man heute Architektur ja so macht“. Wer so unvorbereitet eine Architektur auswählt, wird mit einem anspruchsvollen Modell wie Microservices kaum erfolgreich sein können.

Abb. 5: Nachteile von Microservice-Architekturen
Abb. 5: Nachteile von Microservice-Architekturen

Fazit

Die Idee zu Microservices ist nicht neu und Firmen wie Amazon [11] setzten die Ideen schon seit 10 Jahren um. Im Objektspektrum sind die grundlegenden Ideen auch schon vor 5 Jahren erläutert worden [12].

Microservices haben sich in den letzten Jahren zu einer Architektur-Familie entwickelt. Zahlreiche Projekte nutzen solche Ansätze. Mittlerweile sind daher Vor- und Nachteile bekannt. Ebenso wird die Umsetzung einfacher, weil mehr und mehr Technologien auf den Markt kommen, die speziell auf Microservices abgestimmt sind. Neben den Unternehmen aus dem Web-Umfeld setzten sich Microservices auch bei Finanzdienstleistern durch [13].

Ein wichtiger Faktor für den Erfolg von Microservices ist die gute Unterstützung für agile Softwareentwicklung. Aber Microservices sind mehr als nur eine Lösung für genau dieses Problem. Microservices haben nicht nur aus organisatorischer Sicht sondern auch aus architektureller und technischer Sicht Vorteile. Ein Fokus auf die gewünschten Vorteile ermöglicht eine Technologie- und Architektur-Auswahl, die Nachteile minimiert.

So sind Microservices breit einsetzbar - und sicher mehr als ein Hype und eine Eintagsfliege. Wie jeder anderer Ansatz haben Microservices aber auch Nachteile und sind nur in bestimmten Szenarien sinnvoll einsetzbar. Nachteile und Vorteile abzuwägen und dann die richtige Architektur auszuwählen, bleibt eine wesentliche Aufgabe für Software-Architekten.

Literatur & Links

  1. Eberhard Wolff: Microservices: Grundlagen flexibler Softwarearchitekturen, dpunkt.verlag, 2015, ISBN 978–3864903137  ↩

  2. http://www.programmableweb.com/news/why-netflix-moved-to-microservices-architecture/elsewhere-web/2016/04/02/  ↩

  3. http://microxchg.io/2016/talk/Rodrigue_Schaefer_From_Monolith_to_Microservices.html/  ↩

  4. http://www.se-radio.net/2016/03/se-radio-episode-253-fred-george-on-developer-anarchy/  ↩

  5. http://scs-architecture.org/  ↩

  6. https://www.innoq.com/de/blog/transklusion/  ↩

  7. https://dev.otto.de/2015/09/30/on-monoliths-and-microservices/  ↩

  8. http://galeria-kaufhof.github.io/general/2015/12/15/architektur-und-organisation-im-galeria-de-produktmanagement/  ↩

  9.  http://kuehne-nagel.github.io/monolith-to-microservices/  ↩

  10. https://aws.amazon.com/lambda/details/  ↩

  11. http://www.heise.de/developer/artikel/Neun-Jahre-Microservices-2867634.html/  ↩

  12.  http://www.sigs-datacom.de/fileadmin/user_upload/zeitschriften/os/2011/Architekturen/tilkov_ghadir_OS_Architekturen_11.pdf/  ↩

  13. https://jaxenter.de/micro-services-in-der-praxis-nie-wieder-monolithen-391/  ↩

TAGS